[Ecls-list] How might this elliptic_e issue on SPARC hardware with ECL be debugged?

[Juan Jose Garcia-Ripoll]

On Mon, Aug 10, 2009 at 9:42 AM, Dr. David
Kirkby<david.kirkby at onetel.net> wrote:
> You probably see my previous posts on the fact that elliptic_e is giving
> incorrect results on SPARC hardware using ECL. If not,
> http://sagetrac.org/sage_trac/ticket/6716
> has the details.

I will remove maxima mailing list from this answer to spare me the
usual despective comments about ECL.

> Is there anything else that could be suspected, and so narrow down the
> list of possible causes somewhat?
> * Hardware fault on the particular machine.
> * Design flaw in Sun UltraSPARC CPU
> * ECL
> * Solaris library bug
> * Maxima
> * gcc
> * I screwed up compiling Maxima or ECL.

There are two potential sources of error I can think of. One is the
fact that special function computations with integers/rationals will
be done using short floats in Common-Lisp. It may well be that at some
places this coercion is taking place, etc, etc.

The other possibility is that ECL is inlining the functions using the
C library. I systematically appreciate errors in rounding, results and
accuracy due to this. See http://ecls.sourceforge.net/logs.html and
how the failed ansi tests change from platform to platform.

I do not know whether this is essential to using the C library, or
whether it is associated to the code that the compiler generates. For
instance, gcc may produce code that is less accurate than the C
library itself, or it may use _more_ accuracy than expected by the
IEEE standard.

The way to determine whether it is the compiled code that is
responsible is to execute the same function interpreted and compiled.
But of course, for that we need the particular expression that Maxima
is using.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com