ECL? was ..Re: Runtime determination of share directories?

Raymond Toy wrote:
> Michael Abshoff wrote:

Hi,

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

Ok, I personally have zero problems with GMP and MPFR while getting 
various lisps to compile did cost me considerable more effort. And gcc 
4.2.x recommends GMP and MPFR while 4.3.x and later require it for 
constant folding. So any system providing recent gcc should have them 
available. Ecl has its own GMP copy in tree and so do other lisp 
implementations.

> But Maxima can't run without a lisp, but it does run well (quite well,
> IMNSHO) without MPFR/GMP. :-)

Absolutely, but given the periodically reappearing discussion about 
easier use of external libraries written in C/C++/Fortran something 
worthwhile to think about IMHO would be MPFR. Since I am not doing any 
of the work this is merely a suggestion.

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

Quaddouble uses SSE2 if it is available on on the box in question we 
certainly had that, i.e. it was a recent QuadCore2

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

I need to dig it out of the Sage bug tracker and that will take some time.

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

AFAIK the advantage if qd is that it sets rounding mode to 53 bits and 
hence does not rely on 80 bit representation. There is a well known 
paper that shows that compilers optimizing expression trees will cause 
precision loss. But qd at least to my understanding should not be 
affected by this issue.

> Ray
> 
> 

Cheers,

Michael