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 mark.dickinson
Recipients mark.dickinson, srid
Date 2009-08-06.20:10:16
SpamBayes Score 0.0
Marked as misclassified No
Message-id <1249589419.97.0.757223380749.issue6646@psf.upfronthosting.co.za>
In-reply-to
Content
Thanks.  So pickle protocol 0 is where it's failing;  protocols 1 and 2 
are okay.  It looks as though there's a problem with double <-> string 
(i.e., binary <-> decimal) conversion here.

This probably also means that there are more serious problems on AIX, 
e.g., that float(repr(x)) == x fails for at least some Python floats x.  
That is, on my system:

>>> x = 7e-308
>>> float(repr(x)) == x
True

I expect that you'd get 'False' for this.  Is that right?  If you do get 
False, does this happen for any randomly chosen float x, or is it just 
very small values like the above that are problematic?

Is there any chance the FPU rounding mode has somehow been set to 
something other than round-to-nearest?  (It seems unlikely, but it's 
worth checking.)

These bits of Python are based on the assumption that conversion of an 
IEEE 754-format C double to a decimal string with 17 significant digits 
and back again recovers the original double.  A conforming hosted 
implementation of C99 that defines __STDC_IEC_559__ should satisfy this 
assumption (see Appendix F of the standard, especially section F.5);  
the IEEE 754 standard also recommends this behaviour.

So if your C implementation defines __STDC_IEC_559__ then this can 
reasonably be considered a platform bug.  Does it?
History
Date User Action Args
2009-08-06 20:10:20mark.dickinsonsetrecipients: + mark.dickinson, srid
2009-08-06 20:10:19mark.dickinsonsetmessageid: <1249589419.97.0.757223380749.issue6646@psf.upfronthosting.co.za>
2009-08-06 20:10:17mark.dickinsonlinkissue6646 messages
2009-08-06 20:10:16mark.dickinsoncreate