Re: Effects of newly introduced -mpcX 80387 precision flag

[Tim Prince <n8tm at aol dot com>]

lucier@math.purdue.edu wrote:

> I just (re-)discovered these tables giving maximum known errors in some 
> libm functions when extended precision is enabled:
>
> http://people.inf.ethz.ch/gonnet/FPAccuracy/linux/summary.html
>
> and when the precision of the mantissa is set to 53 bits (double 
> precision):
>
> http://people.inf.ethz.ch/gonnet/FPAccuracy/linux64/summary.html
>
> This is from 2002, and indeed, some of the errors in double-precision 
> results are hundreds or thousands of times bigger when the precision is 
> set to 53 bits.
This isn't very helpful.  I can't find an indication of whose libm is 
being tested, it appears to be an unspecified non-standard version of 
gcc, and a lot of digging would be needed to find out what the tests 
are.  It makes no sense at all for sqrt() to break down with change in 
precision mode.
Extended precision typically gives a significant improvement in accuracy 
of complex math functions, as shown in the Celefunt suite from TOMS.
The functions shown, if properly coded for SSE2, should be capable of 
giving good results, independent of x87 precision mode. I understand 
there is continuing academic research.
Arguments have been going on for some time on whether to accept 
approximate SSE2 math libraries.  I personally would not like to see new 
libraries without some requirement for readable C source and testing.
I agree that it would be bad to set 53-bit mode blindly for a library 
which expects 64-bit mode, but it seems a serious weakness if such a 
library doesn't take care of precision mode itself.
The whole precision mode issue seems somewhat moot, now that years have 
passed since the last CPUs were made which do not support SSE2, or the 
equivalent in other CPU families.