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 Kiriakos.Vlahos, brian.curtin, eric.smith, loewis, mark.dickinson, sjmachin, skrah
Date 2010-09-30.07:09:24
SpamBayes Score 6.3282712e-15
Marked as misclassified No
Message-id <1285830567.52.0.662282059665.issue9980@psf.upfronthosting.co.za>
In-reply-to
Content
> Delphi uses the following code at initialization.

Yep.  That would explain the problem.  On x86 machines, Python's string-to-float and float-to-string conversions require that the x87 FPU has precision set to 53 bits rather than 64 bits (and also that the FPU rounding mode is round-half-to-even, but this rarely gets changed).

There's a configure-time check that works out whether resetting the precision is necessary;  if so, the precision is changed before each conversion and reverted again afterwards (see the _Py_SET_53BIT_PRECISION_START and _Py_SET_53BIT_PRECISION_END macros used in Python/pystrtod.c ).  It looks like you may need to override these macros for PyScripter.

Note that this isn't usually a problem on Windows:  the default setting on Windows is 53 bit precision;  I've no idea why Delphi changes it.  The main problem platform is 32-bit Linux, which uses 64-bit precision by default.  (And 64-bit Linux generally uses the appropriate SSE2 instructions instead of the x87; these are always 53-bit precision.)

So in general there's an issue if the runtime FPU settings don't match the configure-time FPU settings.  I'm not sure what the best mechanism for solving this is.  Checking the FPU state before *every* conversion would be possible, I guess, but it most cases that's unnecessary.
History
Date User Action Args
2010-09-30 07:09:27mark.dickinsonsetrecipients: + mark.dickinson, loewis, sjmachin, eric.smith, brian.curtin, skrah, Kiriakos.Vlahos
2010-09-30 07:09:27mark.dickinsonsetmessageid: <1285830567.52.0.662282059665.issue9980@psf.upfronthosting.co.za>
2010-09-30 07:09:25mark.dickinsonlinkissue9980 messages
2010-09-30 07:09:24mark.dickinsoncreate