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 eric.smith, mark.dickinson, skrah
Date 2010-01-08.20:44:10
SpamBayes Score 1.66533e-16
Marked as misclassified No
Message-id <1262983452.88.0.753329877158.issue7632@psf.upfronthosting.co.za>
In-reply-to
Content
Randomised testing quickly turned up another troublesome string for str -> float conversion:

s = "94393431193180696942841837085033647913224148539854e-358"

This one's actually giving incorrectly rounded results (the horror!) in a non-debug build of trunk, and giving the same 'oversize b in quorem' in a debug build.  With the patch, it doesn't give the 'oversize b' error, but does still give incorrect results.

Python 2.7a1+ (trunk:77375, Jan  8 2010, 20:33:59) 
[GCC 4.2.1 (Apple Inc. build 5646) (dot 1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> s = "94393431193180696942841837085033647913224148539854e-358"
>>> float(s)   # result of dtoa.c
9.439343119318067e-309
>>> from __future__ import division
>>> int(s[:-5])/10**358  # result via (correctly rounded) division
9.43934311931807e-309

I also double checked this value using a simple pure Python implementation of strtod, and using MPFR (via the Python bigfloat module), with the same result:

>>> from test_dtoa import strtod
>>> strtod(s)  # result via a simple pure Python implementation of strtod
9.43934311931807e-309
>>> from bigfloat import *
>>> with double_precision: x = float(BigFloat(s))
>>> x   # result from MPFR, via the bigfloat module
9.43934311931807e-309
History
Date User Action Args
2010-01-08 20:44:13mark.dickinsonsetrecipients: + mark.dickinson, eric.smith, skrah
2010-01-08 20:44:12mark.dickinsonsetmessageid: <1262983452.88.0.753329877158.issue7632@psf.upfronthosting.co.za>
2010-01-08 20:44:11mark.dickinsonlinkissue7632 messages
2010-01-08 20:44:10mark.dickinsoncreate