let's make FriCAS optional

[Martin R]

Dear all,

I would like to propose to make the package FriCAS optional.  FriCAS provides some functionality which is otherwise either mostly missing (e.g., guessing formulas, lazy powerseries), or not as complete as might be desirable (e.g., symbolic integration, solving differential equations).

The FriCAS interface was completely rewritten after FriCAS was demoted to experimental in #18563 and is now quite mature, containing lots of doctests.

I opened trac ticket #23847 for the process.

Martin

[Samuel Lelievre]

Tue 2017-09-26 14:06:36 UTC, Martin R:

> I would like to propose to make the package FriCAS optional.

+1

[David Joyner]

On Tue, Sep 26, 2017 at 10:06 AM, 'Martin R' via sage-devel
<sage-...@googlegroups.com> wrote:
> Dear all,
>
> I would like to propose to make the package FriCAS optional. FriCAS
> provides some functionality which is otherwise either mostly missing (e.g.,
> guessing formulas, lazy powerseries), or not as complete as might be
> desirable (e.g., symbolic integration, solving differential equations).

+1
If it helps to improve Sage's DE solving capability, I'm all for it.

>
> The FriCAS interface was completely rewritten after FriCAS was demoted to
> experimental in #18563 and is now quite mature, containing lots of doctests.
>
> I opened trac ticket #23847 for the process.
>
> Martin
>

> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+...@googlegroups.com.
> To post to this group, send email to sage-...@googlegroups.com.
> Visit this group at https://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/d/optout.

[Ralf Stephan]

+1

[Emmanuel Charpentier]

+1, with some wishes :

- doctests

-documentation

--

Emmanuel Charpentier

[Martin R]

Could you please be more specific?

* there are currently 170 doctests in the interface itself (93% coverage, including quite a few testing the conversion to sage objects), and some more in the symbolic directory.  Which parts of the interface would you like to be more tested?

* Which parts of the interface would you like to see more heavily documented?  There is some module level documentation highlighting some features of FriCAS.  The intention of the interface is, of course, not having to learn FriCAS's own language (which is excellent, but that's a different story) - you should be able to simply use sage's syntax.  

Martin

[Vincent Delecroix]

If FriCAS is

* well maintained
* does build on various architectures and systems (32bits/64 bits,
GNULinux/cygwin/OSX)

(which I believe it is) then of course +1 for its inclusion as optional
package.

[Emmanuel Charpentier]

I was thinking of installing doctests in the "main" facilities. For example, in the documentation of integrate, provide an optional doctest, ecxecuted if and only if fricas is installed, showing that "algorithm='fricas'" allows to solve a symbolic integration that integrate() doesn't solve.

Martin argues that this should be te subject of another ticket. He may be right...

Right now, I'm testing #23782 which is the last non-closed ticket on which#23847 depends.

--

Emmanuel Charpentier

[Jeroen Demeyer]

On 2017-09-27 09:11, Vincent Delecroix wrote:
> If FriCAS is
>
> * well maintained
> * does build on various architectures and systems (32bits/64 bits,
> GNULinux/cygwin/OSX)

Indeed. This is exactly the necessary and sufficient condition for a
package to be optional (as opposed to experimental).

[Vincent Delecroix]

Not sufficient: the package has to be useful for Sage and used in
Sage... emacs is unlikely to become an optional package even if it
satisfies the above conditions.

[rjf]

To the extent that Macsyma/Maxima    and Scratchpad/Axiom/Fricas have 

overlapping capabilities, it would be interesting to have a competent assessment as to

which of them should be used by Sage for some functionalities.

RJF

[Jeroen Demeyer]

On 2017-09-27 16:10, Vincent Delecroix wrote:
> Not sufficient: the package has to be useful for Sage and used in
> Sage... emacs is unlikely to become an optional package even if it
> satisfies the above conditions.

That's why I added "as opposed to experimental" :-)

emacs shouldn't be experimental either.

[John H Palmieri]

Indeed, it should be mandatory.

[Martin R]

I vote for making sage part of emacs, actually.  Well, in fact, it *is* part of emacs.

Martin

[Martin R]

So, apart from the fact that emacs is the only thing a computer should ever run, here is something that might be useful, related to #12589.  Of course, the three-liner below is just a proof of concept, but could easily be expanded into something that works reliably.

Martin

"""

sage: var('q')

sage: f=(q^13362120470/((q - 1)*(q^5 - 1)*(q^21 - 1)*(q^85 - 1)*(q^341 -1)*(q^1365 - 1)*(q^5461 - 1)*(q^21845 - 1)*(q^87381 - 1)*(q^349525 -1)*(q^1398101 - 1)*(q^5592405 - 1)*(q^22369621 - 1)*(q^89478485 -1)*(q^357913941 - 1)*(q^1431655765 - 1)*(q^5726623061 - 1)) +1)/(q^7635497409/((q - 1)*(q^5 - 1)*(q^21 - 1)*(q^85 - 1)*(q^341 -1)*(q^1365 - 1)*(q^5461 - 1)*(q^21845 - 1)*(q^87381 - 1)*(q^349525 -1)*(q^1398101 - 1)*(q^5592405 - 1)*(q^22369621 - 1)*(q^89478485 -1)*(q^357913941 - 1)*(q^1431655765 - 1)*(q^5726623061 - 1)) + 1)

sage: series(f, q, 0)

       11

1 + O(q  )

sage: series(sin(q), q, 0)

    1  3    1   5     1   7      1    9      11

q - - q  + --- q  - ---- q  + ------ q  + O(q  )

    6      120      5040      362880

"""

def series(expr, x, a):

    t = "UTS(FRAC INT, '" + str(x) + ", " + str(a) + ")"

    fricas.set(str(x), "monomial(1,1)$" + t)

    return fricas("(" + str(expr) + ")" + "::" + t)

[Volker Braun]

M-x sage-mode

[kcrisman]

On Wednesday, September 27, 2017 at 1:21:23 PM UTC-4, rjf wrote:

To the extent that Macsyma/Maxima    and Scratchpad/Axiom/Fricas have 

overlapping capabilities, it would be interesting to have a competent assessment as to

which of them should be used by Sage for some functionalities.

Yes, and also sympy, which seems to have been expanding its capabilities a lot the past few years.  There was preliminary work along those lines with respect to integration/limits. 

[mmarco]

Indeed. This last GSoC there was some work to include the Rubi integrator in sympy. That could allow to compute a larger set of integrals (although I have read that it can be kind of slow). It would be a good idea to consider which one of these options we should call by default in each case.