Number of significand bits in long double?
Steve Kargl
sgk at troutmask.apl.washington.edu
Thu Aug 4 18:28:09 GMT 2005
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
More information about the freebsd-current
mailing list