[EMAIL PROTECTED] 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.
