Tim Peters added the comment: 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 http://www.cant.ua.ac.be/ieeecc754.html: 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). __________________________________ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1580> __________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
