| msg70094 - (view) |
Author: Georg Brandl (georg.brandl) *  |
Date: 2008-07-20 22:35 |
| In Py3k, but not in trunk: ====================================================================== FAIL: testSum (test.test_math.MathTests) ---------------------------------------------------------------------- Traceback (most recent call last): File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 769, in testSum self.assertEqual(math.sum(vals), s) OverflowError: math range error During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/home/gbr/devel/python3k/Lib/test/test_math.py", line 772, in testSum "for math.sum(%.100r)" % (i, s, vals)) AssertionError: test 13 failed: got OverflowError, expected 1.7976931348623157e+308 for math.sum([1.7976931348623157e+308, 9.979201547673598e+291]) System info: linux x86, glibc 2.8 |
|
|
| msg70293 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-07-26 10:03 |
| Sadly, this is not the only problem with math.sum on x86 hardware right now. I'd guess that this is another problem related to double-rounding and the use of 80-bit floating-point registers on x86. Raymond and I are still actively looking for ways to fix math.sum up, including the possibility of a complete rewrite using a totally different algorithm. With the current algorithm, behaviour at or near the boundary of the floating-point range should really be considered undefined; so the quick fix is to update the tests and docs to reflect this. The particular test that causes test.math to fail would just be removed. I am intrigued that py3k and the trunk give different results, though; I'd very much like to know where the difference comes from. Georg, *only if you have time*, could you please tell me what results the linux box gives for the following two Python sums, in both py3k and the trunk: >>> 1e16 + 2.9999 10000000000000002.0 >>> 1.7976931348623157e+308 + 9.979201547673598e+291 1.7976931348623157e+308 (The results shown are the ones I get on OS X 10.5.4; I don't have access to a linux box for testing at the moment.) |
|
|
| msg70294 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-07-26 10:14 |
| See also issue 2819 for ongoing discussion, and issue 2937, which is the likely root cause of the current difficulties with math.sum. |
|
|
| msg70296 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2008-07-26 11:18 |
| Both trunk and 3k give this: >>> 1e16 + 2.9999 10000000000000004.0 >>> 1.7976931348623157e+308 + 9.979201547673598e+291 inf |
|
|
| msg70302 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2008-07-26 14:14 |
| Thanks. Those are the results I'd expect on x86. So here's the puzzle: On lines 658-9 of Lib/test/test_math.py, in revision 65248 of the py3k branch, there's a pair of lines that looks like: if 1e16+2.999 != 1e16+2.9999: return These lines are supposed to bail out of testSum on IEEE 754 hardware that doesn't do correct rounding. So on your machine, I'd expect: 1e16+2.999 to evaluate to 10000000000000002.0 1e16+2.9999 to evaluate to 10000000000000004.0 so the condition in the if statement ought to be True, and the rest of the tests should be skipped. It looks like this bailout is working as intended in the trunk, but not in Py3k. Any ideas why there's a difference? Is there some sort of constant folding going on in py3k but not in the trunk? |
|
|
| msg70303 - (view) |
Author: Georg Brandl (georg.brandl) * |
Date: 2008-07-26 15:43 |
| Strangely, it seems to work now with 3k too -- both in a debug and release build. I've no idea what changed, but I'll close this for now. |
|
|
| msg70306 - (view) |
Author: Raymond Hettinger (rhettinger) * |
Date: 2008-07-26 21:29 |
| The tests at floating point boundaries should probably be removed and their behavior should be left undefined. |
|
|
| msg84388 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2009-03-29 13:00 |
| See also issue 5593. |
|
|