Opened 7 years ago

Last modified 6 years ago

#18920 closed defect

upgrade Maxima to version >= 5.39 — at Version 89

Reported by: Dima Pasechnik Owned by:
Priority: major Milestone: sage-7.6
Component: symbolics Keywords:
Cc: Ralf Stephan, Jean-Pierre Flori, Karl-Dieter Crisman, Nils Bruin, Jeroen Demeyer, Volker Braun, Emmanuel Charpentier Merged in:
Authors: Dima Pasechnik Reviewers:
Report Upstream: Fixed upstream, in a later stable release. Work issues: fix doctests
Branch: public/t18920 (Commits, GitHub, GitLab) Commit: af7e5ff2e30dfed8bcb4c597403a6a23eb93b86a
Dependencies: #22191 Stopgaps:

Status badges

Description (last modified by Dima Pasechnik)

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

Change History (89)

comment:1 Changed 7 years ago by Dima Pasechnik

Cc: Ralf Stephan added
Description: modified (diff)

comment:2 Changed 7 years ago by Dima Pasechnik

Description: modified (diff)

comment:3 Changed 7 years ago by Dima Pasechnik

Description: modified (diff)

comment:4 Changed 7 years ago by François Bissey

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.

comment:5 Changed 7 years ago by François Bissey

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.

comment:6 Changed 7 years ago by Dima Pasechnik

Branch: u/dimpase/eclupdate
Cc: Jean-Pierre Flori added
Commit: 045d21eeb356b04102696d1aa51776b1330c635a
Description: modified (diff)

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?

comment:7 Changed 7 years ago by Dima Pasechnik

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

comment:8 Changed 7 years ago by Dima Pasechnik

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.

comment:9 Changed 7 years ago by François Bissey

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.

comment:10 Changed 7 years ago by François Bissey

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

comment:11 in reply to:  10 Changed 7 years ago by Dima Pasechnik

Replying to fbissey:

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.

comment:12 Changed 7 years ago by François Bissey

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.

comment:13 in reply to:  9 ; Changed 7 years ago by Dima Pasechnik

Replying to fbissey:

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.

comment:14 in reply to:  12 Changed 7 years ago by Dima Pasechnik

Replying to fbissey:

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

comment:15 in reply to:  13 Changed 7 years ago by Dima Pasechnik

Replying to dimpase:

Replying to fbissey:

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.

comment:16 Changed 7 years ago by Dima Pasechnik

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

to hopefully sort out the ECL autotools mess.

comment:17 Changed 7 years ago by François Bissey

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.

comment:18 Changed 7 years ago by François Bissey

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.

comment:19 Changed 7 years ago by Dima Pasechnik

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.

comment:20 Changed 7 years ago by git

Commit: 045d21eeb356b04102696d1aa51776b1330c635a9fc27ca7ba877a83443c61d22542e49d65096404

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

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

comment:21 Changed 7 years ago by Karl-Dieter Crisman

Cc: Karl-Dieter Crisman added

comment:22 Changed 7 years ago by git

Commit: 9fc27ca7ba877a83443c61d22542e49d6509640482fdf0eaa092b63cc98d97b418721795ea6b5081

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

82fdf0eported maxima patches; tarball needs bootstrapping; trivial doctests fix

comment:23 Changed 7 years ago by Dima Pasechnik

Cc: Nils Bruin added

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?

comment:24 in reply to:  23 ; Changed 7 years ago by Nils Bruin

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.

comment:25 Changed 7 years ago by Dima Pasechnik

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

comment:26 Changed 7 years ago by git

Commit: 82fdf0eaa092b63cc98d97b418721795ea6b50810d0649ad925808a308084b04253d7eb5c3fe2fad

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

0d0649asome easy doctest fixes

comment:27 Changed 7 years ago by Jeroen Demeyer

This is bad:

  • build/pkgs/maxima/spkg-install

    diff --git a/build/pkgs/maxima/spkg-install b/build/pkgs/maxima/spkg-install
    index 3c80e5c..b08d0d7 100755
    a b done 
    4747echo
    4848echo "Now configuring Maxima..."
     49./bootstrap
    4950./configure --prefix="$SAGE_LOCAL" --libdir="$SAGE_LOCAL/lib" --enable-ecl git_found=false
    5051check_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.

comment:28 in reply to:  13 ; Changed 7 years ago by Jeroen Demeyer

Replying to dimpase:

spkg-src is outdated anyway.

[citation needed]

comment:29 in reply to:  27 Changed 7 years ago by Dima Pasechnik

Replying to jdemeyer:

This is bad:

  • build/pkgs/maxima/spkg-install

    diff --git a/build/pkgs/maxima/spkg-install b/build/pkgs/maxima/spkg-install
    index 3c80e5c..b08d0d7 100755
    a b done 
    4747echo
    4848echo "Now configuring Maxima..."
     49./bootstrap
    4950./configure --prefix="$SAGE_LOCAL" --libdir="$SAGE_LOCAL/lib" --enable-ecl git_found=false
    5051check_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.

comment:30 in reply to:  28 Changed 7 years ago by Dima Pasechnik

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.

comment:31 Changed 7 years ago by Dima Pasechnik

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 ()...

Last edited 7 years ago by Dima Pasechnik (previous) (diff)

comment:32 Changed 7 years ago by Dima Pasechnik

Branch: u/dimpase/eclupdateu/dimpase/updateecl
Commit: 0d0649ad925808a308084b04253d7eb5c3fe2fadb669a434bdf2f91d21254ccf186bc86396dd4909

New commits:

1a0e5c9initial update; implib.patch is problematic
b669a43fixed broken Makefile.in patch (spaces and tabs don't mix), reorganised patches.

comment:33 Changed 7 years ago by Dima Pasechnik

Branch: u/dimpase/updateeclu/dimpase/eclupdate
Commit: b669a434bdf2f91d21254ccf186bc86396dd49090d0649ad925808a308084b04253d7eb5c3fe2fad
Dependencies: #18961
Description: modified (diff)
Summary: upgrade Maxima and ECL to 5.36.0.1 and 15.3.7, respectivelyupgrade Maxima to 5.36.1

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

comment:34 in reply to:  24 ; Changed 7 years ago by Dima Pasechnik

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?

comment:35 in reply to:  34 ; Changed 7 years ago by Nils Bruin

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.

comment:36 in reply to:  35 Changed 7 years ago by Dima Pasechnik

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...

comment:37 Changed 7 years ago by Nils Bruin

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)
Last edited 7 years ago by Nils Bruin (previous) (diff)

comment:38 Changed 7 years ago by Nils Bruin

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)

comment:39 Changed 7 years ago by Nils Bruin

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.

comment:40 Changed 7 years ago by Peter Bruin

Report Upstream: N/ANot yet reported upstream; Will do shortly.

I tried upgrading to Maxima 5.37.0 (released 17 August). The formatting problem is fixed, although some of the output still looks slightly different (more/fewer parentheses, different ordering of terms in some polynomials).

However, there is a serious bug in the function eigenvectors causing too few eigenvectors to be returned:

(%i1) M: matrix([1, 1, 0], [0, 1, 0], [0, 0, 2]);
                                  [ 1  1  0 ]
                                  [         ]
(%o1)                             [ 0  1  0 ]
                                  [         ]
                                  [ 0  0  2 ]

Maxima 5.35.1 computes the eigenvalues and eigenvectors correctly:

(%i2) eigenvectors(M);
(%o2)           [[[1, 2], [2, 1]], [[[1, 0, 0]], [[0, 0, 1]]]]

In Maxima 5.37.0, the eigenvector [0, 0, 1] is missing:

(%i2) eigenvectors(M);
(%o2)                  [[[1, 2], [2, 1]], [[[1, 0, 0]]]]

I found this out through several doctest failures in Sage.

comment:41 Changed 7 years ago by Peter Bruin

Report Upstream: Not yet reported upstream; Will do shortly.Reported upstream. No feedback yet.

comment:42 Changed 6 years ago by Travis Scrimshaw

It seems that version 5.38 was released a few months ago, and we are currently at 5.35.1. I think we can upgrade now since the reported bug was fixed.

comment:43 Changed 6 years ago by Travis Scrimshaw

Cc: Jeroen Demeyer Volker Braun added
Milestone: sage-6.8sage-7.3
Report Upstream: Reported upstream. No feedback yet.Fixed upstream, in a later stable release.

comment:44 in reply to:  42 Changed 6 years ago by Peter Bruin

Replying to tscrim:

It seems that version 5.38 was released a few months ago, and we are currently at 5.35.1. I think we can upgrade now since the reported bug was fixed.

Note that the bug fix is only in the development branch, not in 5.38.1. We can of course add the relevant upstream commit (3e4e107) as a patch.

comment:45 Changed 6 years ago by Travis Scrimshaw

Shall we then move forward then with upgrading to 5.38.1 with backporting 3e4e107 as a patch? Or should we ask the Maxima team to see how close they are to cutting a 5.38.2?

comment:46 Changed 6 years ago by Dima Pasechnik

Milestone: sage-7.3sage-7.4
Summary: upgrade Maxima to 5.36.1upgrade Maxima to version >= 5.38.1

it's about time. Should I have a go at it?

comment:47 Changed 6 years ago by Tobias Hansen

Please do. We have to make sagemath 7.4 work with maxima 5.38.1 in Debian and it would help if we had a patch that we could backport.

comment:48 Changed 6 years ago by François Bissey

Dima, can you rebase your branch?

comment:49 Changed 6 years ago by Dima Pasechnik

Will try later today.

comment:50 Changed 6 years ago by Dima Pasechnik

Branch: u/dimpase/eclupdatepublic/t18920
Commit: 0d0649ad925808a308084b04253d7eb5c3fe2fad231002039aeed3f1926ec58804bd538b5ec9385d
Dependencies: #18961

rebased the relevant patches


New commits:

ee327bcported maxima patches; tarball needs bootstrapping; trivial doctests fix
2310020some easy doctest fixes

comment:51 Changed 6 years ago by Dima Pasechnik

Work issues: rebase the rest of Maxima patches

So far, only the relevant commits from the old branch are rebased. I still have to fix patches to Maxima sources -- they don't apply cleanly.

comment:52 Changed 6 years ago by François Bissey

We'll also want to move to maxima 5.38.1 at least.

comment:53 Changed 6 years ago by git

Commit: 231002039aeed3f1926ec58804bd538b5ec9385da4bf7166892c6dae760cd2cd1c84f5cb9675ef15

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

a4bf716rebased patches, added eigenvectors patch too

comment:54 Changed 6 years ago by Dima Pasechnik

Authors: Dima Pasechnik
Description: modified (diff)
Milestone: sage-7.4sage-7.5
Work issues: rebase the rest of Maxima patchesfix doctests, if any.

comment:55 Changed 6 years ago by Dima Pasechnik

this seems to be a change:

File "src/sage/interfaces/maxima.py", line 210, in sage.interfaces.maxima
Failed example:
    g.taylor('x', 0, 3)
Expected:
    x+x^3/6+(3*x^5)/40+(5*x^7)/112+(35*x^9)/1152
Got:
    f/(k^4*x^4)-(2*f)/((3*k^2)*x^2)+(11*f)/45-((62*k^2*f)*x^2)/945

there f is defined as f=maxima(`1/x^2`), so this no longer works, defining maxima functions this way.

Anyhow, I'm pushing the other doctest changes for this file, and few other.

comment:56 Changed 6 years ago by git

Commit: a4bf7166892c6dae760cd2cd1c84f5cb9675ef1562b5825544b467e481c7a752604b8d45c64d9752

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

62b5825some more easy doctest fixes

comment:57 Changed 6 years ago by Dima Pasechnik

the following looks to me like a regression (or perhaps it's not really, as if one picked the right branches of the corresponding complex variable functions, it would be correct) :

File "src/sage/calculus/tests.py", line 107, in sage.calculus.tests
Failed example:
    integrate(log(1-x^2)/x, x)
Expected:
    1/2*log(x^2)*log(-x^2 + 1) + 1/2*polylog(2, -x^2 + 1)
Got:
    log(-x)*log(x + 1) + log(x)*log(-x + 1) + polylog(2, x + 1) + polylog(2, -x + 1)

New commits:

62b5825some more easy doctest fixes

comment:58 Changed 6 years ago by Dima Pasechnik

and another regression of sorts: despite besselexpand set to False, one gets

File "src/sage/interfaces/maxima_lib.py", line 66, in sage.interfaces.maxima_lib
Failed example:
    sum((-x)^n/(factorial(n)*factorial(n+3/2)),n,0,oo)
Expected:
    bessel_J(3/2, 2*sqrt(x))/x^(3/4)
Got:
    -1/2*(2*x*cos(2*sqrt(x)) - sqrt(x)*sin(2*sqrt(x)))/(sqrt(pi)*x^2)

Perhaps it's a deficiency of our test, which is too simple for besselexpand to kick in.

comment:59 Changed 6 years ago by Dima Pasechnik

this one needs work:

File "src/sage/interfaces/maxima_lib.py", line 724, in sage.interfaces.maxima_lib.Ma
ximaLib.sr_integral
Failed example:
    integrate(1 / (1 + abs(x-5)), x, -5, 6)
Exception raised:
    Traceback (most recent call last):
    ...
    TypeError: unable to make sense of Maxima expression 'limit(if(-(_SAGE_VAR_x-5)>0,-log(6-_SAGE_VAR_x),log(abs(_SAGE_VAR_x-4))),_SAGE_VAR_x,-5,plus)' in Sage

comment:60 Changed 6 years ago by Dima Pasechnik

and this one is puzzling on the Sage side:

File "src/sage/misc/functional.py", line 658, in sage.misc.functional.integral
Failed example:
    _ = integrate(y, x, -1000, 1000)
Exception raised:
...
    FloatingPointError: Floating point exception

and comes from a regression in Maxima/ECL version combo (I did check that with Maxima 5.38.1 running on SBCL 1.3.6 this integral computes just fine).

Maxima 5.38.1 http://maxima.sourceforge.net
using Lisp ECL 16.1.2
Distributed under the GNU Public License. See the file COPYING.
Dedicated to the memory of William Schelter.
The function bug_report() provides bug reporting information.
(%i1) integrate((x^2)*exp(x) / (1 + exp(x))^2,x,-1000,1000);

Maxima encountered a Lisp error:

 #<a ARITHMETIC-ERROR>

Automatically continuing.
To enable the Lisp debugger set *debugger-hook* to nil.
Last edited 6 years ago by Dima Pasechnik (previous) (diff)

comment:61 Changed 6 years ago by Dima Pasechnik

this one needs an expert opinion:

File "src/sage/schemes/projective/projective_morphism.py", line 853, in sage.schemes.projective.projective_morphism.SchemeMorphism_polynomial_projective_space.dynatomic_polynomial
Failed example:
    f.dynatomic_polynomial(2)
Expected:
    0.666666666666667*x^2 + 0.333333333333333*y^2
Got:
    2.00000000000000*x^2 + 0.999999999999999*y^2

The output is clearly different, but perhaps it's OK, I don't know---I suspect it's OK, as we must be interested in the projective points where it vanishes(?) - documentation talks about "roots" though, and these, projectively, remain the same.

Last edited 6 years ago by Dima Pasechnik (previous) (diff)

comment:62 Changed 6 years ago by git

Commit: 62b5825544b467e481c7a752604b8d45c64d97529ef994d79cfe0af28d17d0951b709576647a4231

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

9ef994dmore easy doctest fixes

comment:63 Changed 6 years ago by Dima Pasechnik

Status: newneeds_review

setting this to "needs review", so that the issues I raised in comments can be discussed.

There are still few easy doctest fixes to be done, I'll do them.

comment:64 Changed 6 years ago by git

Commit: 9ef994d79cfe0af28d17d0951b709576647a42313c280228256c02dcba6e6a8df2bcb98625031613

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

3c28022more easy doctest fixes

comment:65 in reply to:  60 ; Changed 6 years ago by Dima Pasechnik

Replying to dimpase:

regression in Maxima/ECL version combo (I did check that with Maxima 5.38.1 running on SBCL 1.3.6 this integral computes just fine).

I opened https://sourceforge.net/p/maxima/bugs/3235/

comment:66 in reply to:  65 ; Changed 6 years ago by Dima Pasechnik

Replying to dimpase:

Replying to dimpase:

regression in Maxima/ECL version combo (I did check that with Maxima 5.38.1 running on SBCL 1.3.6 this integral computes just fine).

I opened https://sourceforge.net/p/maxima/bugs/3235/

Robert Dodier has traced this down to a problem with ECL, see https://gitlab.com/embeddable-common-lisp/ecl/issues/299

ECL has a problem comparing their own (there is no Common Lisp standard for this) infinity constants with 1/1000000...

comment:67 Changed 6 years ago by git

Commit: 3c280228256c02dcba6e6a8df2bcb98625031613100d9d6516e4bcfbb93ee979f086f52072ace786

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

5d86413Merge branch 'public/t18920' of trac.sagemath.org:sage into max5381
100d9d6workaround for #<a ARITHMETIC-ERROR> (18920#comment:60

comment:68 in reply to:  66 Changed 6 years ago by Dima Pasechnik

Replying to dimpase:

Replying to dimpase:

Replying to dimpase:

regression in Maxima/ECL version combo (I did check that with Maxima 5.38.1 running on SBCL 1.3.6 this integral computes just fine).

I opened https://sourceforge.net/p/maxima/bugs/3235/

Robert Dodier has traced this down to a problem with ECL, see https://gitlab.com/embeddable-common-lisp/ecl/issues/299

ECL has a problem comparing their own (there is no Common Lisp standard for this) infinity constants with 1/1000000...

this is fixed by Maxima people, and in the latest commit 100d9d6

comment:69 Changed 6 years ago by git

Commit: 100d9d6516e4bcfbb93ee979f086f52072ace786814e8edc2eb51ba9706c122a39bf75d3c77e141c

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

79eb82ffix for maxima bug #3236
814e8edreflect patch's dependence on an earlier maxima tree commit

comment:70 Changed 6 years ago by git

Commit: 814e8edc2eb51ba9706c122a39bf75d3c77e141caf7e5ff2e30dfed8bcb4c597403a6a23eb93b86a

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

af7e5ffnew scaling of dynatomic polynomial

comment:71 in reply to:  67 Changed 6 years ago by Dima Pasechnik

Replying to git:

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

5d86413Merge branch 'public/t18920' of trac.sagemath.org:sage into max5381
100d9d6workaround for #<a ARITHMETIC-ERROR> (18920#comment:60

this workaround turned out to be buggy, and anyway ECL has released a fix for this problem, making the workaround not necessary. (But it would need an update of our ECL package, as it does depend upon a number of changes, see https://gitlab.com/embeddable-common-lisp/ecl/issues/299; they promise a new release by the end of the year).

Should we wait, or should we proceed?

comment:72 Changed 6 years ago by Travis Scrimshaw

I think we should either backport the fix as a patch to ECL or perhaps take a development cut.

comment:73 Changed 6 years ago by Jean-Pierre Flori

I would go for the first option which looks easier: just put the ECL patch into build/pkgs/ecl/patches.

comment:74 Changed 6 years ago by Jean-Pierre Flori

There is the issue that you have to force an ECL rebuild. Add a p(n+1) suffix in package-version.txt?

comment:75 in reply to:  73 Changed 6 years ago by Dima Pasechnik

Replying to jpflori:

I would go for the first option which looks easier: just put the ECL patch into build/pkgs/ecl/patches.

a single patch is not enough. In fact, it hangs the ECL build if I do this. ECL people say the have worked on a number of related things, that is support of IEEE floats, since the release, so the latest fix relies on these. A proper ECL update is the only way I think.

comment:76 Changed 6 years ago by François Bissey

We may have to wait. I could try a git snapshot in sage-on-gentoo to see how things are going but I am overloaded as it is. I have to draw the line somewhere.

comment:77 Changed 6 years ago by Ximin Luo

Hi, we're following this ticket very closely in Debian. I notice that the following two patches are still applicable to 5.38.1:

Have these patches been forwarded upstream yet? Would they be suitable for other users of Maxima, or are they only useful for Sage?

comment:78 in reply to:  77 Changed 6 years ago by Dima Pasechnik

Replying to infinity0:

Hi, we're following this ticket very closely in Debian. I notice that the following two patches are still applicable to 5.38.1:

this one comes from upstream, from here: https://sourceforge.net/p/maxima/bugs/2520/#e3a5 (so it's sort of unfinished digging on the maxima side; it's definitely useful outside of Sage)

this is also from upstream (updated somewhat): https://sourceforge.net/p/maxima/bugs/2596/

again, upstream still has it open.

comment:79 Changed 6 years ago by Jeroen Demeyer

Status: needs_reviewneeds_work
Work issues: fix doctests, if any.fix doctests
sage -t --long src/sage/interfaces/maxima.py
**********************************************************************
File "src/sage/interfaces/maxima.py", line 210, in sage.interfaces.maxima
Failed example:
    g.taylor('x', 0, 3)
Expected:
    x+x^3/6+(3*x^5)/40+(5*x^7)/112+(35*x^9)/1152
Got:
    f/(k^4*x^4)-(2*f)/((3*k^2)*x^2)+(11*f)/45-((62*k^2*f)*x^2)/945
**********************************************************************
1 item had failures:
   1 of  96 in sage.interfaces.maxima
    [182 tests, 1 failure, 10.65 s]
sage -t --long src/sage/symbolic/expression_conversions.py
**********************************************************************
File "src/sage/symbolic/expression_conversions.py", line 535, in sage.symbolic.expression_conversions.InterfaceInit.derivative
Failed example:
    b = maxima(a); b
Expected:
    %at('diff('f(_SAGE_VAR_t0),_SAGE_VAR_t0,1),[_SAGE_VAR_t0=%e^_SAGE_VAR_x])
Got:
    %at('diff('f(_SAGE_VAR_t0),_SAGE_VAR_t0,1),_SAGE_VAR_t0=%e^_SAGE_VAR_x)
**********************************************************************
File "src/sage/symbolic/expression_conversions.py", line 544, in sage.symbolic.expression_conversions.InterfaceInit.derivative
Failed example:
    b = maxima(a); b
Expected:
    %at('diff('f(_SAGE_VAR_t0),_SAGE_VAR_t0,1),[_SAGE_VAR_t0=4])
Got:
    %at('diff('f(_SAGE_VAR_t0),_SAGE_VAR_t0,1),_SAGE_VAR_t0=4)
**********************************************************************
File "src/sage/symbolic/expression_conversions.py", line 564, in sage.symbolic.expression_conversions.InterfaceInit.derivative
Failed example:
    b = maxima(a); b
Expected:
    %at('diff('f(_SAGE_VAR_t0,_SAGE_VAR_t1),_SAGE_VAR_t0,1),[_SAGE_VAR_t0=4,_SAGE_VAR_t1=_SAGE_VAR_y])
Got:
    %at('diff('f(_SAGE_VAR_t0,_SAGE_VAR_y),_SAGE_VAR_t0,1),_SAGE_VAR_t0=4)
**********************************************************************
File "src/sage/symbolic/expression_conversions.py", line 573, in sage.symbolic.expression_conversions.InterfaceInit.derivative
Failed example:
    b = maxima(a); b
Expected:
    %at('diff('f(_SAGE_VAR_t0,_SAGE_VAR_t1),_SAGE_VAR_t0,1),[_SAGE_VAR_t0=4,_SAGE_VAR_t1=8])
Got:
    %at('diff('f(_SAGE_VAR_t0,8),_SAGE_VAR_t0,1),_SAGE_VAR_t0=4)
**********************************************************************
1 item had failures:
   4 of  37 in sage.symbolic.expression_conversions.InterfaceInit.derivative
    [462 tests, 4 failures, 5.14 s]
sage -t --long src/sage/calculus/tests.py
**********************************************************************
File "src/sage/calculus/tests.py", line 107, in sage.calculus.tests
Failed example:
    integrate(log(1-x^2)/x, x)
Expected:
    1/2*log(x^2)*log(-x^2 + 1) + 1/2*polylog(2, -x^2 + 1)
Got:
    log(-x)*log(x + 1) + log(x)*log(-x + 1) + polylog(2, x + 1) + polylog(2, -x + 1)
**********************************************************************
1 item had failures:
   1 of  83 in sage.calculus.tests
    [82 tests, 1 failure, 8.56 s]
sage -t --long src/sage/interfaces/maxima_lib.py
**********************************************************************
File "src/sage/interfaces/maxima_lib.py", line 66, in sage.interfaces.maxima_lib
Failed example:
    sum((-x)^n/(factorial(n)*factorial(n+3/2)),n,0,oo)
Expected:
    bessel_J(3/2, 2*sqrt(x))/x^(3/4)
Got:
    -1/2*(2*x*cos(2*sqrt(x)) - sqrt(x)*sin(2*sqrt(x)))/(sqrt(pi)*x^2)
**********************************************************************
File "src/sage/interfaces/maxima_lib.py", line 724, in sage.interfaces.maxima_lib.MaximaLib.sr_integral
Failed example:
    integrate(1 / (1 + abs(x-5)), x, -5, 6)
Exception raised:
    Traceback (most recent call last):
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 498, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 861, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.interfaces.maxima_lib.MaximaLib.sr_integral[12]>", line 1, in <module>
        integrate(Integer(1) / (Integer(1) + abs(x-Integer(5))), x, -Integer(5), Integer(6))
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/misc/functional.py", line 662, in integral
        return x.integral(*args, **kwds)
      File "sage/symbolic/expression.pyx", line 11624, in sage.symbolic.expression.Expression.integral (/usr/local/src/sage-config/src/build/cythonized/sage/symbolic/expression.cpp:64315)
        return integral(self, *args, **kwds)
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/symbolic/integration/integral.py", line 777, in integrate
        return definite_integral(expression, v, a, b, hold=hold)
      File "sage/symbolic/function.pyx", line 995, in sage.symbolic.function.BuiltinFunction.__call__ (/usr/local/src/sage-config/src/build/cythonized/sage/symbolic/function.cpp:11329)
        res = super(BuiltinFunction, self).__call__(
      File "sage/symbolic/function.pyx", line 485, in sage.symbolic.function.Function.__call__ (/usr/local/src/sage-config/src/build/cythonized/sage/symbolic/function.cpp:6372)
        res = g_function_evalv(self._serial, vec, hold)
      File "sage/symbolic/function.pyx", line 1084, in sage.symbolic.function.BuiltinFunction._evalf_or_eval_ (/usr/local/src/sage-config/src/build/cythonized/sage/symbolic/function.cpp:12689)
        return self._eval0_(*args)
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/symbolic/integration/integral.py", line 178, in _eval_
        return integrator(*args)
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/symbolic/integration/external.py", line 24, in maxima_integrator
        result = maxima.sr_integral(expression, v, a, b)
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/interfaces/maxima_lib.py", line 799, in sr_integral
        return max_to_sr(maxima_eval(([max_integrate],[sr_to_max(SR(a)) for a in args])))
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/interfaces/maxima_lib.py", line 1672, in max_to_sr
        args=[max_to_sr(a) for a in max_args]
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/interfaces/maxima_lib.py", line 1672, in max_to_sr
        args=[max_to_sr(a) for a in max_args]
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/interfaces/maxima_lib.py", line 1663, in max_to_sr
        sage_expr=SR(maxima(expr))
      File "sage/structure/parent.pyx", line 953, in sage.structure.parent.Parent.__call__ (/usr/local/src/sage-config/src/build/cythonized/sage/structure/parent.c:9849)
        return mor._call_(x)
      File "sage/structure/coerce_maps.pyx", line 238, in sage.structure.coerce_maps.NamedConvertMap._call_ (/usr/local/src/sage-config/src/build/cythonized/sage/structure/coerce_maps.c:6388)
        cdef Element e = method(C)
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/interfaces/maxima_abstract.py", line 1255, in _symbolic_
        return R(self._sage_())
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/interfaces/maxima_abstract.py", line 1230, in _sage_
        maxima=self.parent())
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/calculus/calculus.py", line 1897, 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 'limit(if(-(_SAGE_VAR_x-5)>0,-log(6-_SAGE_VAR_x),log(abs(_SAGE_VAR_x-4))),_SAGE_VAR_x,-5,plus)' in Sage
**********************************************************************

comment:80 Changed 6 years ago by Dima Pasechnik

Some of these doctests are solely Maxima's regressions, one is fixable via a ECL update. I can just mark them appropriately and proceed, if this is acceptable.

comment:81 in reply to:  79 ; Changed 6 years ago by Ralf Stephan

Replying to jdemeyer:

File "src/sage/interfaces/maxima_lib.py", line 724, in sage.interfaces.maxima_lib.MaximaLib.sr_integral
Failed example:
    integrate(1 / (1 + abs(x-5)), x, -5, 6)
Exception raised:
    Traceback (most recent call last):
...
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/calculus/calculus.py", line 1897, 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 'limit(if(-(_SAGE_VAR_x-5)>0,-log(6-_SAGE_VAR_x),log(abs(_SAGE_VAR_x-4))),_SAGE_VAR_x,-5,plus)' in Sage
**********************************************************************

This is both #17892 and #20191, because the result changed, presumably to something more correct that needs these symbolic functions we don't have atm.

comment:82 in reply to:  81 Changed 6 years ago by Dima Pasechnik

Replying to rws:

Replying to jdemeyer:

File "src/sage/interfaces/maxima_lib.py", line 724, in sage.interfaces.maxima_lib.MaximaLib.sr_integral
Failed example:
    integrate(1 / (1 + abs(x-5)), x, -5, 6)
Exception raised:
    Traceback (most recent call last):
...
      File "/usr/local/src/sage-config/local/lib/python2.7/site-packages/sage/calculus/calculus.py", line 1897, 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 'limit(if(-(_SAGE_VAR_x-5)>0,-log(6-_SAGE_VAR_x),log(abs(_SAGE_VAR_x-4))),_SAGE_VAR_x,-5,plus)' in Sage
**********************************************************************

This is both #17892 and #20191, because the result changed, presumably to something more correct that needs these symbolic functions we don't have atm.

I think this one is a new Maxima bug: https://sourceforge.net/p/maxima/bugs/3237/ - still under investigation by Maxima people.

comment:83 in reply to:  79 Changed 6 years ago by Ralf Stephan

Replying to jdemeyer:

sage -t --long src/sage/interfaces/maxima.py
**********************************************************************
File "src/sage/interfaces/maxima.py", line 210, in sage.interfaces.maxima
Failed example:
    g.taylor('x', 0, 3)
Expected:
    x+x^3/6+(3*x^5)/40+(5*x^7)/112+(35*x^9)/1152
Got:
    f/(k^4*x^4)-(2*f)/((3*k^2)*x^2)+(11*f)/45-((62*k^2*f)*x^2)/945

That's odd. The doctest skipped to the next result line which is of course different.

I think this one is a new Maxima bug: ​https://sourceforge.net/p/maxima/bugs/3237/ - still under investigation by Maxima people.

Looking more closely, I agree.

comment:84 Changed 6 years ago by Paul Masson

Cc: Paul Masson added

comment:85 Changed 6 years ago by François Bissey

ecl 16.1.3 is out. I haven't checked yet if all we want is in there but I will look int it.

comment:86 Changed 6 years ago by Jeroen Demeyer

If possible, do the ECL upgrade in a new ticket.

comment:87 Changed 6 years ago by François Bissey

Considering the havoc it wrecks in the building of the documentation it deserves its own ticket. Surprisingly, I haven't spotted libecl in the numerous backtraces produced before the build petered out. But that's the only thing I changed from one successful build to this one.

comment:88 Changed 6 years ago by Dima Pasechnik

Milestone: sage-7.5sage-7.6

comment:89 Changed 6 years ago by Dima Pasechnik

Dependencies: #22191
Description: modified (diff)
Summary: upgrade Maxima to version >= 5.38.1upgrade Maxima to version >= 5.39

maxima 5.39.0 has been released. ECL upgrade is happening on #22191.

Note: See TracTickets for help on using tickets.