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 tim.peters
Recipients christian.heimes, gvanrossum, nascheme, noam, rhettinger, tim.peters
Date 2007-12-18.07:28:52
SpamBayes Score 0.00025928448
Marked as misclassified No
Message-id <>
It's not a question of bugs.  Call the machine writing the string W and
the machine reading the string R.  Then there are 4 ways R can get back
the double W started with when using the suggested algorithm:

1. W and R are the same machine.  This is the way that's most obvious.

The rest apply when W and R are different machines (by which I really
mean both use 754 doubles, but use different C libraries for
double<->string conversions):

2. W and R both do correct-rounding string->double.  This is obvious too
 (although it may not be obvious that it's /not/ also necessary that W
do correct-rounding double->string).

3. W and R both conform to the 754 standard, and W did produce 17
significant digits (or fewer if trailing zeroes were chopped).  This one
is neither obvious nor non-obvious:  that "it works" is something the
754 standard requires.

4. W produced fewer than 17 significant digits, and W and/or R do not do
correct rounding.  Then it works, or fails, by luck, and this has
nothing to do whether the double<->string algorithms have bugs.  There
are countless ways to code such routines that will fail in some cases --
doing correct rounding in all cases is the only way that won't fail in
some cases of producing fewer than 17 significant digits (and exactly
which cases depend on all the details of the specific
non-correct-rounding algorithms W and/or R implement).

This has nothing to do with what will or won't satisfy me, either.  I'm
happy with what Python currently does, which is to rely on #3 above. 
That's explainable (what's hard about understanding "%.17g"?), and
relies only on what the 754 standard requires.

There is no easy way around this, period.  If you're willing to give up
on float(repr(x)) == x cross-754-platform in some cases (and are willing
to be unable to spell out /which/ cases), then many easy alternates exist.

Maybe this is a missing fact:  I don't care whether float(repr(x)) == x.
 It would, for example, be fine by me if Python used a plain %.8g format
for str and repr.  But I'm not indulging wishful thinking about the
difficulties in ensuring float(repr(x)) == x either ;-)

BTW, about  passing that test
does not guarantee the platform does correct rounding.  It uses a fixed
set of test cases that were in fact obtained from running the algorithm
I invented for efficiently finding "hard" cases in the early 90s (and
implemented by Vern Paxson, and then picked up by the authors of the
test suite you found).  It's "very likely" that an implementation that
doesn't do correct rounding will fail on at least one of those cases,
but not certain.  Exhaustive testing is impossible (too many cases).
Date User Action Args
2007-12-18 07:28:55tim.peterssetspambayes_score: 0.000259284 -> 0.00025928448
recipients: + tim.peters, gvanrossum, nascheme, rhettinger, christian.heimes, noam
2007-12-18 07:28:54tim.peterssetspambayes_score: 0.000259284 -> 0.000259284
messageid: <>
2007-12-18 07:28:54tim.peterslinkissue1580 messages
2007-12-18 07:28:52tim.peterscreate