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 preston
Recipients alexandre.vassalotti, amaury.forgeotdarc, christian.heimes, gvanrossum, mark.dickinson, nascheme, noam, preston, rhettinger, skip.montanaro, tim.peters
Date 2009-02-25.18:11:20
SpamBayes Score 0.00022235572
Marked as misclassified No
Message-id <9d8c178d0902251011t4ee4f4bpe21f614e436194df@mail.gmail.com>
In-reply-to <1235583935.03.0.379204731807.issue1580@psf.upfronthosting.co.za>
Content
>> It'd probably have to be touched up a bit.

> This may be an understatement. :-)

Probably so.  Nevertheless, it's got to be easier
than approaching the problem from scratch.
And considering that this discussion has been
going on for over a year now, it might be a way to
move forward.

> In the first 50 lines of the 3897-line dtoa.c file, I see this warning:
>
> /* On a machine with IEEE extended-precision registers, it is
>  * necessary to specify double-precision (53-bit) rounding precision
>  * before invoking strtod or dtoa.  [...] */
>
> It seems to me that figuring out how and when to do this, and
> writing and testing the appropriate configure/pyport/whatever
> code, is already a nontrivial task.

I would consider compiling the library with flags appropriate to forcing
64-bit IEEE arithmetic if possible.  Another possibility is to explore
gdtoa.c
which is supposed to include code for extended precision, quad precision,
etc.
Files
File name Uploaded
unnamed preston, 2009-02-25.18:11:19
History
Date User Action Args
2009-02-25 18:11:22prestonsetrecipients: + preston, gvanrossum, tim.peters, skip.montanaro, nascheme, rhettinger, amaury.forgeotdarc, mark.dickinson, christian.heimes, alexandre.vassalotti, noam
2009-02-25 18:11:20prestonlinkissue1580 messages
2009-02-25 18:11:20prestoncreate