[sage-devel] elliptic_e(0.5, 0.1) differs from Mathematica 7 by about 0.04%.

Valery Pipin wrote:
>>> Dr. David Kirkby wrote:

> Sorry last was for the previous version of Maxima
> 
> [va at colombo maxima-5.19.0]$ rlwrap ./maxima-local
> STYLE-WARNING:
>    redefining ASDF:PERFORM :AROUND (#<STANDARD-CLASS ASDF:LOAD-OP>
>                                     #<STANDARD-CLASS ASDF:CL-SOURCE-FILE>) in 
> DEFMETHOD
> Maxima 5.19.0 http://maxima.sourceforge.net
> Using Lisp SBCL 1.0.29
> 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) elliptic_e(0.5, 0.1);
> (%o1)                          .4980113944988315
> 
> I wonder how sage people resist to use the high perfomance lisps like cmucl or 
> sbcl (which has windows version as well) to compile maxima. 
> 
> best luck
> Valery

You do not say what hardware you are using, which is quite relevant in 
this case.

I've no idea how the Sage group would feel about switches lisps. Given 
they have just recently done that (I forgot what was used before), there 
might not be too much enthusiasm for it.

Why do you think cmucl or sbcl would give high performance. Are you 
suggesting ecl would give lower performance?

Previously I showed the result from Mathematica where I'd taken pains to 
use 1/2 for 0.5, 1/10 for 0.5, then computed the results to 50 digits

In[4]:= N[EllipticE[1/2,1/10],50]

Out[4]= 0.49801139449883153311546104061744810584963105068054

This would have used software emulation to do the high precision. I 
tried it again, this time doing no such thing, so I might expect 
Mathematica to use only the floating point processor of the Sun and Sun 
libraries, not its own. (Of course, with closed-source software), it is 
anyone's guess what is really happening)

In[1]:= EllipticE[0.5,0.1]

Out[1]= 0.498011

which for all the digits shown, is the same result everyone else seems 
to get on their x86 boxes. This is on the same hardware. So if it was a 
problem on a Sun library, it is not one used by Mathematica.

I'll ask on the ECL list. I'll also try to build this on some other 
Solaris (SPARC) hardware and also on some Solaris x86 hardware.

The libraries ecl uses are:


$ ldd local/bin/ecl
         libecl.so =>     (file not found)
         libdl.so.1 =>    /lib/libdl.so.1
         libm.so.2 =>     /lib/libm.so.2
         libsocket.so.1 =>        /lib/libsocket.so.1
         libnsl.so.1 =>   /lib/libnsl.so.1
         libintl.so.1 =>  /lib/libintl.so.1
         libc.so.1 =>     /lib/libc.so.1
         libmp.so.2 =>    /lib/libmp.so.2
         libmd.so.1 =>    /lib/libmd.so.1
         libscf.so.1 =>   /lib/libscf.so.1
         libdoor.so.1 =>  /lib/libdoor.so.1
         libuutil.so.1 =>         /lib/libuutil.so.1
         libgen.so.1 =>   /lib/libgen.so.1
         /platform/SUNW,Sun-Blade-1000/lib/libc_psr.so.1
         /platform/SUNW,Sun-Blade-1000/lib/libmd_psr.so.1

(It's not found its own library here, but this it does run when uses as 
part of Sage. If I try to run the binary directly, it immediately exits

$ local/bin/ecl
ld.so.1: ecl: fatal: libecl.so: open failed: No such file or directory
Killed

but when run inside the environment Sage has set up for this, it runs 
ok. If it is a library problem, clearly libecl.so is a possibility. But 
I've no idea if that is related to floating point maths or not.


Dave