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 alexandre.vassalotti, amaury.forgeotdarc, christian.heimes, gvanrossum, mark.dickinson, nascheme, noam, preston, rhettinger, skip.montanaro, tim.peters
Date 2009-02-25.20:49:13
SpamBayes Score 6.6912337e-10
Marked as misclassified No
Message-id <>
> I would consider compiling the library with flags appropriate to forcing
> 64-bit IEEE arithmetic if possible.

Using the right compiler flags is only half the battle, though.  You 
should really be setting the rounding precision dynamically:  set it to 
53-bit precision before the call to strtod, and then restore it to 
whatever the original precision was afterwards.  And the magic formula for 
doing this is likely to vary from platform to platform.  As far as I can 
tell, the C99 standard doesn't suggest any standard spellings for changing 
the rounding precision.

It's not unknown for libm functions on x86 to blindly assume that the x87 
FPU is set to its default of extended-precision (64-bit) rounding, so it's 
risky to just set 53-bit rounding for the whole of Python's execution.

And contrary to popular belief, setting 53-bit rounding *still* doesn't 
give the x87 FPU IEEE 754 semantics:  there are issues at the extremes of 
the floating-point range, and I'm not 100% convinced that those issues 
wouldn't affect the dtoa.c strtod.

I'm not saying that all this is impossible;  just that it's subtle and 
would involve some work.
Date User Action Args
2009-02-25 20:49:17mark.dickinsonsetrecipients: + mark.dickinson, gvanrossum, tim.peters, skip.montanaro, nascheme, rhettinger, amaury.forgeotdarc, christian.heimes, alexandre.vassalotti, noam, preston
2009-02-25 20:49:16mark.dickinsonsetmessageid: <>
2009-02-25 20:49:14mark.dickinsonlinkissue1580 messages
2009-02-25 20:49:13mark.dickinsoncreate