Re: Effects of newly introduced -mpcX 80387 precision flag

[Tim Prince <n8tm at aol dot com>]

lucier@math.purdue.edu wrote:
> On Apr 29, 2007, at 1:01 PM, Tim Prince wrote:

> > It makes no sense at all for sqrt() to break down with change in 
> > precision mode.
>
> If you do an extended-precision (80-bit) sqrt and then round the result 
> again to a double (64-bit) then those two roundings will increase the 
> error, sometimes to > 1/2 ulp.
>
> To give current results on a machine I have access to, I ran the tests 
> there on
>
> vendor_id       : AuthenticAMD
> cpu family      : 15
> model           : 33
> model name      : Dual Core AMD Opteron(tm) Processor 875
>
> using
>
> euler-59% gcc -v
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ../configure --prefix=/pkgs/gcc-4.1.2
> Thread model: posix
> gcc version 4.1.2
>
> on an up-to-date RHEL 4.0 server (so whatever libm is offered there), 
> and, indeed, the only differences that it found were in 1/x, sqrt(x), 
> and Pi*x because of double rounding.  In other words, the code that went 
> through libm gave identical answers whether running on sse, x87 
> (extended precision), or x87 (double precision).
>
> I don't know whether there are still math libraries for which Gonnet's 
> 2002 results prevail.
Double rounding ought to be avoided by -mfpmath=sse and permitting 
builtin_sqrt to do its thing, or by setting 53-bit precision.  The 
latter disables long double.  The original URL showed total failure of 
sqrt(); double rounding only brings error of .5 ULP, as usually assessed.
I don't think the 64-/53-bit double rounding of sqrt can be detected, 
but of course such double rounding of * can be measured.  With Pi, you 
have various possibilities, according to precision of the Pi value 
(including the possibility of the one supplied by the x87 instruction) 
as well as the 2 choices of arithmetic precision mode.