upgrade Maxima to version >= 5.39

[dimpase]

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

• get Maxima 5.39.0 tarball ​here

[fbissey]

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.

[fbissey]

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]

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]

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]

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.

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

[fbissey]

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

[dimpase]

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.

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

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

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]

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

[dimpase]

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.

[dimpase]

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

to hopefully sort out the ECL autotools mess.

[fbissey]

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.

[fbissey]

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]

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.

[git]

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.

[git]

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

​82fdf0e

ported maxima patches; tarball needs bootstrapping; trivial doctests fix

[dimpase]

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]

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]

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

[git]

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

​0d0649a

some easy doctest fixes

[jdemeyer]

This is bad:

build/pkgs/maxima/spkg-install

@@ -47 +47 @@
 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]

Replying to dimpase:

spkg-src is outdated anyway.

[citation needed]

[dimpase]

Replying to jdemeyer:

This is bad:

build/pkgs/maxima/spkg-install

@@ -47 +47 @@
 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]

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]

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]

New commits:

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

[dimpase]

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

[dimpase]

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]

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]

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]

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]

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]

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.

[pbruin]

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.

[pbruin]

Upstream bug report: ​https://sourceforge.net/p/maxima/bugs/3008/

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

[pbruin]

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.

[tscrim]

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?

[dimpase]

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

[thansen]

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.

[fbissey]

Dima, can you rebase your branch?

[dimpase]

Will try later today.

[dimpase]

rebased the relevant patches

---

New commits:

​ee327bc	ported maxima patches; tarball needs bootstrapping; trivial doctests fix
​2310020	some easy doctest fixes

[dimpase]

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.

[fbissey]

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

[git]

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

​a4bf716

rebased patches, added eigenvectors patch too

[dimpase]

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.

[git]

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

​62b5825

some more easy doctest fixes

[dimpase]

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:

​62b5825

some more easy doctest fixes

[dimpase]

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.

[dimpase]

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

[dimpase]

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.

[dimpase]

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.

[git]

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

​9ef994d

more easy doctest fixes

[dimpase]

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.

[git]

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

​3c28022

more easy doctest fixes

[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/

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

[git]

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

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

[dimpase]

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

[git]

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

​79eb82f	fix for maxima bug #3236
​814e8ed	reflect patch's dependence on an earlier maxima tree commit

[git]

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

​af7e5ff

new scaling of dynatomic polynomial

[dimpase]

Replying to git:

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

​5d86413	Merge branch 'public/t18920' of trac.sagemath.org:sage into max5381
​100d9d6	workaround 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?

[tscrim]

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

[jpflori]

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

[jpflori]

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

[dimpase]

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.

[fbissey]

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.

[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:

• ​https://git.sagemath.org/sage.git/tree/build/pkgs/maxima/patches/0001-taylor2-Avoid-blowing-the-stack-when-diff-expand-isn.patch
• ​https://git.sagemath.org/sage.git/tree/build/pkgs/maxima/patches/matrixexp.patch

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

[dimpase]

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:

• ​https://git.sagemath.org/sage.git/tree/build/pkgs/maxima/patches/0001-taylor2-Avoid-blowing-the-stack-when-diff-expand-isn.patch

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)

• ​https://git.sagemath.org/sage.git/tree/build/pkgs/maxima/patches/matrixexp.patch

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

again, upstream still has it open.

[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
**********************************************************************
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
**********************************************************************

[dimpase]

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.

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

[dimpase]

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.

[rws]

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.

[fbissey]

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

[jdemeyer]

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

[fbissey]

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.

[dimpase]

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

[git]

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

​eff6081	update ECL to 16.1.3 - most of our patches are obsolete
​68da1e4	Merge branch 'public/t18920' of trac.sagemath.org:sage into ecl1613
​6bae4b1	bumped up for 5.39.0. Sage builds (with ecl 16.1.3)

[dimpase]

On this branch, the following works at the prompt:

sage: K.<i> = NumberField(x^2+1)
sage: (6*i + 6).factor()
(-i) * (i + 1)^3 * 3

but crashes in testing:

Using --optional=mpir,python2,sage
Doctesting 1 file using 8 threads.
sage -t src/sage/rings/number_field/number_field_element.pyx
**********************************************************************
File "src/sage/rings/number_field/number_field_element.pyx", line 1752, in sage.rings.number_field.number_field_element.NumberFieldElement.factor
Failed example:
    (6*i + 6).factor()
Exception raised:
    Traceback (most recent call last):
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 498, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 861, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.rings.number_field.number_field_element.NumberFieldElement.factor[1]>", line 1, in <module>
        (Integer(6)*i + Integer(6)).factor()
      File "sage/rings/number_field/number_field_element.pyx", line 1782, in sage.rings.number_field.number_field_element.NumberFieldElement.factor (build/cythonized/sage/rings/number_field/number_field_element.cpp:19881)
        if not P.is_principal():
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/number_field/number_field_ideal.py", line 1115, in is_principal
        self._cache_bnfisprincipal(proof)
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/number_field/number_field_ideal.py", line 1058, in _cache_bnfisprincipal
        bnf = self.number_field().pari_bnf(proof)
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/number_field/number_field.py", line 3603, in pari_bnf
        self._pari_bnf = f.bnfinit(1)
      File "sage/libs/cypari2/auto_gen.pxi", line 2984, in sage.libs.cypari2.gen.gen_auto.bnfinit (build/cythonized/sage/libs/cypari2/gen.c:17894)
        sig_on()
      File "src/cysignals/signals.pyx", line 105, in cysignals.signals.sig_raise_exception (build/src/cysignals/signals.c:1519)
    FloatingPointError: Floating point exception
**********************************************************************
1 item had failures:
   1 of   8 in sage.rings.number_field.number_field_element.NumberFieldElement.factor
    [1051 tests, 1 failure, 10.88 s]
----------------------------------------------------------------------
sage -t src/sage/rings/number_field/number_field_element.pyx  # 1 doctest failed

Looks like the testing environment is a bit shot, but I cannot figure out why.

[dimpase]

here we get fp exception instead of ArithmeticError

File "src/sage/arith/misc.py", line 2696, in sage.arith.misc.is_squarefree
Failed example:
    is_squarefree(a - 3)
Expected:
    Traceback (most recent call last):
    ...
    ArithmeticError: non-principal ideal in factorization
Got:
    <BLANKLINE>
    Traceback (most recent call last):
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 498, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 861, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.arith.misc.is_squarefree[13]>", line 1, in <module>
        is_squarefree(a - Integer(3))
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/arith/misc.py", line 2711, in is_squarefree
        return all(r[1] == 1 for r in factor(n))
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/arith/misc.py", line 2479, in factor
        return n.factor(**kwds)
      File "sage/rings/number_field/number_field_element.pyx", line 1782, in sage.rings.number_field.number_field_element.NumberFieldElement.factor (build/cythonized/sage/rings/number_field/number_field_element.cpp:19881)
        if not P.is_principal():
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/number_field/number_field_ideal.py", line 1115, in is_principal
        self._cache_bnfisprincipal(proof)
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/number_field/number_field_ideal.py", line 1058, in _cache_bnfisprincipal
        bnf = self.number_field().pari_bnf(proof)
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/number_field/number_field.py", line 3603, in pari_bnf
        self._pari_bnf = f.bnfinit(1)
      File "sage/libs/cypari2/auto_gen.pxi", line 2984, in sage.libs.cypari2.gen.gen_auto.bnfinit (build/cythonized/sage/libs/cypari2/gen.c:17894)
        sig_on()
      File "src/cysignals/signals.pyx", line 105, in cysignals.signals.sig_raise_exception (build/src/cysignals/signals.c:1519)
    FloatingPointError: Floating point exception

[dimpase]

Is the following a regression in Maxima?:

sage -t --warn-long 87.4 src/sage/symbolic/expression.pyx
**********************************************************************
File "src/sage/symbolic/expression.pyx", line 10600, in sage.symbolic.expression.Expression.solve
Failed example:
    solve(Q*sqrt(Q^2 + 2) - 1, Q, to_poly_solve=True)
Expected:
    [Q == 1/sqrt(-sqrt(2) + 1), Q == 1/sqrt(sqrt(2) + 1)]
Got:
    [Q == -sqrt(-sqrt(2) - 1)]

[dimpase]

The following works at the prompt:

sage: F.<omega> = NumberField(x^2+x+1)
sage: xx = polygen(F)
sage: ps = [p for p, _ in F(7).factor()]
sage: ps
[-3*omega - 2, 3*omega + 1]

but crashes in testing:

sage -t --warn-long 87.4 src/sage/rings/number_field/number_field.py
**********************************************************************
File "src/sage/rings/number_field/number_field.py", line 1246, in sage.rings.number_field.number_field.NumberField_generic
Failed example:
    ps = [p for p, _ in F(7).factor()]
Exception raised:
    Traceback (most recent call last):
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 498, in _run
        self.compile_and_execute(example, compiler, test.globs)
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/doctest/forker.py", line 861, in compile_and_execute
        exec(compiled, globs)
      File "<doctest sage.rings.number_field.number_field.NumberField_generic[43]>", line 1, in <module>
        ps = [p for p, _ in F(Integer(7)).factor()]
      File "sage/rings/number_field/number_field_element.pyx", line 1782, in sage.rings.number_field.number_field_element.NumberFieldElement.factor (build/cythonized/sage/rings/number_field/number_field_element.cpp:19881)
        if not P.is_principal():
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/number_field/number_field_ideal.py", line 1115, in is_principal
        self._cache_bnfisprincipal(proof)
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/number_field/number_field_ideal.py", line 1058, in _cache_bnfisprincipal
        bnf = self.number_field().pari_bnf(proof)
      File "/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/number_field/number_field.py", line 3603, in pari_bnf
        self._pari_bnf = f.bnfinit(1)
      File "sage/libs/cypari2/auto_gen.pxi", line 2984, in sage.libs.cypari2.gen.gen_auto.bnfinit (build/cythonized/sage/libs/cypari2/gen.c:17894)
        sig_on()
      File "src/cysignals/signals.pyx", line 105, in cysignals.signals.sig_raise_exception (build/src/cysignals/signals.c:1519)
    FloatingPointError: Floating point exception

[dimpase]

This works at the prompt (with a good plot, too):

sage: plot(bessel_Y(1,x), (x,0,5), color='blue')
Launched png viewer for Graphics object consisting of 1 graphics primitive

but dumps core in testing:

sage -t src/sage/functions/bessel.py
...

sage: plot(bessel_Y(1,x), (x,0,5), color='blue') ## line 513 ##
------------------------------------------------------------------------
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x4495)[0x7f677f921495]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x44e5)[0x7f677f9214e5]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x7e38)[0x7f677f924e38]
/lib64/libpthread.so.0(+0x10a00)[0x7f678c3d2a00]
/home/scratch/dimpase/sage/sage/local/lib/libmpfr.so.4(mpfr_get_d+0x217)[0x7f6774bafd97]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/rings/real_mpfr.so(+0x11bd7)[0x7f6578157bd7]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyNumber_Float+0x2b)[0x7f678c6335cb]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x82ed5)[0x7f678c662ed5]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0xbeae3)[0x7f678c69eae3]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/libs/mpmath/utils.so(+0x765e)[0x7f6577a9265e]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/libs/mpmath/utils.so(+0xe0ee)[0x7f6577a990ee]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7ce1)[0x7f678c6ec461]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x85e4d)[0x7f678c665e4d]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x65f7c)[0x7f678c645f7c]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/symbolic/function.so(+0xad3f)[0x7f655d2b8d3f]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/symbolic/function.so(+0x23cd1)[0x7f655d2d1cd1]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/symbolic/function.so(+0xad3f)[0x7f655d2b8d3f]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/symbolic/function.so(+0x2a868)[0x7f655d2d8868]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_CallObjectWithKeywords+0x47)[0x7f678c6e4187]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/ext/interpreters/wrapper_py.so(interp_py+0x398)[0x7f654092e1a8]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/ext/interpreters/wrapper_py.so(+0x391b)[0x7f654091e91b]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x56da)[0x7f678c6e9e5a]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x85e4d)[0x7f678c665e4d]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x18aa)[0x7f678c6e602a]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x85e4d)[0x7f678c665e4d]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x18aa)[0x7f678c6e602a]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x85e4d)[0x7f678c665e4d]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/symbolic/expression.so(+0x1a03f)[0x7f655dde203f]
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/sage/symbolic/expression.so(+0x343de)[0x7f655ddfc3de]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x625b)[0x7f678c6ea9db]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x85e4d)[0x7f678c665e4d]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x18aa)[0x7f678c6e602a]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f678c6ee139]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x7428)[0x7f678c6ebba8]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x85d7c)[0x7f678c665d7c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x65f7c)[0x7f678c645f7c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0xc20b5)[0x7f678c6a20b5]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x56da)[0x7f678c6e9e5a]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8271)[0x7f678c6ec9f1]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x85d7c)[0x7f678c665d7c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0x65f7c)[0x7f678c645f7c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0xc24fd)[0x7f678c6a24fd]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(+0xbeb2f)[0x7f678c69eb2f]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyObject_Call+0x43)[0x7f678c634c13]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x56da)[0x7f678c6e9e5a]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8271)[0x7f678c6ec9f1]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalFrameEx+0x8020)[0x7f678c6ec7a0]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCodeEx+0x81c)[0x7f678c6ee01c]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyEval_EvalCode+0x19)[0x7f678c6ee139]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyRun_FileExFlags+0x8a)[0x7f678c7121da]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(PyRun_SimpleFileExFlags+0xd7)[0x7f678c713587]
/home/scratch/dimpase/sage/sage/local/lib/libpython2.7.so.1.0(Py_Main+0xc3e)[0x7f678c729c4e]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f678b918580]
python(_start+0x29)[0x400759]
------------------------------------------------------------------------
Attaching gdb to process id 25288.

Saved trace to /home/scratch/dimpase/.sage/crash_logs/crash_vEDCJn.log
------------------------------------------------------------------------
Unhandled SIGFPE: An unhandled floating point exception occurred.
This probably occurred because a *compiled* module has a bug
in it and is not properly wrapped with sig_on(), sig_off().
Python will now terminate.
------------------------------------------------------------------------

**********************************************************************
----------------------------------------------------------------------
sage -t src/sage/functions/bessel.py  # Killed due to floating point exception

[dimpase]

I think I need an idea what's wrong here, before being able to go forward. This discrepancy between testsuite vs prompt is really odd.

[git]

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

​44da831

version number in tests

[dimpase]

here is a bad one - reproducible on two different systems; I don't understand what's going on here; it appears that computing g(x), the Taylor expansion of log(x), breaks log(x) plotting (in case the leftmost interval point is 0).

Probably this initialises some symbolics, breaking handling of inifinity in the process...

sage: plot(log(x),(x,0,2))
Launched png viewer for Graphics object consisting of 1 graphics primitive
sage: g(x)=taylor(log(x),x,1,6); g
x |--> -1/6*(x - 1)^6 + 1/5*(x - 1)^5 - 1/4*(x - 1)^4 + 1/3*(x - 1)^3 - 1/2*(x - 1)^2 + x - 1
sage: plot(log(x),(x,0,2))
------------------------------------------------------------------------
/home/scratch/dimpase/sage/sage/local/lib/python2.7/site-packages/cysignals/signals.so(+0x4495)[0x7f5dbb0d9495]
[...]
------------------------------------------------------------------------
Unhandled SIGFPE: An unhandled floating point exception occurred.
This probably occurred because a *compiled* module has a bug
in it and is not properly wrapped with sig_on(), sig_off().
Python will now terminate.

---

New commits:

​44da831

version number in tests

[dimpase]

Replying to dimpase:

here is a bad one - reproducible on two different systems; I don't understand what's going on here; it appears that computing g(x), the Taylor expansion of log(x), breaks log(x) plotting (in case the leftmost interval point is 0).

Probably this initialises some symbolics, breaking handling of infinity in the process...

Further entry point - the crash does not happen if I revert back to ECL 16.1.2. (and keep new Maxima version). That is, it seems that the call to taylor loads ecl+maxima, and sets up some stuff that is responsible for handling infinities.

[fbissey]

I think a number of things point back to ecl-16.1.3 so it may belong to #22191. I remember having a lot of similar stuff when changing just ecl without change maxima (still need a rebuild though) in sage-on-gentoo. Right now I am just locked on 16.1.2.

[git]

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

​ac8348c	disable SIGFPE traps
​530a89e	Merge branch 'public/t18920' of trac.sagemath.org:sage into ecl1613

[dimpase]

the last commit appears to fix the SIGFPE problem. More testing...

[git]

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

​1b821c4

easy doctest fixes

[dimpase]

still a couple of SIGFPEs to figure out, but otherwise does not look too bad. I'll post ptestlong results later today.

[dimpase]

SIGFPEs are of the same sort as above:

sage: g(x)=taylor(log(x),x,1,6) # this initialises ECL/Maxima
sage: q = (2^53) * 2^971/1
sage: float(q) # boom, instead of "inf" as the answer.
...
Unhandled SIGFPE: An unhandled floating point exception occurred.
...

which I traced down to the call to ldexp at sage/rings/rational.pyx:3799. Note that this is with ​ac8348c commit already in (and so ECL_OPT_TRAP_SIGFPE = 0), so there is more of the same kind of story as above, but harder. I don't see what's going wrong here now.

This is a different to division by 0 kind of FPE, so this is perhaps the reason.

[dimpase]

ecl-16.1.3+Maxima 5.39.0

[dimpase]

I've decided to stick to ECL 16.1.2 for this ticket. (ECL 16.1.3 has a problem that cannot be fixed quickly, and benefits of using it here are pretty minimal).

---

Last 10 new commits:

​4163ef8	rebased patches, added eigenvectors patch too
​5b9a7af	some more easy doctest fixes
​da15a6d	more easy doctest fixes
​4ea0e8e	workaround for #<a ARITHMETIC-ERROR> (18920#comment:60
​7c7a0f3	fix for maxima bug #3236
​4377282	reflect patch's dependence on an earlier maxima tree commit
​29f595a	new scaling of dynatomic polynomial
​7577f86	bumped up for 5.39.0. Sage builds (with ecl 16.1.3)
​759104a	version number in tests
​9450861	easy doctest fixes

[git]

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

​3e1dcef

few more easy fixes

[dimpase]

With this branch, the following remains to be fixed (or marked as known bugs):

1) this appears to be a Maxima regression ​bug report:

sage -t src/sage/symbolic/expression.pyx
******************************************************************
****
File "src/sage/symbolic/expression.pyx", line 10600, in sage.symbo
lic.expression.Expression.solve
Failed example:
    solve(Q*sqrt(Q^2 + 2) - 1, Q, to_poly_solve=True)
Expected:
    [Q == 1/sqrt(-sqrt(2) + 1), Q == 1/sqrt(sqrt(2) + 1)]
Got:
    [Q == -sqrt(-sqrt(2) - 1)]

2) this is weird (sage interface problem?) --- scratch this, it's a typo!

sage -t 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
**********************************************************************

3) this looks like a maxima regression ​bug report:

sage -t 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*dilog(-x^2 + 1)
Got:
    log(-x)*log(x + 1) + log(x)*log(-x + 1) + dilog(x + 1) + dilog(-x + 1)

4) this is a known Maxima issue ​bug report:

sage -t src/sage/interfaces/maxima_lib.py
******************************************************************
****
File "src/sage/interfaces/maxima_lib.py", line 724, in sage.interf
aces.maxima_lib.MaximaLib.sr_integral
Failed example:
    integrate(1 / (1 + abs(x-5)), x, -5, 6)
Exception raised:
...
    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
**********************************************************************

[git]

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

​f7448ef	some more easy doctest fixes
​81463e2	more easy doctest fixes
​386e276	workaround for #<a ARITHMETIC-ERROR> (18920#comment:60
​a0cd5d4	fix for maxima bug #3236
​5594310	reflect patch's dependence on an earlier maxima tree commit
​c5358b4	new scaling of dynatomic polynomial
​92d1c59	bumped up for 5.39.0. Sage builds (with ecl 16.1.3)
​2dbe3cf	version number in tests
​efe9848	easy doctest fixes
​941b62c	few more easy fixes

[dimpase]

cleaned up the branch

[git]

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

​fbc2293

marked Maxima regressions: #18920, comment 108

[git]

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

​68a0ab2

one more format output change

[dimpase]

OK, all done, ready for review, at last.

[tscrim]

Instead of removing this doctest:

src/sage/symbolic/expression.pyx

@@ -10597 +10597 @@
             Q
             sage: solve(Q*sqrt(Q^2 + 2) - 1, Q)
             [Q == 1/sqrt(Q^2 + 2)]
+
+        The following example is a regression in Maxima 5.39.0,
+        it used to be possible to get 2 solutions here, see
+        https://sourceforge.net/p/maxima/bugs/3276/::
+
             sage: solve(Q*sqrt(Q^2 + 2) - 1, Q, to_poly_solve=True)
-            [Q == 1/sqrt(-sqrt(2) + 1), Q == 1/sqrt(sqrt(2) + 1)]
+            [Q == -sqrt(-sqrt(2) - 1)]
 
         In some cases there may be infinitely many solutions indexed
         by a dummy variable.  If it begins with ``z``, it is implicitly

I would instead mark the previous solution as # known bug or at least keep the solution. Same in calculus/tests.py.

[charpent]

On Debian testing (Core i7 + 16 GB Ram), on a branch where R 3.2.2 is merged with the latest released Sage, a parallel test (MAKE="make -j8") gives :

----------------------------------------------------------------------
sage -t --long --warn-long 114.8 src/sage/tests/cmdline.py  # 2 doctests failed
sage -t --long --warn-long 114.8 src/sage/rings/polynomial/multi_polynomial_ideal.py  # 1 doctest failed
sage -t --long --warn-long 114.8 src/sage/interfaces/tests.py  # 1 doctest failed
sage -t --long --warn-long 114.8 src/sage/homology/simplicial_complex.py  # 1 doctest failed
sage -t --long --warn-long 114.8 src/sage/modules/free_module_element.pyx  # Timed out
----------------------------------------------------------------------

4 of these five are transient, and pass when run sandalone.

However:

charpent@asus16-ec:/usr/local/sage-7$ sage -t --long --warn-long 114.8 src/sage/rings/polynomial/multi_polynomial_ideal.py
Running doctests with ID 2017-01-18-16-59-41-26a3a809.
Git branch: testR
Using --optional=database_gap,giacpy_sage,mpir,python2,sage,xz
Doctesting 1 file.
sage -t --long --warn-long 114.8 src/sage/rings/polynomial/multi_polynomial_ideal.py
**********************************************************************
File "src/sage/rings/polynomial/multi_polynomial_ideal.py", line 3532, in sage.rings.polynomial.multi_polynomial_ideal.NCPolynomialIdeal.groebner_basis
Failed example:
    ideal(J.transformed_basis()).change_ring(P).interreduced_basis()  # optional - giacpy_sage
Expected:
    [a - 60*c^3 + 158/7*c^2 + 8/7*c - 1, b + 30*c^3 - 79/7*c^2 + 3/7*c, c^4 - 10/21*c^3 + 1/84*c^2 + 1/84*c]
Got:
    [7*a - 420*c^3 + 158*c^2 + 8*c - 7, 7*b + 210*c^3 - 79*c^2 + 3*c, 84*c^4 - 40*c^3 + c^2 + c]
**********************************************************************
1 item had failures:
   1 of  67 in sage.rings.polynomial.multi_polynomial_ideal.NCPolynomialIdeal.groebner_basis
    [727 tests, 1 failure, 9.29 s]
----------------------------------------------------------------------
sage -t --long --warn-long 114.8 src/sage/rings/polynomial/multi_polynomial_ideal.py  # 1 doctest failed
----------------------------------------------------------------------
Total time for all tests: 9.4 seconds
    cpu time: 15.5 seconds
    cumulative wall time: 9.3 seconds

This latter bug is known, not really a bug and has its own ticket.

Furthermore, Maxima 5.38.1 (Debian testing current version) fixes one of my pet peeves :

charpent@SAP5057241:~$ maxima

Maxima 5.38.1 http://maxima.sourceforge.net
using Lisp GNU Common Lisp (GCL) GCL 2.6.12
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) display2d:false;

(%o1) false
(%i2) integrate(f(x),x);

(%o2) 'integrate(f(x),x)
(%i3) taylor(integrate(f(x),x),x,x_0,2);

(%o3) 'at('integrate(f(x),x),x = x_0)+f(x_0)*(x-x_0)
                                     +(('at('diff(f(x),x,1),x = x_0))
                                      *(x-x_0)^2)
                                      /2

Whereas Sage's Maxima gives :

charpent@SAP5057241:~$ sage -maxima
;;; Loading #P"/usr/local/sage-7/local/lib/ecl/sb-bsd-sockets.fas"
;;; Loading #P"/usr/local/sage-7/local/lib/ecl/sockets.fas"
;;; Loading #P"/usr/local/sage-7/local/lib/ecl/defsystem.fas"
;;; Loading #P"/usr/local/sage-7/local/lib/ecl/cmp.fas"
Maxima 5.39.0 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) display2d:false;

(%o1) false
(%i2) integrate(f(x),x);         

(%o2) 'integrate(f(x),x)
(%i3) taylor(integrate(f(x),x),x,x_0,2);

taylor: unable to expand at a point specified in:
'integrate(f(x),x)
 -- an error. To debug this try: debugmode(true);

So, we have :

• already known problems with parallel testing ;
• one already reported and ticketed test failure ;
• one not already reported problem, that continues the previous behaviour of Maxima-in-Sage, whereas this behavior has been fixed in 5.38.1.

None of these seem to impede giving this ticket a positive_review. Which I'd do unless you think that the behavior of the taylor(integrate(...)...) should/could be fixed with this issue.

However, I think the objection of Thierry Scrim (?) valid, and I think it is more important, since it points out a case where Maxima's answer is incomplete. Hence ==>needs_work.

[rws]

Replying to dimpase:

4) this is a known Maxima issue ​bug report:

sage -t src/sage/interfaces/maxima_lib.py
******************************************************************
****
File "src/sage/interfaces/maxima_lib.py", line 724, in sage.interf
aces.maxima_lib.MaximaLib.sr_integral
Failed example:
    integrate(1 / (1 + abs(x-5)), x, -5, 6)
Exception raised:
...
    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
**********************************************************************

Actually I believe Maxima is not to blame here, and in the bug report the dev says "not technically incorrect". See #17892 for our symbolic limit ticket.

[git]

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

​0f2acfe

addressed the reviewers' concerns.

[paulmasson]

As a minor point, when reviewing documentation tickets I always ask that lines be kept to about the same length. I would appreciate if you could break the long lines here, especially in the tutorials. Thanks.

[charpent]

This time, three failures in a parallel ptestlong :

----------------------------------------------------------------------
sage -t --long --warn-long 110.0 src/sage/rings/polynomial/multi_polynomial_ideal.py  # 1 doctest failed
sage -t --long --warn-long 110.0 src/sage/homology/simplicial_complex.py  # 1 doctest failed
sage -t --long --warn-long 110.0 src/sage/graphs/generators/smallgraphs.py  # Timed out
----------------------------------------------------------------------

Olny the firs one persists when run standalone, and is our old aquaintance... The other two are transient (race conditions ?)

Since the explanation given in #22191 show that the problem I signaled before is in ECL's realm, not Maxima's, there is no reason not to give this a positive_review.

Aaaaahhhhh !

[vbraun]

Reviewer name missing

[tscrim]

Adding some other people who I recall contributing comments, but may not be comprehensive or conservative (i.e., add/subtract your name).

[vbraun]

public/maxima5390 doesn't exist... typo?

[dimpase]

what? so it did quietly vanish? IMHO the whole git tree is fcked:

$ git push trac HEAD:public/maxima5390bis 
error: unable to push to unqualified destination: public/maxima5390bis
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@trac.sagemath.org:sage.git'

EDIT: this went through on a 3rd attempt

[dimpase]

Could please a reviewer compare the new branch with the old one he has locally? E.g. as follows:

git fetch trac public/maxima5390bis
git diff FETCH_HEAD trac/public/maxima5390

if this diff returns nothing we're good to go.

[charpent]

I use git-trac (nice !...), so I did :

charpent@asus16-ec:/usr/local/sage-7$ git fetch trac public/maxima5390bis
Depuis git://trac.sagemath.org/sage
 * branch                  public/maxima5390bis -> FETCH_HEAD
charpent@asus16-ec:/usr/local/sage-7$ git diff FETCH_HEAD t/18920/public/maxima5390 
charpent@asus16-ec:/usr/local/sage-7$ 

So, unless I'm mistaken, "we're good to go"...

HTH,

[dimpase]

Thanks. Hope the branch will not be cut again...

[vbraun]

Fails to build, e.g. ​http://build.sagedev.org/#/builders/16/builds/8/steps/5/logs/maxima

[fbissey]

It says makeinfo not found. Great, we always had a few for maxima's documentation but I thought makeinfo was a requisite.

[vbraun]

Maybe there is a make target that doesn't build the texinfo docs?

[dimpase]

Replying to vbraun:

Fails to build, e.g. ​http://build.sagedev.org/#/builders/16/builds/8/steps/5/logs/maxima

I cannot find anything there, the interface is pretty impossible to use for me. Can I have a link to the log file I can download?

[dimpase]

Replying to vbraun:

Maybe there is a make target that doesn't build the texinfo docs?

I'd say, just add makeinfo to the list of pre-reqs. It has been necessary to have it to build Maxima for years, see e.g. ​https://sourceforge.net/p/maxima/bugs/2878/

And it looks like the latter Maxima ticket did not fix anything :-)

[dimpase]

something that has been a problem since Maxima 5.23 should not stop this ticket...

[fbissey]

I think we may have some workaround by touching the right file. It is not in the current spkg-install, so we have dropped it at some point. You are right to point to upstream that they have a regression. For info: ​https://github.com/sagemath/sage/commit/6656b7b171d83078bd55c3cceea0f45da517ded0

[vbraun]

Seriously, the buildbots don't have makeinfo installed

[dimpase]

Replying to fbissey:

I think we may have some workaround by touching the right file. It is not in the current spkg-install, so we have dropped it at some point. You are right to point to upstream that they have a regression. For info: ​https://github.com/sagemath/sage/commit/6656b7b171d83078bd55c3cceea0f45da517ded0

perhaps our workound + Maxima's workarond + no makeinfo == error... :)

I'll check this.

[dimpase]

I am not convinced whether it's at all possible to build Maxima 5.39.0 and its docs without makeinfo. We are on our own here, as the official upstream pre-req for the build includes autotools.

Instead of wasting time on this academic issue, I'd like to rather include makeinfo into Sage pre-reqs.

[dimpase]

I have opened a new ​Maxima ticket on the makeinfo question.

[charpent]

Replying to dimpase:

I am not convinced whether it's at all possible to build Maxima 5.39.0 and its docs without makeinfo. We are on our own here, as the official upstream pre-req for the build includes autotools.

Instead of wasting time on this academic issue, I'd like to rather include makeinfo into Sage pre-reqs.

Seconded, on basic principles :

[ The following rant is not gratuitous. It's just a lemma. Bear with me for a while... ]

Our "batteries included" so-called philosophy has pushed us to include more and more software of peripheral interest at best up to the point where Sage is now a small-scale, highly specialized Linux distribution.

This distribution is of great interest to sage builders (i. e. potential developpers). It is at best an hindrance (read "pain in the *ss") to what should be one of our primary targets : the potential users of Sage. And no, this cannot be restricted to research mathematicians specializing in number theory...

For example, going to the pain to build our own GCC collection seems to me pushing consistency exigences a bit too far. Requiring from an installer (i. e. potential developper) to take the pain to install a matching set of decently recent compilers does not sound too much to me.

Corollary : our binary tarballs/packages should be sound enough to satisfy the largest possible number of potential users. That means that our users should not be requested to install and manage a virtual machine setup, nor a complicated installation on "exotic" platforms. An undergraduate or even high school student, a practising engineer, etc... should be able to install a precompiled binary and go use Sage as he uses a word processor, without having to install a $#!+load of tools he/she'll never use for anything else.

Therefore, if we need autotools to build Maxima, let's use existing autotools distributions, and do not try to avoid it. Or maintaining our own port. Maintaining our ports should be limited to the cases where there is a mathematical reason to do so.

[ End of rant. Now for its consequences : ]

Therefore, I think that wiggling away from one more tool to build Sage amounts to trying to alleviate the load of developers. Which is the wrong target. Our primary goal should be to alleviate the load imposed on users.

Those two sets were largely overlapping in the begionning of Sage, which as long been targeted on a certain research community. This is no longer the case. Sage now needs a lot of users, able to report problems, if we want to be able to fix them.

So, in the present case, if autotools is needed to build Maxima, let's depend on it for building Sage. But users of a binary distribution of Sage should not have to bother themselves with that.

In other (shorter) words : I'm not bothered by one more build dependency, if I can lighten the run dependencies... This seems the case here.

Corollary : the time spent on arguing and nitpicking over autotools would have been better spent helping Eric Bray's Cygwin port cum Windows installer, which opens us a quite large pool of potential users...

[dimpase]

autotools are not needed to build Maxima, but makeinfo apparently is.

Perhaps one can build Maxima without makeinfo if autotools are available, I didn't check, for this is even more academic question... makeinfo is a very easy pre-req, as it is available on every system we build Sage on, and included in XCode too.

[git]

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

​0ee645a

Re-introduce the makeinfo workaround until upstream fix it again

[fbissey]

I think this is enough.

I have now re-introduced the makeinfo workaround and my logs says it is safe to use on a makeinfo-less system.

I appreciate the feeling Emmanuel but the place for it is sage-devel - of course nothing is likely to happen for it in the short term. The reality is now there are plenty of "user space" package management solution around (not so many when sage was started) and most of them do a better job than the sage packaging system. The other reality is those other packaging system usually don't play well with sage. We pick problems regularly from users with a default installation of brew on OS X for example.

[mkoeppe]

Replying to charpent:

So, in the present case, if autotools is needed to build Maxima, let's depend on it for building Sage. But users of a binary distribution of Sage should not have to bother themselves with that.

In other (shorter) words : I'm not bothered by one more build dependency, if I can lighten the run dependencies... This seems the case here.

Users of binary distributions of Sage should still be able to install optional and experimental packages. Since there is no binary distribution of optional packages, build-time tools need to be included.

I would propose to add a standard package that includes (a current version of) texinfo (which provides makeinfo). Note that our autotools spkg packages only an ancient version of texinfo (4.13) (see #21196 for a discussion).

[pbruin]

Replying to dimpase:

autotools are not needed to build Maxima, but makeinfo apparently is.

It should not be; the bug is that the necessary TeX files are not included in the tarball. Even if the user does not have makeinfo, there should be no problem because the configure script will set $(MAKEINFO) to a command that does nothing. There is at least one place where a Maxima makefile uses makeinfo instead of $(MAKEINFO). In #17514 I fixed this specific one, but I seem to remember another problem of this kind in newer Maxima versions. Anyway, the only way to really fix this is if the Maxima developers make sure that all TeX files are in the distribution.

[fbissey]

I have got a funny failing doctest in sage-on-gentoo but I am not completely sure this ticket is responsible (I am testing from the current develop branch of Volker's fork where he is testing this now)

sage -t --long /usr/lib64/python2.7/site-packages/sage/functions/special.py
**********************************************************************
File "/usr/lib64/python2.7/site-packages/sage/functions/special.py", line 232, in sage.functions.special.SphericalHarmonic._eval_
Failed example:
    spherical_harmonic(3,2,1,2*pi/3)
Expected:
    1/240*sqrt(30)*(-15*I*sqrt(7)*sqrt(3)
     - 15*sqrt(7))*cos(1)*sin(1)^2/sqrt(pi)
Got:
    -1/240*sqrt(30)*(15*I*sqrt(7)*sqrt(3) + 15*sqrt(7))*cos(1)*sin(1)^2/sqrt(pi)
**********************************************************************

As you can see they are actually identical...

[vbraun]

I get the same on the buildbot....

[fbissey]

All bots or a mixture?

[vbraun]

all

[fbissey]

Doctest introduced by #20939 merged in 7.6.beta0, that's why it was missed. The branch needs re-basing before it can be fixed. Incoming.

[dimpase]

Please go on with this. I have negative amount of time available till the end of the week.

[git]

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

​71c0cea	Merge branch 'develop' into maxima5390bis
​a6c51e6	fix failing doctest introduced by #20939

[fbissey]

Definitely, not waiting for you. Here we go again, straight to positive review.