bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

glibc 2.2.4: More math errors (K6, DX4, and Linux emulator)


From: Michael Deutschmann
Subject: glibc 2.2.4: More math errors (K6, DX4, and Linux emulator)
Date: Tue, 9 Oct 2001 22:01:53 -0700 (PDT)

glibc 2.2.4 seems to have tighter math checks than previous versions.  In 
particular, Intel DX4 and AMD K6 systems now fail (with different 
errors). All the errors occur at long-double precision.

Additionally, I have been aware of failures that occur when using the FPU 
emulator included with the Linux kernel.  I've held off contacting you 
immediately, as I first brought the errors to the attention of the 
emulator's maintainer, Bill Metzenthen.  He's fixed most of them, but 
some problems remain.

So once again I have to ask you to widen the error tolerance, it seems.

The emulator failures are as follows (identical problems occur on the 
inline test):

---
testing long double (without inline functions)
Failure: Test: cos (M_PI_6l * 4.0) == -0.5
Result:
 is:         -4.99999999999999999946e-01  -0xf.ffffffffffffffe00000p-5
 should be:  -5.00000000000000000000e-01  -0x8.00000000000000000000p-4
 difference:  5.42101086242752217004e-20   0x8.00000000000000000000p-67
 ulp       :  1.0000
 max.ulp   :  0.5000
Failure: Test: sinh (0x8p-32) == 1.86264514923095703232705808926175479e-9
Result:
 is:          1.86264514923095703246e-09   0x8.00000000000000600000p-32
 should be:   1.86264514923095703226e-09   0x8.00000000000000500000p-32
 difference:  2.01948391736579022185e-28   0x8.00000000000000000000p-95
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: j0 (2.0) == 0.22389077914123566805
Result:
 is:          2.23890779141235668042e-01   0xe.5439fd92677be4600000p-6
 should be:   2.23890779141235668056e-01   0xe.5439fd92677be4700000p-6
 difference:  1.35525271560688054251e-20   0x8.00000000000000000000p-69
 ulp       :  1.0000
 max.ulp   :  0.0000
Maximal error of `j0'
 is      :  1.0000 ulp
 accepted:  0.0000 ulp
Failure: Test: jn (0, 2.0) == 0.22389077914123566805
Result:
 is:          2.23890779141235668042e-01   0xe.5439fd92677be4600000p-6
 should be:   2.23890779141235668056e-01   0xe.5439fd92677be4700000p-6
 difference:  1.35525271560688054251e-20   0x8.00000000000000000000p-69
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: y0 (2.0) == 0.51037567264974511960
Result:
 is:          5.10375672649745119641e-01   0x8.2a7fae6b46465e200000p-4
 should be:   5.10375672649745119587e-01   0x8.2a7fae6b46465e100000p-4
 difference:  5.42101086242752217004e-20   0x8.00000000000000000000p-67
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: y1 (2.0) == -0.10703243154093754689
Result:
 is:         -1.07032431540937546858e-01  -0xd.b33d1c8a3323ac100000p-7
 should be:  -1.07032431540937546892e-01  -0xd.b33d1c8a3323ac600000p-7
 difference:  3.38813178901720135627e-20   0xa.00000000000000000000p-68
 ulp       :  5.0000
 max.ulp   :  1.0000
Maximal error of `y1'
 is      :  5.0000 ulp
 accepted:  2.0000 ulp
Failure: Test: yn (0, 2.0) == 0.51037567264974511960
Result:
 is:          5.10375672649745119641e-01   0x8.2a7fae6b46465e200000p-4
 should be:   5.10375672649745119587e-01   0x8.2a7fae6b46465e100000p-4
 difference:  5.42101086242752217004e-20   0x8.00000000000000000000p-67
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: yn (1, 2.0) == -0.10703243154093754689
Result:
 is:         -1.07032431540937546858e-01  -0xd.b33d1c8a3323ac100000p-7
 should be:  -1.07032431540937546892e-01  -0xd.b33d1c8a3323ac600000p-7
 difference:  3.38813178901720135627e-20   0xa.00000000000000000000p-68
 ulp       :  5.0000
 max.ulp   :  1.0000

Test suite completed:
  2500 test cases plus 2288 tests for exception flags executed.
  10 errors occurred.
---

Bill points out that the correctly rounded answer for cosl(3/2pi), is 
actually one unit greater than -1.0 at this precision, due to the 
rounding of the input value.  The 486 gets it right -- but you don't 
notice because of your .5ULP tolerance.   While the emulator is 1ULP out 
itself here (in the opposite direction), Bill doubts he can fix it 
without hurting accuracy elsewhere.

And he says that the error in sinh() is actually a problem with your
algorithm -- it only works on the 486 because -it- has a bug in F2XM1 that
hides your error.  The K6 also fails (just) sinh(), in the same way
-- which tends to confirm his analysis. 

The DX4 errors are completely different:
testing long double (without inline functions)
Failure: Test: exp (1) == e
Result:
 is:          2.71828182845904523521e+00   0xa.df85458a2bb4a9a00000p-2
 should be:   2.71828182845904523543e+00   0xa.df85458a2bb4a9b00000p-2
 difference:  2.16840434497100886801e-19   0x8.00000000000000000000p-65
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: exp (3) == e^3
Result:
 is:          2.00855369231876677398e+01   0xa.0af2dfb7d882f9600000p+1
 should be:   2.00855369231876677415e+01   0xa.0af2dfb7d882f9700000p+1
 difference:  1.73472347597680709441e-18   0x8.00000000000000000000p-62
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: erfc (2.0) == 0.0046777349810472658379
Result:
 is:          4.67773498104726583751e-03   0x9.947af61a873346b00000p-11
 should be:   4.67773498104726583793e-03   0x9.947af61a873346c00000p-11
 difference:  4.23516473627150169534e-22   0x8.00000000000000000000p-74
 ulp       :  1.0000
 max.ulp   :  0.0000
Failure: Test: Real part of: csin (-2 - 3 i) == -9.1544991469114295734 + 
4.1689069599665643507 i
Result:
 is:         -9.15449914691142957283e+00  -0x9.278d418f3e96dbe00000p+0
 should be:  -9.15449914691142957370e+00  -0x9.278d418f3e96dbf00000p+0
 difference:  8.67361737988403547206e-19   0x8.00000000000000000000p-63
 ulp       :  1.0000
 max.ulp   :  0.0000

Test suite completed:
  2500 test cases plus 2288 tests for exception flags executed.
  4 errors occurred.

Oddly enough, the first two errors do not register in the inline version 
of the test.

Note that the emulator tests were done with the very latest version of the
fpu emulator, included in Linux 2.0.40pre2.  Linux 2.0.39 is much worse,
and current 2.2/2.4 versions may have further problems too, depending on
how fast the latest fixes have propagated.

---- Michael Deutschmann <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]