[issue5593] test_math.testFsum failure on release30-maint
Mark Dickinson dicki...@gmail.com added the comment: Test fixed for 2.7, 3.1 in r71837, r71839 -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Mark Dickinson dicki...@gmail.com added the comment: Hmm. I can't reproduce this. Is this a failure that just started happening recently on this particular platform, or is this the first time you ran the math test with this setup? I can't see any recent checkins that could have precipitated this. Could you attach the output of the configure script (just the stdout output, not the config.log)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Antoine Pitrou pit...@free.fr added the comment: Yikes. I can't reproduce it anymore. Perhaps make distclean is really necessary when switching a working copy from a 64-bit to a 32-bit build... Sorry for the noise. -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Mark Dickinson dicki...@gmail.com added the comment: Sorry for the noise. Not noise. I'd still be interested in understanding where this is coming from; I seem to recall someone else having exactly the same experience (reported bug, then found that it disappeared after a clean compile). My best guess is that you somehow ended up in a situation where the math module was using the x87 FPU for floating-point, while the interpreter core was using SSE2. Is this possible? Explanation: the x87 FPU has problems with double rounding (because it uses 80-bit extended precision registers internally) while SSE2 doesn't. fsum is a bit broken on systems with double rounding problems. So there's a pair of lines in testFsum that look like: if 1e16+2.0 != 1e16+2.: return These lines are supposed to skip all these tests on platforms with the double rounding problem. But if the core is using SSE2 then the test will fail and all the fsum tests will be executed, which is a problem if fsum is using x87. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Mark Dickinson dicki...@gmail.com added the comment: Found the other report of this: see issue 3421. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Mark Dickinson dicki...@gmail.com added the comment: My best guess is that you somehow ended up in a situation where the math module was using the x87 FPU for floating-point, while the interpreter core was using SSE2. Is this possible? I should also have said that this would fit with the 32-bit/64-bit stuff: I *think* it's true that for gcc on Linux, in the absence of compiler flags, a 64-bit build defaults to using SSE2 while a 32-bit build defaults to x87. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Antoine Pitrou pit...@free.fr added the comment: My best guess is that you somehow ended up in a situation where the math module was using the x87 FPU for floating-point, while the interpreter core was using SSE2. Is this possible? That would be the reverse, since this occurred on a 32-bit build, i.e. the interpreter core was using x87. But I don't understand how a 64-bit module could be loaded by a 32-bit executable (I did check that sys.maxsize was 2**31 - 1). fsum is a bit broken on systems with double rounding problems. So there's a pair of lines in testFsum that look like: if 1e16+2.0 != 1e16+2.: return Wouldn't it be a problem with stale pyc files then? The result of each addition is stored as a constant when the code is compiled. Note how the constants arrays differ: 64-bit: def f(): ... return 1e16+2. ... dis.dis(f) 2 0 LOAD_CONST 3 (10002.0) 3 RETURN_VALUE zlib.crc32(marshal.dumps(f.__code__.co_consts)) 2292868100 32-bit: def f(): ... return 1e16+2. ... dis.dis(f) 2 0 LOAD_CONST 3 (10004.0) 3 RETURN_VALUE zlib.crc32(marshal.dumps(f.__code__.co_consts)) 103113703 -- resolution: invalid - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Mark Dickinson dicki...@gmail.com added the comment: Wouldn't it be a problem with stale pyc files then? Hah! Yes! That seems entirely likely. So what sequence of moves does one have to go through to reproduce this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Antoine Pitrou pit...@free.fr added the comment: Wouldn't it be a problem with stale pyc files then? Hah! Yes! That seems entirely likely. So what sequence of moves does one have to go through to reproduce this? I suppose: first run -m test.regrtest -v test_math in 64-bit mode, then rebuild in 32-bit mode (*) without doing make (dist)clean, then run -m test.regrtest -v test_math again (in 32-bit mode). (*) CC=gcc -m32 ./configure -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Mark Dickinson dicki...@gmail.com added the comment: Thanks, Antoine! Yes, I can now reproduce the testFsum failure on my MacBook Pro (OS X 10.5.6/x86_64, with Apple's gcc 4.0.1) using the following sequence of commands: (I tested this for the trunk, but I py3k should be just the same). make distclean CC=gcc -arch x86_64 ./configure make ./python.exe -m test.regrtest -v test_math rm Parser/*.o CC=gcc -mfpmath=387 ./configure make ./python.exe -m test.regrtest -v test_math (the rm is necessary to avoid a 'wrong architecture' build failure). It might be worth making the tests a bit more robust here; I'll take a look. On the other hand, there are plans to replace fsum with a double-rounding-friendly version. -- assignee: - marketdickinson components: +Extension Modules -Interpreter Core stage: - needs patch versions: +Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Antoine Pitrou pit...@free.fr added the comment:
I think it would be sufficient to invoke the addition through a helper
function, that is:
def add(x, y):
return x + y
if add(1e16, 2.0) != add(1e16, 2.):
return
Also, instead of return, you might use the new raise
unittest.SkipTest('some message').
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5593
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
New submission from Antoine Pitrou pit...@free.fr: I started getting this in release30-maint (not in py3k). == FAIL: testFsum (test.test_math.MathTests) -- Traceback (most recent call last): File /home/antoine/py3k/30/Lib/test/test_math.py, line 443, in testFsum self.assertEqual(actual, expected) AssertionError: 1.1102230246251565e-16 != 0.0 -- -- components: Interpreter Core messages: 84354 nosy: marketdickinson, pitrou priority: normal severity: normal status: open title: test_math.testFsum failure on release30-maint type: behavior versions: Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Antoine Pitrou pit...@free.fr added the comment: It only seems to happen on a 32-bit build on a 64-bit system. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5593] test_math.testFsum failure on release30-maint
Antoine Pitrou pit...@free.fr added the comment: And it actually also happens in py3k (but only in 32-bit mode, too). -- versions: +Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5593 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
