ECL? was ..Re: Runtime determination of share directories?
Subject: ECL? was ..Re: Runtime determination of share directories?
From: Raymond Toy
Date: Fri, 23 Jan 2009 16:17:50 -0500
Michael Abshoff wrote:
> Mhhh, maybe I did not name the right package? I am referring to the
> recent work of Dieter Kaiser implementing more special functions and I
> do recall him increasing the number of bits used internally for some
> computations to ensure identical results on various lisps.
>
There was some discussion about the gamma function, but I think
increasing the number of bits wasn't actually done.
As far as I know, the bigfloat implementations of the special functions
are truly identical.
> MPFR itself is pure C, but MPFR relies on GMP for the underlying
> arithmetic which is partially written in assembler. But I don't see how
> requiring MPFR and GMP present on the system would be an issue since
> building a lisp from sources is often harder. Making it optional and
>
I didn't find it that easy to build MPFR and/or GMP.
But Maxima can't run without a lisp, but it does run well (quite well,
IMNSHO) without MPFR/GMP. :-)
> No, the problem with quaddouble is that it requires at least on x86 to
> precisely set the FPU control word, i.e. rounding mode and so on. On
This assumes you're using x87. There should be no problem if you're
using SSE2.
>
>
> bits promised. I have even seen cases where a single multiplication of
> two numbers (and we did not attempt to hit a corner case) produced
> results that were different in the last three of four bits.
>
Do you have such an example? I'd really like to see it, since I
implemented a quaddouble package in Lisp sometime ago. Richard is well
aware of some of the problems we had on getting Allegro to produce the
correct results. (Not really allegro's fault, but it was over
aggressive speed 3, safety 0 optimization causing the compiler to lose
track (intentionally) of the precision of the numbers.)
> If the documentation tells me that I get 212 bits of precision then it
> should not matter which IEEE conformant CPU I am running the code on
> (modulo compiler bugs), but quaddouble does for the purpose the Sage
> project uses it not live up to the standard of reproducibility. That
> does not mean it is not useful for other projects, but at least Sage is
> not in the business of delivering potentially worng results 50% faster.
> AFAIK the issue is known to quaddouble developers and Carl Witty and I
> discussed the possibility of attempting to fix it by working around
> potential miscompilations last night, but this is a waste of time since
> even if we get it to work for some examples it will still not even come
I'm not sure, but I think there will always be corner cases where you
will get incorrect results on an x87. It's unavoidable due to the
80-bit registers. Even if you set the rounding and precision modes
correctly. I think the cases are when a number would underflow to 0 if
you had 64-bit doubles but doesn't when you have 80-bit long floats.
Ray