[email protected] (Michael van Elst) writes: > [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).
I guess that's a complicated situation in terms of IEEE754 and the expected deterministic outcome, but if we are down to just that it would be great :-) > 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. I rebuilt paranoia with -ffloat-store (and didn't touch libm), and then I get only: Checking rounding on multiply, divide and add/subtract. * is neither chopped nor correctly rounded. / is neither chopped nor correctly rounded. Addition/Subtraction neither rounds nor chops. Sticky bit used incorrectly or not at all. FLAW: lack(s) of guard digits or failure(s) to correctly round or chop (noted above) count as one flaw in the final tally below. I see a complaint about * and correct rounding on 10-aarch64, and no complaints at all on 10-amd64. Does our amd64 build avoid the use of extended (80-bit) doubles? Assuming no and no, do you understand why the IEEE754-expected 53 bits is found on amd64? Is that just happenstance of how the test is compiled?
