homepage

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

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.)

See also issue 2819 for ongoing discussion, and issue 2937, which is the 
likely root cause of the current difficulties with math.sum.

Both trunk and 3k give this:
>>> 1e16 + 2.9999
10000000000000004.0
>>> 1.7976931348623157e+308 + 9.979201547673598e+291
inf

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?

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.

The tests at floating point boundaries should probably be removed and 
their behavior should be left undefined.

See also issue 5593.