Upgrade Maxima to 5.33.0 #13973

dimpase · 2013-01-19T12:29:28Z

This is a continuation of #13364, and aims at including more upstream bug fixes, which e.g. fix an
issue reported on sage-support,
which was reported as Maxima bug 2535, and marked there as closed in post-5.29.1.

Fixes #11894, #13526, #13712, #14209, #14306, #15386 and possibly other Maxima-related bugs.

Ought to fix #13733 (but loading the abs_integrate package currently causes this to fail).

Ought to fix #8728 (but Maxima asks for more constraints which follow from the existing ones).

Does not fix #14591, #14677, #15033.

tarball: http://homepages.warwick.ac.uk/staff/P.Bruin/sage/maxima-5.33.0.tar.bz2

Note about the existing maxima_bug_2526.patch: the bug was marked "closed" in the Maxima bug tracking system, but the commit somehow disappeared from the Maxima repository and the bug has been reopened. Hence this patch is still needed to fix it.

CC: @SnarkBoojum

Component: packages: standard

Keywords: sd48

Author: Peter Bruin

Branch: a130eed

Reviewer: Marc Mezzarobba

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

The text was updated successfully, but these errors were encountered:

kcrisman · 2013-01-20T01:35:01Z

Changed dependencies from 13364 to #13364

kcrisman · 2013-01-20T01:39:55Z

comment:2

So for instance going at least as far as the fix for #13733 would be good.

zimmermann6 · 2013-01-23T08:08:29Z

comment:3

while we are at it, it seems strange to me that sage/interfaces/maxima_abstract.py contains a doctest for the maxima version used:

File "/localdisk/tmp/sage-5.5/devel/sage-12615b/sage/interfaces/maxima_abstract.py", line 422:
    sage: maxima.version()
Expected:
    '5.26.0'
Got:
    '5.29.1'

What really matters is the functionality provided, not the actual version?
Does Sage check the actual version of each component?

Paul

dimpase · 2013-01-23T09:45:14Z

comment:4

Replying to @zimmermann6:

while we are at it, it seems strange to me that sage/interfaces/maxima_abstract.py contains a doctest for the maxima version used:
File "/localdisk/tmp/sage-5.5/devel/sage-12615b/sage/interfaces/maxima_abstract.py", line 422:
    sage: maxima.version()
Expected:
    '5.26.0'
Got:
    '5.29.1'

seems that https://github.com/sagemath/sage-prod/files/10656171/doctests.2.patch.gz
was not installed into the Sage installation you work with.

What really matters is the functionality provided, not the actual version?
Does Sage check the actual version of each component?

Sage provides versions at least for some other components, e.g. gap.version()

Sometimes it might be useful; AFAIK some optional packages check this.

Dima

Paul

zimmermann6 · 2013-01-23T10:15:17Z

comment:5

Dima, I don't object about providing a function maxima_version(), but checking it returns a particular value.

Paul

dimpase · 2013-01-23T12:33:14Z

comment:6

Replying to @zimmermann6:

Dima, I don't object about providing a function maxima_version(), but checking it returns a particular value.

well, one would like to test Sage functions... How else would you check that it works and returns something meaningful?

Paul

zimmermann6 · 2013-01-23T12:37:01Z

comment:7

we could for example check that the version is of the form x.y.z, or is greater than or equal to a given number.

Paul

zimmermann6 · 2013-05-07T08:54:01Z

comment:8

see #14306 (issue fixed in Maxima git)

Paul

kcrisman · 2013-05-08T02:42:44Z

comment:9

Also note that Maxima is now at 5.30.0.

kiwifb · 2013-05-08T09:30:12Z

comment:10

Yes it is at 5.30.0. No check from sage-on-gentoo on whether it works so far because the maxima ecl library building is currently broken for that particular version - an adsf upgrade problem in gentoo.

I second checking the form of the version returned rather than the value. That would make my life easier when R, maxima are upgraded in s-o-g independently of sage itself (and without side effects at leat in doctests).

jdemeyer · 2013-06-13T08:51:24Z

comment:12

I'll try making a new Maxima spkg just to see what happpens...

jdemeyer · 2013-06-13T08:57:47Z

Author: Jeroen Demeyer

jdemeyer · 2013-06-13T09:30:54Z

comment:15

This looks problematic:

sage -t devel/sage/sage/calculus/calculus.py
**********************************************************************
File "devel/sage/sage/calculus/calculus.py", line 145, in sage.calculus.calculus
Failed example:
    e^M
Exception raised:
    Traceback (most recent call last):
      File "/mazur/release/merger/sage-5.10.rc2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 466, in _run
        self.execute(example, compiled, test.globs)
      File "/mazur/release/merger/sage-5.10.rc2/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 825, in execute
        exec compiled in globs
      File "<doctest sage.calculus.calculus[32]>", line 1, in <module>
        e**M
      File "constants_c.pyx", line 275, in sage.symbolic.constants_c.E.__pow__ (sage/symbolic/constants_c.cpp:2779)
      File "matrix_symbolic_dense.pyx", line 387, in sage.matrix.matrix_symbolic_dense.Matrix_symbolic_dense.exp (sage/matrix/matrix_symbolic_dense.c:3433)
      File "/mazur/release/merger/sage-5.10.rc2/local/lib/python2.7/site-packages/sage/interfaces/interface.py", line 199, in __call__
        return cls(self, x, name=name)
      File "/mazur/release/merger/sage-5.10.rc2/local/lib/python2.7/site-packages/sage/interfaces/interface.py", line 626, in __init__
        raise TypeError, x
    TypeError: ECL says: Error executing code in Maxima: Unable to find the spectral representation
**********************************************************************

jdemeyer · 2013-06-13T09:36:17Z

comment:16

Also

sage -t devel/sage/sage/interfaces/maxima.py  # Time out

due to a timeout of

sage: maxima('limit(x^a,x,0)')

This is fixable, it is because of a slightly different output format of assumptions.

jdemeyer · 2013-06-13T09:58:08Z

Changed upstream from Fixed upstream, but not in a stable release. to none

kcrisman · 2013-06-13T14:13:29Z

comment:18

That is awesome, thanks for checking this, Jeroen.

kcrisman · 2013-06-18T18:30:29Z

comment:19

This is fixable, it is because of a slightly different output format of assumptions.

Jeroen, while it's true that the error is slightly different in format, I don't think this is the problem (or at least not the whole one). The other things are still passing doctests, and we never even get to the

           if i > 0:
                v = self._expect.before

branch, as one can verify by inserting print statements.

This looks problematic:

This is #2400 again, to some extent. Not sure why this doesn't work any more. In Maxima 5.29.1, this is fine.

Maxima 5.29.1 http://maxima.sourceforge.net
using Lisp ECL 12.12.1
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) m: matrix([%i*%pi]);
(%o1)                             [ %i %pi ]
(%i4) matrixexp(m), keepfloat:true;
(%o4)                                 - 1
(%i5) matrixexp(m),keepfloat:false;
(%o5)                                 - 1

which is good. In 5.30, though, we have

(%i1) m: matrix([%i*%pi]);
(%o1)                             [ %i %pi ]
(%i6) matrixexp(m),keepfloat:true;

Unable to find the spectral representation
 -- an error. To debug this try: debugmode(true);
(%i7) matrixexp(m),keepfloat:false;

Unable to find the spectral representation
 -- an error. To debug this try: debugmode(true);

kcrisman · 2013-06-18T18:37:43Z

Changed keywords from none to sd48

kcrisman · 2013-06-18T18:38:58Z

comment:21

Note that the spkg changes are not committed.

kcrisman · 2013-06-19T13:44:13Z

Changed dependencies from #13364 to none

kcrisman · 2013-06-19T13:44:13Z

Upstream: Reported upstream. Developers acknowledge bug.

kcrisman · 2013-06-19T13:44:13Z

comment:22

Thanks to Barton Willis for this workaround.

This bug is due to circa January 2013 changes to matrix inversion. A workaround is to set ratmx to true:

Maxima branch_5_30_base_98_g29f9239_dirty http://maxima.sourceforge.net
using Lisp Clozure Common Lisp Version 1.9-r15764  (WindowsX8632)

(%i1) matrixexp(matrix([%i*%pi]));

Unable to find the spectral representation

(%i2) matrixexp(matrix([%i*%pi])), ratmx=true;
(%o2)                                 - 1

I've reported this here. I don't know if doing this ratmx thing universally is good, though:

 if FALSE will cause determinant and matrix addition, subtraction, and multiplication to be performed in the representation of the matrix elements and will cause the result of matrix inversion to be left in general representation. If it is TRUE, the 4 operations mentioned above will be performed in CRE form and the result of matrix inverse will be in CRE form. Note that this may cause the elements to be expanded (depending on the setting of RATFAC) which might not always be desired.

mezzarobba · 2014-05-23T12:46:50Z

comment:41

sage -t --long src/sage/interfaces/maxima_lib.py
**********************************************************************
File "src/sage/interfaces/maxima_lib.py", line 702, in sage.interfaces.maxima_lib.MaximaLib.sr_integral
Failed example:
    integrate(cos(x + abs(x)), x)
Expected:
    -1/4*(2*x - sin(2*x))*realpart(sgn(x)) + 1/2*x + 1/4*sin(2*x)
Got:
    -1/4*(2*x - sin(2*x))*real_part(sgn(x)) + 1/2*x + 1/4*sin(2*x)
**********************************************************************

This is with Volker's current develop branch on github (d409685), which includes a few dozens new tickets compared to 6.3.beta1.

sagetrac-git · 2014-05-23T13:05:24Z

Changed commit from 13d48c2 to a130eed

sagetrac-git · 2014-05-23T13:05:24Z

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

`a130eed`	`Trac 13973: realpart should be real_part`

pjbruin · 2014-05-23T13:05:51Z

comment:43

Thanks, that must be a consequence of #16224.

kcrisman · 2014-05-23T13:46:38Z

comment:44

Thanks, that must be a consequence of #16224.

So... did we have an incorrect translation of Maxima's realpart all along? Interesting.

mezzarobba · 2014-05-23T15:11:14Z

comment:45

Is there a reason for no longer using z... in the following test?

@@ -9231,7 +9231,7 @@ cdef class Expression(CommutativeRingElement):
             sage: from sage.calculus.calculus import maxima
             sage: sol = maxima(cos(x)==0).to_poly_solve(x)
             sage: sol.sage()
-            [[x == -1/2*pi + 2*pi*z...], [x == 1/2*pi + 2*pi*z...]]
+            [[x == 1/2*pi + pi*z82]]
 
         If a returned unsolved expression has a denominator, but the
         original one did not, this may also be true::

The same comment may apply to z[0-9]+ in

src/sage/interfaces/maxima_lib.py:            [[x == pi*z54]]
src/sage/symbolic/relation.py:        [[x == 1/4*pi + pi*z80, y == -1/4*pi - pi*z80]]

The bugs listed in the description indeed appear to be fixed with the update, except #13733, for which I get:

sage: integral(log(cot(x)-1),x,0,pi/4)
...
RuntimeError: ECL says: Error executing code in Maxima: PSLOG: internal error.

Otherwise looks good to me.

pjbruin · 2014-05-23T17:26:47Z

comment:46

Replying to @mezzarobba:

Is there a reason for no longer using z... in the following test?

Mostly readability (since the tests are also part of the documentation); with the ... it is not clear that it is just a "serial number" and not part of a larger expression that has been left out. Of course it is somewhat random, so it may change once in a while with Maxima upgrades or changes in other doctests in the same file. I personally think displaying a complete answer is worth the trouble of having to change it every now and then, but if you insist I can change all such examples to ....

The bugs listed in the description indeed appear to be fixed with the update, except #13733, for which I get:
sage: integral(log(cot(x)-1),x,0,pi/4)
...
RuntimeError: ECL says: Error executing code in Maxima: PSLOG: internal error.

You're right; I tested this inside Maxima (sage --maxima), but Sage loads additional packages. In this case the failure is caused by loading abs_integrate. Using 5.33.0:

$ sage --maxima
...
(%i1) display2d: false$

(%i2) integrate(log(cot(x)-1),x,0,%pi/4);

(%o2) (%i*li[2]((%i+1)/2)-%i*li[2](-(%i-1)/2))/2
 -(%i*(2*li[2](%i+1)-2*li[2](1-%i))+%pi*log(2))/4
(%i3) load(abs_integrate)$

(%i4) integrate(log(cot(x)-1),x,0,%pi/4);

log: encountered log(0).
log: encountered log(0).
log: encountered log(0).
log: encountered log(0).
log: encountered log(0).
log: encountered log(0).
log: encountered log(0).
log: encountered log(0).
log: encountered log(0).
PSLOG: internal error.
 -- an error. To debug this try: debugmode(true);

mezzarobba · 2014-05-23T17:46:45Z

Reviewer: Marc Mezzarobba

mezzarobba · 2014-05-23T17:46:45Z

Changed upstream from Completely fixed; Fix reported upstream to none

mezzarobba · 2014-05-23T17:46:45Z

comment:47

Replying to @pjbruin:

Replying to @mezzarobba:

Is there a reason for no longer using z... in the following test?

Mostly readability (since the tests are also part of the documentation); with the ... it is not clear that it is just a "serial number" and not part of a larger expression that has been left out. Of course it is somewhat random, so it may change once in a while with Maxima upgrades or changes in other doctests in the same file. I personally think displaying a complete answer is worth the trouble of having to change it every now and then, but if you insist I can change all such examples to ....

No, that's fine with me, I just wanted to make sure that it was intentional.

vbraun · 2014-05-25T17:31:52Z

Changed branch from u/pbruin/13973-maxima_update to a130eed

kcrisman · 2014-06-04T13:40:11Z

comment:49

Note about the patches: maxima_bug_2526.patch, which fixes http://sourceforge.net/p/maxima/bugs/2526/, is still necessary even though the bug is marked "closed" in the Maxima bug tracking system; the commit somehow didn't make it into the Maxima repository.

Okay, this is finally in Maxima, so the next Maxima upgrade will get to remove this patch.

kcrisman · 2014-06-04T13:40:11Z

Changed commit from a130eed to none

kcrisman · 2014-06-04T13:55:50Z

comment:50

#14306 needs review.

dimpase added this to the sage-5.10 milestone Jan 19, 2013

dimpase added c: packages: standard labels Jan 19, 2013

This comment has been minimized.

Sign in to view

jdemeyer modified the milestones: sage-5.10, sage-5.11 Jun 13, 2013

This comment has been minimized.

Sign in to view

mezzarobba added s: needs work and removed s: needs review labels May 23, 2014

pjbruin added s: needs review and removed s: needs work labels May 23, 2014

This comment has been minimized.

Sign in to view

mezzarobba added s: positive review and removed s: needs review labels May 23, 2014

vbraun removed the s: positive review label May 25, 2014

vbraun closed this as completed in 6220027 May 25, 2014

sagetrac-tmonteil mannequin mentioned this issue Jun 2, 2014

problems with infinite sum #11894

Closed

sagetrac-pang mannequin mentioned this issue Jun 2, 2014

simple incorrect limit #13526

Closed

burcin mentioned this issue May 30, 2014

wrong evaluation of infinite sum #13712

Closed

pipedream mentioned this issue Jun 2, 2014

Extra assumption kept by Maxima #14209

Closed

sagetrac-JGuzman mannequin mentioned this issue Aug 16, 2014

Wrong limit value of expression involving gamma function #15033

Closed

pjbruin mentioned this issue May 17, 2014

work around Maxima fpprintprec bug and other ARM-specific problems #15921

Closed

slel mentioned this issue Jan 29, 2023

Maxima SPKG: eliminate matrixexp.patch #32898

Closed

Upgrade Maxima to 5.33.0 #13973

Upgrade Maxima to 5.33.0 #13973

Comments

dimpase commented Jan 19, 2013

kcrisman commented Jan 20, 2013

kcrisman commented Jan 20, 2013

zimmermann6 commented Jan 23, 2013

dimpase commented Jan 23, 2013

zimmermann6 commented Jan 23, 2013

dimpase commented Jan 23, 2013

zimmermann6 commented Jan 23, 2013

zimmermann6 commented May 7, 2013

kcrisman commented May 8, 2013

kiwifb commented May 8, 2013

jdemeyer commented Jun 13, 2013

jdemeyer commented Jun 13, 2013

This comment has been minimized.

This comment has been minimized.

jdemeyer commented Jun 13, 2013

jdemeyer commented Jun 13, 2013

jdemeyer commented Jun 13, 2013

kcrisman commented Jun 13, 2013

kcrisman commented Jun 18, 2013

kcrisman commented Jun 18, 2013

kcrisman commented Jun 18, 2013

kcrisman commented Jun 19, 2013

kcrisman commented Jun 19, 2013

kcrisman commented Jun 19, 2013

mezzarobba commented May 23, 2014

sagetrac-git mannequin commented May 23, 2014

sagetrac-git mannequin commented May 23, 2014

pjbruin commented May 23, 2014

kcrisman commented May 23, 2014

mezzarobba commented May 23, 2014

This comment has been minimized.

pjbruin commented May 23, 2014

mezzarobba commented May 23, 2014

mezzarobba commented May 23, 2014

mezzarobba commented May 23, 2014

vbraun commented May 25, 2014

kcrisman commented Jun 4, 2014

kcrisman commented Jun 4, 2014

kcrisman commented Jun 4, 2014