This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Test failure in test_math::testSum
Type: Stage:
Components: Extension Modules, Tests Versions: Python 3.0
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: mark.dickinson Nosy List: georg.brandl, mark.dickinson, rhettinger
Priority: normal Keywords:

Created on 2008-07-20 22:35 by georg.brandl, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (8)
msg70094 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) Date: 2009-03-29 13:00
See also issue 5593.
History
Date User Action Args
2022-04-11 14:56:36adminsetgithub: 47671
2009-03-29 13:00:41mark.dickinsonsetmessages: + msg84388
2008-07-26 21:29:02rhettingersetnosy: + rhettinger
messages: + msg70306
2008-07-26 15:43:22georg.brandlsetstatus: open -> closed
resolution: works for me
messages: + msg70303
2008-07-26 14:14:56mark.dickinsonsetmessages: + msg70302
2008-07-26 11:18:37georg.brandlsetmessages: + msg70296
2008-07-26 10:14:22mark.dickinsonsetmessages: + msg70294
2008-07-26 10:03:09mark.dickinsonsetmessages: + msg70293
2008-07-20 22:35:19georg.brandlcreate