Re: Number of significand bits in long double?

On Thu, Aug 04, 2005 at 08:02:31PM +0200, Stefan Farfeleder wrote:
> On Thu, Aug 04, 2005 at 09:26:18AM -0700, Steve Kargl wrote:
> > Can someone confirm or refute that the long double type
> > has 53 bits in its significand on i386?  Which header 
> > file in /usr/include provides this info?
> 
> The type long double has 64 mantissa bits, however we set the FPU to
> 53-bit precision to get double computations right.
> 

This is screwing up my test programs that compare my implementations
of sqrtl, logl, acoshl, asinhl, atanhl, log2l, log10l, and cbrtl with
GMP/MPFR values.  I was using the values from float.h to set the
number of bits and number of decimal digits in the GMP/MPFR computation,

Once I account for the fact that long double is 53-bits instead of
64 bits, my test program for sqrt (compiled with -fno-builtin) shows
kargl[206] ./sqrt 1000000 1
Checking sqrtf, sqrt, and sqrtl ...
 Fuzzy: 15 15943 16333
Failed: 0 0 0

I'm generating 1000000 random numbers of the form s * F * 2^(S * 1)
where s and S are randomly set to +1 or -1 and F is in [1/2,1).
Fuzzy compares the output of sprintf conversed float, double, and
long double sqrt functions with the string generated by GMP/MPFR.
It does not count a possible rounding error in the 15 decimal
place as a failure.  So, we see sqrtf has 15 possible rounding
problems, sqrt has 15943, and my sqrtl has 16333 possible rounding
problems.  Contrast this with

kargl[216] ./log 10 1
Checking logf, log, and logl ...
log(9.98924517538399e-01)
        -1.07606120785561e-03 libm
        -1.07606120785517e-03 mpfr
logl(9.98924517538399e-01)
        -1.07606120785561e-03 libm
        -1.07606120785517e-03 mpfr
 Fuzzy: 0 2 2
Failed: 0 1 1

Our log() seems suspect.

-- 
Steve