Re: RFS: maxima (NMU)
Ondrej Certik
> Dear mentors,
>
> Apparently due to problems with GCL, maxima currently either fails to
> build (474909) or builds but fails its test suite (489871).
>
> I have prepared an NMU changing the underlying lisp to SBCL. This is
> semantically quite intrusive, but according to upstream SBCL is one of
> the dialects of common lisp they test with.
>
> If you want to get a handle on how intrusive the patch is in terms of lines changed,
> you can have a look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474909#27
>
> The resulting package is not perfect of course, but I think it is
> better than what we have now (which, AFAIKT, is no maxima in lenny).
> Two issues in particular:
>
> 1) The documentation index is read into lisp and the system redumped. This makes the image
> about 1M bigger than required (OTOH, it is already 43M).
> 2) there is now versioned dependency on SBCL, since the core format turns out to be
> unstable from release to release.
>
> If you prefer, you can grab a copy of my packaging vcs:
>
> git clone alioth.debian.org:/git/debian-science/packages/maxima
>
> The latter can be built with
>
> git-buildpackage --git-ignore-new
>
> It builds these binary packages: maxima - A computer algebra system --
> base system maxima-doc - A computer algebra system -- documentation
> maxima-emacs - A computer algebra system -- emacs interface
> maxima-share - A computer algebra system -- extra code maxima-src - A
> computer algebra system -- source code maxima-test - A computer
> algebra system -- test suite xmaxima - A computer algebra system -- x
> interface
>
> The upload would fix these bugs: 474909, 489871
>
> The package can be found on mentors.debian.net:
> - URL: http://mentors.debian.net/debian/pool/main/m/maxima
> - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free
> - dget http://mentors.debian.net/debian/pool/main/m/maxima/maxima_5.13.0-3.2.dsc
>
> I would be glad if someone uploaded this package for me.
CCing to debian-sage.
Ondrej
mabshoff
Hi
I assume NMU == non maintainer update. You Debian people need to take
it easy with the acronyms in "public" :)
> On Sat, Jul 26, 2008 at 7:36 PM, David Bremner <brem...@unb.ca> wrote:
> > Dear mentors,
>
> > Apparently due to problems with GCL, maxima currently either fails to
> > build (474909) or builds but fails its test suite (489871).
>
> > I have prepared an NMU changing the underlying lisp to SBCL. This is
> > semantically quite intrusive, but according to upstream SBCL is one of
> > the dialects of common lisp they test with.
>
> > If you want to get a handle on how intrusive the patch is in terms of lines changed,
> > The resulting package is not perfect of course, but I think it is
> > better than what we have now (which, AFAIKT, is no maxima in lenny).
> > Two issues in particular:
>
> > 1) The documentation index is read into lisp and the system redumped. This makes the image
> > about 1M bigger than required (OTOH, it is already 43M).
> > 2) there is now versioned dependency on SBCL, since the core format turns out to be
> > unstable from release to release.
>
> > If you prefer, you can grab a copy of my packaging vcs:
>
> > git clone alioth.debian.org:/git/debian-science/packages/maxima
>
> > The latter can be built with
>
> > git-buildpackage --git-ignore-new
>
> > It builds these binary packages: maxima - A computer algebra system --
> > base system maxima-doc - A computer algebra system -- documentation
> > maxima-emacs - A computer algebra system -- emacs interface
> > maxima-share - A computer algebra system -- extra code maxima-src - A
> > computer algebra system -- source code maxima-test - A computer
> > algebra system -- test suite xmaxima - A computer algebra system -- x
> > interface
>
> > The upload would fix these bugs: 474909, 489871
>
> > The package can be found on mentors.debian.net:
> > - URL:http://mentors.debian.net/debian/pool/main/m/maxima
> > - Source repository: deb-srchttp://mentors.debian.net/debianunstable main contrib non-free
> > I would be glad if someone uploaded this package for me.
>
> CCing to debian-sage.
could build on top of ecl since there is some version of it in Debian.
sbcl seems to work mostly fine. I am having some trouble with it on
Sparc/Solaris, so I would not be surprised if there were some on Sparc/
Linux. Note that that trouble happens when running the Sage test suite
on sbcl 0.9.17 (the last 0.9.x release since none of the 1.0.x
releases of sbcl compile on Solaris 10) even though the Maxima test
suite passes with sbcl 0.9.17 on that Solaris 10 Intel box. So I would
take the fact that the Maxima test suite passes with a grain of salt
when evaluation common lisps for Maxima.
I also followed the discussion of the clisp Debian maintainer and due
to lack of time/sudden appearance of the lenny freeze it was decided
to upgrade from clisp 2.41 to 2.44 and *not* 2.46 in Debian. Oh
well ....
> Ondrej
Cheers,
Michael
François Bissey
> Yeah, I would have been so great if Maxima 5.16 had shipped and Debian
> could build on top of ecl since there is some version of it in Debian.
> sbcl seems to work mostly fine. I am having some trouble with it on
> Sparc/Solaris, so I would not be surprised if there were some on Sparc/
> Linux. Note that that trouble happens when running the Sage test suite
> on sbcl 0.9.17 (the last 0.9.x release since none of the 1.0.x
> releases of sbcl compile on Solaris 10) even though the Maxima test
> suite passes with sbcl 0.9.17 on that Solaris 10 Intel box. So I would
> take the fact that the Maxima test suite passes with a grain of salt
> when evaluation common lisps for Maxima.
Last time I tried using a maxima compiled with sbcl (1.0.9 ?) with sage
on Gentoo, sage couldn't call maxima. The lisp engine just didn't allow
for it. It may be that it is possible but need some tuning with the
compilation options. I am currently forbiding the building of maxima with
sbcl for sage on Gentoo.
The current maxima ebuild will have to be modified to allow building against
ecl but it should be possible.
Francois
mabshoff
On Jul 27, 4:49 am, François Bissey <fbis...@slingshot.co.nz> wrote:
> On Sun, 27 Jul 2008, mabshoff wrote:
> > Yeah, I would have been so great if Maxima 5.16 had shipped and Debian
> > could build on top of ecl since there is some version of it in Debian.
> > sbcl seems to work mostly fine. I am having some trouble with it on
> > Sparc/Solaris, so I would not be surprised if there were some on Sparc/
> > Linux. Note that that trouble happens when running the Sage test suite
> > on sbcl 0.9.17 (the last 0.9.x release since none of the 1.0.x
> > releases of sbcl compile on Solaris 10) even though the Maxima test
> > suite passes with sbcl 0.9.17 on that Solaris 10 Intel box. So I would
> > take the fact that the Maxima test suite passes with a grain of salt
> > when evaluation common lisps for Maxima.
> Last time I tried using a maxima compiled with sbcl (1.0.9 ?) with sage
> on Gentoo, sage couldn't call maxima. The lisp engine just didn't allow
> for it. It may be that it is possible but need some tuning with the
> compilation options. I am currently forbiding the building of maxima with
> sbcl for sage on Gentoo.
of the one shipped with Sage. We will upgrade to Maxima 5.16.x once it
is officially out and will at the same time switch to ecl (probably
some well tested CVS snapshot unless a release happens soon).
> The current maxima ebuild will have to be modified to allow building against
> ecl but it should be possible.
packages and I think that ecl will be the fastest lisp in the future
to run Maxima (it is about 10% behind sbcl at the moment) and also
that ecl will build and actually work on a much wider number of
platforms than any other common lisp (Emacs' lisp implementation does
not count, it is not *common* lisp :)). The Pan-Axiom crowd is also
switching to ecl as the recommended lisp and I am hoping that the
availability of Maxima on top of ecl (I plan to build the Maxima
people a 64 bit installer for Windows) will make many more projects
build with common lisp make sure that they work on ecl.
> Francois
Cheers,
Michael
Timothy G Abbott
I ran a full Sage test suite after building and installing the new maxima
package, and things seem to work about as well as they did with the old
one. Some tests fail due to different rounding policies between Maxima
with clisp (what Sage uses) and with other lisps (example below); this is
an old issue.
**********************************************************************
File "/home/tabbott/.sage/tests/calculus.py", line 3141:
sage: f.find_minimum_on_interval(1, 5)
Expected:
(-3.2883713955908962, 3.42561846957)
Got:
(-3.2883713955908962, 3.425618469566611)
**********************************************************************
But I get one case where the answer is completely different.
sage -t devel/sage/sage/calculus/calculus.py
**********************************************************************
File "/home/tabbott/.sage/tests/calculus.py", line 2596:
sage: f.nintegrate(x,0,1)
Expected:
(-480.00000000000011, 5.3290705182007538e-12, 21, 0)
Got:
(-831.99999999999989, 9.237055564881304e-12, 21, 0)
**********************************************************************
However, I don't think we should be concerned, since the answer is
actually supposed to be basically 0 and this doctest is intended to be a
demonstration of the problems with using floats everywhere.
So, I don't think that the new Maxima will be a problem for Sage.
(the relevant section of calculus.py responsible for that test is below)
-----------------------------------------------------------------
Note that in exotic cases where floating point evaluation of
the expression leads to the wrong value, then the output
can be completely wrong:
sage: f = exp(pi*sqrt(163)) - 262537412640768744
Despite appearance, $f$ is really very close to 0, but one
gets a nonzero value since the definition of \code{float(f)} is
that it makes all constants inside the expression floats, then
evaluates each function and each arithmetic operation
using float arithmetic:
sage: float(f)
-480.0
Computing to higher precision we see the truth:
sage: f.n(200)
-7.4992740280181431112064614366622348652078895136533593355718e-13
sage: f.n(300)
-7.49927402801814311120646143662663009137292462589621789352095066181709095575\
681963967103004e-13
Now numerically integrating, we see why the answer is wrong:
sage: f.nintegrate(x,0,1)
(-480.00000000000011, 5.3290705182007538e-12, 21, 0)
It is just because every floating point evaluation of return
-480.0 in floating point.
-----------------------------------------------------------------
-Tim Abbott