upgrade Maxima to version >= 5.39

[dimpase]

this would fix some bugs, e.g. as reported here.

• get Maxima 5.39.0 tarball here

Upstream: Fixed upstream, in a later stable release.

CC: @rwst @jpflori @kcrisman @nbruin @jdemeyer @vbraun @EmmanuelCharpentier

Component: symbolics

Author: Dima Pasechnik

Branch/Commit: a6c51e6

Reviewer: Travis Scrimshaw, Emmanuel Charpentier, François Bissey, Jeroen Demeyer, Nils Bruin

Issue created by migration from https://trac.sagemath.org/ticket/18920

[dimpase]

Description changed:

--- 
+++ 
@@ -1,4 +1,5 @@
 this would fix some bugs, e.g. as reported [here](https://groups.google.com/d/msg/sage-support/OJAN4pk4dwQ/FJRxra67EbwJ).

-* get Maxima [here](https://github.com/andrejv/maxima) (then `git checkout 5.36.0.1`) and
-* ECL [here](https://gitlab.com/embeddable-common-lisp/ecl.git).
+* get Maxima [here](https://github.com/andrejv/maxima) (then `git checkout 5.36.0.1`); sf.net with tarballs is down...
+* ECL git [here](https://gitlab.com/embeddable-common-lisp/ecl.git) and apparently the tarball
+  can be obtained [there https://gitlab.com/embeddable-common-lisp/ecl/repository/archive.tar.gz?ref=ECL.15.3.7], too.

[dimpase]

Description changed:

--- 
+++ 
@@ -2,4 +2,4 @@

 * get Maxima [here](https://github.com/andrejv/maxima) (then `git checkout 5.36.0.1`); sf.net with tarballs is down...
 * ECL git [here](https://gitlab.com/embeddable-common-lisp/ecl.git) and apparently the tarball
-  can be obtained [there https://gitlab.com/embeddable-common-lisp/ecl/repository/archive.tar.gz?ref=ECL.15.3.7], too.
+  can be obtained [there](https://gitlab.com/embeddable-common-lisp/ecl/repository/archive.tar.gz?ref=ECL.15.3.7), too.

[dimpase]

Description changed:

--- 
+++ 
@@ -1,5 +1,5 @@
 this would fix some bugs, e.g. as reported [here](https://groups.google.com/d/msg/sage-support/OJAN4pk4dwQ/FJRxra67EbwJ).

-* get Maxima [here](https://github.com/andrejv/maxima) (then `git checkout 5.36.0.1`); sf.net with tarballs is down...
+* get Maxima [here](https://github.com/andrejv/maxima) (then `git checkout 5.36.0.1`); the [tarball](https://github.com/andrejv/maxima/archive/5.36.0.1.tar.gz); note that sf.net with tarballs is down...
 * ECL git [here](https://gitlab.com/embeddable-common-lisp/ecl.git) and apparently the tarball
   can be obtained [there](https://gitlab.com/embeddable-common-lisp/ecl/repository/archive.tar.gz?ref=ECL.15.3.7), too.

[kiwifb]

comment:4

For info, I have been using ecl 15.3.7 for a while in sage-on-gentoo. That part is a straight upgrade as far as I can see. I do not remember having tried a newer maxima but it usually breaks a lest a couple of doctest.

[kiwifb]

comment:5

I tried maxima 5.36.0 and reverted (that was with ecl 15.3.7) , not tried 5.36.1 (5.36.0.1 whatever the version number is actually).

     Wed Apr 29 11:14:49 2015 >>> sci-mathematics/maxima-5.35.1-r2
       merge time: 5 minutes and 6 seconds.

     Fri May  1 10:33:58 2015 >>> sci-mathematics/maxima-5.36.0
       merge time: 4 minutes and 52 seconds.

     Fri May  1 10:42:03 2015 >>> sci-mathematics/maxima-5.35.1-r2
       merge time: 5 minutes and 8 seconds.

[dimpase]

Description changed:

--- 
+++ 
@@ -2,4 +2,6 @@

 * get Maxima [here](https://github.com/andrejv/maxima) (then `git checkout 5.36.0.1`); the [tarball](https://github.com/andrejv/maxima/archive/5.36.0.1.tar.gz); note that sf.net with tarballs is down...
 * ECL git [here](https://gitlab.com/embeddable-common-lisp/ecl.git) and apparently the tarball
-  can be obtained [there](https://gitlab.com/embeddable-common-lisp/ecl/repository/archive.tar.gz?ref=ECL.15.3.7), too.
+  can be obtained [there](https://gitlab.com/embeddable-common-lisp/ecl/repository/archive.tar.gz?ref=ECL.15.3.7), too. But it is not useful without renaming, etc.
+
+ecl tarball to use is [here](http://users.ox.ac.uk/~coml0531/sage/ecl-15.3.7.tar.bz2)

[dimpase]

comment:6

The branch is currently not working; to build the new ecl pkg, one has to move patches/implib.patch out of the way; I tried porting the latter patch to the new ecl, but it produces a makefile error that I don't understand; anyway, it is cygwin-specific.

I cc its author now. J.-P., any ideas?

[dimpase]

Commit: 045d21e

[dimpase]

Branch: u/dimpase/eclupdate

[dimpase]

comment:7

for the record, I get

...
config.status: creating ecl/config.h
Configuration complete. To build ECL, issue make in this directory.
cd build; make -j1
make[1]: Entering directory `/home/dima/software/sage/local/var/tmp/sage/build/ecl-15.3.7.p0/src/build'
Makefile:192: *** commands commence before first target.  Stop.
make[1]: Leaving directory `/home/dima/software/sage/local/var/tmp/sage/build/ecl-15.3.7.p0/src/build'
make: *** [all] Error 2
Error - Failed to build ECL ... exiting

[dimpase]

comment:8

What I don't understand is whether some patches are in fact results of running autoconf/automake/aclocal on patched configure.ac, Makefile.in, etc.

If yes, then these should be split from the "real" ones to allow for fully automatic creation (and commands needed to run autotools need to be spelled out somewhere in the pkg docs). If no, then I don't see the point of patching configure.ac, Makefile.in, etc in the first place.

[kiwifb]

comment:9

Look at spkg_src. autotools are not run. But may be the impl platch was copied from an autotool run. The gmp patch deals with the removal of gmp sources from the upstream tarball (the configure script of ecl checks for stuff in that subdirectory so those checks have to be diverted). the impl patch deals with cygwin stuff.

Getting real autoconf patch and running autotools wouldn't be a bad idea but that means you will need to have autotools installed to run spkg-src. spkg-src will need to be amended accordingly.

[kiwifb]

comment:10

I notice that the gmp patch is against configure.ac while implib is against configure.in the last one is probably wrong.

[dimpase]

comment:11

Replying to @kiwifb:

I notice that the gmp patch is against configure.ac while implib is against configure.in the last one is probably wrong.

the name has changed in version 15.3.7.

[kiwifb]

comment:12

I am trying to read the stuff from the git commit and of course it is patch of patch, it is not readable as this, you changed it already I see.

[dimpase]

comment:13

Replying to @kiwifb:

Look at spkg_src. autotools are not run. But may be the impl platch was copied from an autotool run. The gmp patch deals with the removal of gmp sources from the upstream tarball (the configure script of ecl checks for stuff in that subdirectory so those checks have to be diverted). the impl patch deals with cygwin stuff.

Getting real autoconf patch and running autotools wouldn't be a bad idea but that means you will need to have autotools installed to run spkg-src. spkg-src will need to be amended accordingly.

spkg-src is outdated anyway.

[dimpase]

comment:14

Replying to @kiwifb:

I am trying to read the stuff from the git commit and of course it is patch of patch, it is not readable as this, you changed it already I see.

here they are in a more readable way: https://github.com/dimpase/ecl/commits/sagepatches

[dimpase]

comment:15

Replying to @dimpase:

Replying to @kiwifb:

Look at spkg_src. autotools are not run. But may be the impl platch was copied from an autotool run. The gmp patch deals with the removal of gmp sources from the upstream tarball (the configure script of ecl checks for stuff in that subdirectory so those checks have to be diverted). the impl patch deals with cygwin stuff.

No, I mean that it is silly and error-prone to rebase by hand patches that are better obtained directly from diffs to output of autoconf/automake/aclocal.

The latter should not be bundled together with the "real" one.

[dimpase]

comment:16

I have opened https://gitlab.com/embeddable-common-lisp/ecl/issues/93

to hopefully sort out the ECL autotools mess.

[kiwifb]

comment:17

Sorry I have been too busy today to look further into this. I can reproduce your problem with your branch on my mac. I haven't quite identified yet the guilty makefile. I think the problem is not in the top makefile but in one of the subfolders but I haven't identified which one yet.

[kiwifb]

comment:18

To complete the answer you got from upstream: automake is not used (not a crime) but ecl also ship some of its dependencies in the pristine tarball and those come with their own build systems which can use automake. Apart from ffi we don't want to care about these I think.

[dimpase]

comment:19

arrghh, that was me mixing of tabs and spaces in src/Makefile.in patch... Now all seems to work. I'll post an update soon.

OK, and for the record, src/configure is generated by autoreconf, that is, one does not need to rebase the corresponding patch manually.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

9fc27ca

fixed broken Makefile.in patch (spaces and tabs don't mix), reorganised patches.

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 045d21e to 9fc27ca

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 9fc27ca to 82fdf0e

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

82fdf0e

ported maxima patches; tarball needs bootstrapping; trivial doctests fix

[dimpase]

comment:23

New Maxima output sometimes breaks Sage parser, e.g.

sage -t src/sage/calculus/calculus.py
**********************************************************************
File "src/sage/calculus/calculus.py", line 373, in sage.calculus.calculus
Failed example:
    taylor(gamma(1/3+x),x,0,3)
Exception raised:
    Traceback (most recent call last):
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 496, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 858, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.calculus.calculus[100]>", line 1, in <module>
        taylor(gamma(Integer(1)/Integer(3)+x),x,Integer(0),Integer(3))
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/calculus/functional.py", line 378, in taylor
        return f.taylor(*args)
      File "sage/symbolic/expression.pyx", line 4038, in sage.symbolic.expression.Expression.taylor (/home/dima/software/sage/src/build/cythonized/sage/symbolic/expression.cpp:23671)
        return self.parent()(l)
      File "sage/structure/parent.pyx", line 1097, in sage.structure.parent.Parent.__call__ (/home/dima/software/sage/src/build/cythonized/sage/structure/parent.c:9546)
        return mor._call_(x)
      File "sage/structure/coerce_maps.pyx", line 237, in sage.structure.coerce_maps.NamedConvertMap._call_ (/home/dima/software/sage/src/build/cythonized/sage/structure/coerce_maps.c:5756)
        cdef Element e = method(C)
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/interfaces/maxima_abstract.py", line 1251, in _symbolic_
        return R(self._sage_())
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/interfaces/maxima_abstract.py", line 1226, in _sage_
        maxima=self.parent())
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/calculus/calculus.py", line 1901, in symbolic_expression_from_maxima_string
        raise TypeError("unable to make sense of Maxima expression '%s' in Sage"%s)
    TypeError: unable to make sense of Maxima expression '(1/432)*(72*gamma(1/3)*(psi[2])(1/3)+((-72)*euler_gamma^3+((-36)*pi*3^(1/2)+(-324)*log(3))*euler_gamma^2+((-108)*log(3)*pi*3^(1/2)+(-18)*pi^2+(-486)*log(3)^2+(-216)*(psi[1])(1/3))*euler_gamma+((-1)*pi^3+((-81)*log(3)^2+(-36)*(psi[1])(1/3))*pi)*3^(1/2)+(-27)*log(3)*pi^2+(-243)*log(3)^3+(-324)*(psi[1])(1/3)*log(3))*gamma(1/3))*_SAGE_VAR_x^3+(1/24)*((12*euler_gamma^2+(4*pi*3^(1/2)+36*log(3))*euler_gamma+6*log(3)*pi*3^(1/2)+pi^2+27*log(3)^2+12*(psi[1])(1/3))*gamma(1/3))*_SAGE_VAR_x^2+((-1)/6)*((6*euler_gamma+pi*3^(1/2)+9*log(3))*gamma(1/3))*_SAGE_VAR_x+gamma(1/3)' in Sage

and

File "src/sage/calculus/calculus.py", line 1746, in sage.calculus.calculus.symbolic_expression_from_maxima_string
Failed example:
    maxima('3*li[2](u)+8*li[33](exp(u))').sage()
Exception raised:
    Traceback (most recent call last):
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 496, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 858, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.calculus.calculus.symbolic_expression_from_maxima_string[6]>", line 1, in <module>
        maxima('3*li[2](u)+8*li[33](exp(u))').sage()
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/interfaces/interface.py", line 1016, in sage
        return self._sage_(*args, **kwds)
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/interfaces/maxima_abstract.py", line 1226, in _sage_
        maxima=self.parent())
      File "/home/dima/software/sage/local/lib/python2.7/site-packages/sage/calculus/calculus.py", line 1901, in symbolic_expression_from_maxima_string
        raise TypeError("unable to make sense of Maxima expression '%s' in Sage"%s)
    TypeError: unable to make sense of Maxima expression '8*(li[33])(e^u)+3*(li[2])(u)' in Sage

Is it easy to fix?

[nbruin]

comment:24

Replying to @dimpase:

    TypeError: unable to make sense of Maxima expression '(1/432)*(72*gamma(1/3)*(psi[2])(1/3)+((-72)*euler_gamma^3+((-36)*pi*3^(1/2)+(-324)*log(3))*euler_gamma^2+((-108)*log(3)*pi*3^(1/2)+(-18)*pi^2+(-486)*log(3)^2+(-216)*(psi[1])(1/3))*euler_gamma+((-1)*pi^3+((-81)*log(3)^2+(-36)*(psi[1])(1/3))*pi)*3^(1/2)+(-27)*log(3)*pi^2+(-243)*log(3)^3+(-324)*(psi[1])(1/3)*log(3))*gamma(1/3))*_SAGE_VAR_x^3+(1/24)*((12*euler_gamma^2+(4*pi*3^(1/2)+36*log(3))*euler_gamma+6*log(3)*pi*3^(1/2)+pi^2+27*log(3)^2+12*(psi[1])(1/3))*gamma(1/3))*_SAGE_VAR_x^2+((-1)/6)*((6*euler_gamma+pi*3^(1/2)+9*log(3))*gamma(1/3))*_SAGE_VAR_x+gamma(1/3)' in Sage

and

    TypeError: unable to make sense of Maxima expression '8*(li[33])(e^u)+3*(li[2])(u)' in Sage

No, it is not very easy to fix. We rewrite li[n]( to polylog(n, and the same for psi[n]( to psi(n,. This string matching obviously completely breaks if maxima starts spelling this as (li[n])(x). Quite frankly, that's an insane spelling, so perhaps the preferred approach is to clarify with the maxima folks if they really intend this. It might be an unforeseen byproduct of some other change that they prefer to fix themselves, in which case we shouldn't waste time.

If they insist this is a reasonable spelling, I think we can work around it, but it'll be a bit of real work. Note that we can handle calls to parenthesized functions:

sage: from sage.calculus.calculus import symbolic_expression_from_maxima_string as sefms
sage: sefms('(sin)(x)')
sin(x)

so as long as we ensure that expressions like li[n] and psi[n] themselves get parsed to callable functions, we should be OK. Something like this would be OK:

sage: sefms('li[n]')
curried_polylog(n)
sage: sefms('li[n]')(x)
polylog(n,x)
sage: sefms('(li[n])(x)')
polylog(n,x)

Since we cannot really handle square brackets, we'd need to do the li[n]->curried_polylog(n) via a string substitution, but that should be OK. The curried_polylog(n) would just create a symbolic function that, when called with a single argument, would create the appropriate polylog.

The binary conversion sr_to_max in maxima_lib.py shouldn't be affected, unless they have changed their internal representation of polylogarithms.

[dimpase]

comment:25

I opened https://sourceforge.net/p/maxima/bugs/2998/ to ask about these extra ()...

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Changed commit from 82fdf0e to 0d0649a

[7ed8c4ca-6d56-4ae9-953a-41e42b4ed313]

Branch pushed to git repo; I updated commit sha1. New commits:

0d0649a

some easy doctest fixes

[jdemeyer]

comment:27

This is bad:

diff --git a/build/pkgs/maxima/spkg-install b/build/pkgs/maxima/spkg-install
index 3c80e5c..b08d0d7 100755
--- a/build/pkgs/maxima/spkg-install
+++ b/build/pkgs/maxima/spkg-install
@@ -47,6 +47,7 @@ done
 echo
 echo "Now configuring Maxima..."
+./bootstrap
 ./configure --prefix="$SAGE_LOCAL" --libdir="$SAGE_LOCAL/lib" --enable-ecl git_found=false
 check_error "Failed to configure Maxima."

Bootstrapping should ideally be done by upstream. Alternatively, it should be done in spkg-src, but certainly not in spkg-install. Autotools are not a Sage prerequisite.

[jdemeyer]

comment:28

Replying to @dimpase:

spkg-src is outdated anyway.

[citation needed]

[dimpase]

comment:29

Replying to @jdemeyer:

This is bad:

diff --git a/build/pkgs/maxima/spkg-install b/build/pkgs/maxima/spkg-install
index 3c80e5c..b08d0d7 100755
--- a/build/pkgs/maxima/spkg-install
+++ b/build/pkgs/maxima/spkg-install
@@ -47,6 +47,7 @@ done
 echo
 echo "Now configuring Maxima..."
+./bootstrap
 ./configure --prefix="$SAGE_LOCAL" --libdir="$SAGE_LOCAL/lib" --enable-ecl git_found=false
 check_error "Failed to configure Maxima."

Bootstrapping should ideally be done by upstream. Alternatively, it should be done in spkg-src, but certainly not in spkg-install. Autotools are not a Sage prerequisite.

I am acutely aware of this; upstream is not doing bootstrapping in the release in question. Also, note that the ticket status is "new". I'll sort this out after the bigger issues are fixed.

[dimpase]

comment:30

Replying to @jdemeyer:

Replying to @dimpase:

spkg-src is outdated anyway.

[citation needed]

I meant to say that parts of this spkg-src need an update.

[dimpase]

comment:31

with sf.net back online, one finds there version 5.36.1. Not sure yet how much different it is from 5.36.0.1, which is not official...

5.36.1 has the same issue with too many ()...

[dimpase]

Changed branch from u/dimpase/eclupdate to u/dimpase/updateecl

[dimpase]

Changed commit from 0d0649a to b669a43

[dimpase]

New commits:

1a0e5c9	initial update; implib.patch is problematic
b669a43	fixed broken Makefile.in patch (spaces and tabs don't mix), reorganised patches.

[dimpase]

comment:33

I've split the update of ECL to a separate ticket #18961, as it is ready.

[dimpase]

Changed branch from u/dimpase/updateecl to u/dimpase/eclupdate

[dimpase]

Dependencies: #18961

[dimpase]

Changed commit from b669a43 to 0d0649a

[dimpase]

Description changed:

--- 
+++ 
@@ -1,7 +1,5 @@
 this would fix some bugs, e.g. as reported [here](https://groups.google.com/d/msg/sage-support/OJAN4pk4dwQ/FJRxra67EbwJ).

 * get Maxima [here](https://github.com/andrejv/maxima) (then `git checkout 5.36.0.1`); the [tarball](https://github.com/andrejv/maxima/archive/5.36.0.1.tar.gz); note that sf.net with tarballs is down...
-* ECL git [here](https://gitlab.com/embeddable-common-lisp/ecl.git) and apparently the tarball
-  can be obtained [there](https://gitlab.com/embeddable-common-lisp/ecl/repository/archive.tar.gz?ref=ECL.15.3.7), too. But it is not useful without renaming, etc.

-ecl tarball to use is [here](http://users.ox.ac.uk/~coml0531/sage/ecl-15.3.7.tar.bz2)
+ECL is updated on #18961

[dimpase]

comment:34

Replying to @nbruin:

Replying to @dimpase:

The binary conversion sr_to_max in maxima_lib.py shouldn't be affected, unless they have changed their internal representation of polylogarithms.

They say the change is a by-product to fix another bug. Obviously it is a low priority for them to make the output backwards compatible. I wonder if we should just fully switch to maxima_lib.py and do not try to deal with this in some other way?

[nbruin]

comment:35

Replying to @dimpase:

They say the change is a by-product to fix another bug. Obviously it is a low priority for them to make the output backwards compatible. I wonder if we should just fully switch to maxima_lib.py and do not try to deal with this in some other way?

Robert isn't making any statement there about priority. I would not think it's a very low priority, because the current behaviour is tantamount to writing (sin)(x), which is silly. I would not be surprised if in the next couple of weeks, when he has had a chance to think about a solution, he will have a fix. I'm sure it's not hard to fix. It just needs some thought to fix it properly and efficiently.

In terms of total amount of work, I would think introducing "curried" poylog and psi will be less work than eliminating any dependence on string parsing from maxima.

For calculus use, we're already moved entirely to maxima_lib. The library instance just allows two interfaces back and forth: a strings-based one and the binary sr_to_max and max_to_sr one. Moving calculus entirely to sr_to_max is a nice idea in general, and that's a worthwhile project that should be quite doable (we're halfway there already and it didn't take much work to do that). It would mean identifying all remaining places where calculus triggers string conversions and replace those sites with mechanisms comparable to sr_integral, sr_limit, sr_sum etc.

I think it's worthwhile if somehow we do maintain the pexpect interface to maxima as well, even if we don't need it for the calculus functionality in sage proper (and since the strings-based interface in maxima_lib shares nearly all its code with that, we might as well keep that too). Having the pexpect interfaces in sage is a useful feature for communicating with other computer algebra systems.

[dimpase]

comment:36

Replying to @nbruin:

Replying to @dimpase:

They say the change is a by-product to fix another bug. Obviously it is a low priority for them to make the output backwards compatible. I wonder if we should just fully switch to maxima_lib.py and do not try to deal with this in some other way?

Robert isn't making any statement there about priority. I would not think it's a very low priority, because the current behaviour is tantamount to writing (sin)(x), which is silly. I would not be surprised if in the next couple of weeks, when he has had a chance to think about a solution, he will have a fix. I'm sure it's not hard to fix. It just needs some thought to fix it properly and efficiently.

he replied, saying that he does not see a way to fix this, and that Sage has to put up with this for the time being.

I'd rather see this fixed im maxima, of course, but this is probably a nontrivial job for a Lisp hacker we don't have...

[nbruin]

comment:37

Quick workaround:

ecl_eval("(defprop $LI 210 rbp)")
ecl_eval("(defprop $PSI 210 rbp)")

it certainly avoids the extra parentheses around li and psi invocations. I've reported this workaround on the maxima bugtracker too. Hopefully Robert will comment there about any possible adverse effects. Including these statements in the maxima_calculus initialization in maxima_lib.py might do the trick (and possibly the change is accepted upstream!)

EDIT: A better and more universal change is probably:

ecl_eval("(defprop MFUNCTION 190 lbp)")

This way it applies to all "MQAPPLY" calls. That could be problematic, of course, but it doesn't seem to be, probably because 190 is still high enough. Things go wrong if you go too low:

sage: maxima_calculus("(a+b)(t)")
(b+a)(t)
sage: ecl_eval("(defprop MFUNCTION 1 lbp)")
<ECL: 1>
sage: maxima_calculus("(a+b)(t)")
b+a(t)

[nbruin]

comment:38

Of course, the expression type that gets constructed for li and psi is more general:

sage: maxima_calculus("a[1](x)")
a[1](x)
sage: maxima_calculus("a[1](x)").ecl()
<ECL: ((MQAPPLY SIMP) (($A SIMP ARRAY) 1) $X)>

but we already fail with that (because we carefully only convert li[ and psi[):

sage: SR(maxima_calculus("a[1](x)"))
TypeError: unable to make sense of Maxima expression 'a[1](x)' in Sage

Since square brackets are really part of Maxima's expression syntax, the proper solution would be to have a parser that can handle them. The following seems valid maxima:

sage: maxima_calculus("(sin(x)+cos(y))[tan(u)[3/(a+b)]+log(w)](t)")
(cos(y)+sin(x))[log(w)+tan(u)[3/(b+a)]](t)

and parsing that with anything less than parser support for [ will be. Of course, without [] support on the side of pynac, we'd have to parse a[n] to something like get_item(a,n) but that would be fine (and then get_item can have the right logic to actually resolve in relevant cases, but this would be more an extension of our symbolic expressions before it's a parsing issue for maxima)

[nbruin]

comment:39

The maxima ticket https://sourceforge.net/p/maxima/bugs/2998/ is now marked as resolved, so with any luck, the extra parentheses issue will not occur with the new maxima release.

The fix implemented is indeed ecl_eval("(defprop MFUNCTION 190 lbp)"), so if you do not want to wait for the next maxima release, just put this command in the initialization section of maxima_lib.