Mark Dickinson <dicki...@gmail.com> added the comment: 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 ---------- stage: patch review -> needs patch _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7632> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
