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.

Author pitrou
Recipients mark.dickinson, pitrou
Date 2009-03-29.13:09:12
SpamBayes Score 2.2601341e-08
Marked as misclassified No
Message-id <1238332154.63.0.603448548442.issue5593@psf.upfronthosting.co.za>
In-reply-to
Content
> 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
History
Date User Action Args
2009-03-29 13:09:14pitrousetrecipients: + pitrou, mark.dickinson
2009-03-29 13:09:14pitrousetmessageid: <1238332154.63.0.603448548442.issue5593@psf.upfronthosting.co.za>
2009-03-29 13:09:13pitroulinkissue5593 messages
2009-03-29 13:09:12pitroucreate