Re: floating point woes on i386

[email protected] (Greg Troxel) writes:

>I ran paranoia (pkgsrc/benchmarks/paranoia) on 9 and 10.  On 9:

>  The number of  FAILUREs  encountered =       3.
>  The number of  SERIOUS DEFECTs  discovered = 4.
>  The number of  DEFECTs  discovered =         3.
>  The number of  FLAWs  discovered =           2.

>which is shocking, especially as I remember earlier NetBSD i386 versions
>being ok, like 5 or 7.

Same on -10, but while some defects are strange (like not
obeying rules for -inf and nan), some show a problem of
paranoia.

DEFECT:  computing
        (1.30000000000000000e+01) ^ (1.70000000000000000e+01)
        yielded 8.65041591938133811e+18;
        which compared unequal to correct 8.65041591938133914e+18 ;
                they differ by -1.02400000000000000e+03 .

13^17 is an integer with 19 digits that needs 126 bit (without
the leading 1).

13^17 = 8650415919381337933  the real value
      = 8650415919381338110  what paranoia thinks was computed
      = 8650415919381339140  what paranoia believed to be correct

For comparison:

13^17 = 8650415977864888320  when multiplying 13.0 17 times with float.
        8650415919381339136  when multiplying 13.0 17 times with double.
        8650415919381337933  when multiplying 13.0 17 times with long double.
        8650415919381338112  what paranoia really computed == pow(13.0, 17.0).


Running the 32bit and the 64bit version of paranoia on the same
hardware also reveals:

32bit:
Radix = 2.000000 .
Closest relative separation found is U1 = 5.4210109e-20 .
The number of significant digits of the Radix is 64.000000 .

64bit:
Radix = 2.000000 .
Closest relative separation found is U1 = 1.1102230e-16 .
The number of significant digits of the Radix is 53.000000 .


At least the precision calculations are spoiled by verifying only
at a lower precision on 64bit. My guess is that the paranoia
diagnosis would be 'better' when compiling paranoia (and maybe
libm) with -ffloat-store.