Message84391
> 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.9999:
> 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.9999
...
>>> dis.dis(f)
2 0 LOAD_CONST 3 (10000000000000002.0)
3 RETURN_VALUE
>>> zlib.crc32(marshal.dumps(f.__code__.co_consts))
2292868100
32-bit:
>>> def f():
... return 1e16+2.9999
...
>>> dis.dis(f)
2 0 LOAD_CONST 3 (10000000000000004.0)
3 RETURN_VALUE
>>> zlib.crc32(marshal.dumps(f.__code__.co_consts))
103113703 |
|
Date |
User |
Action |
Args |
2009-03-29 13:09:14 | pitrou | set | recipients:
+ pitrou, mark.dickinson |
2009-03-29 13:09:14 | pitrou | set | messageid: <1238332154.63.0.603448548442.issue5593@psf.upfronthosting.co.za> |
2009-03-29 13:09:13 | pitrou | link | issue5593 messages |
2009-03-29 13:09:12 | pitrou | create | |
|