tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: floating point woes on i386
gdt%lexort.com@localhost (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.
Home |
Main Index |
Thread Index |
Old Index