4 hundred quadrillonth?
dickinsm at gmail.com
Fri May 22 22:05:59 CEST 2009
On May 22, 3:28 pm, Steven D'Aprano <st... at REMOVE-THIS-
> On Thu, 21 May 2009 18:30:17 -0700, Gary Herron wrote:
> >> In py3k Eric Smith and Mark Dickinson have implemented Gay's floating
> >> point algorithm for Python so that the shortest repr that will round
> >> trip correctly is what is used as the floating point repr....
> >> --David
> > Which won't change the fact that 0.8 and lots of other favorite floats
> > are still not representable exactly, but it will hide this fact from
> > most newbies. One of the nicer results of this will be that these
> > (almost) weekly questions and discussions will be come a thing of the
> > past.
> > With a sigh of relief,
> Yay! We now will have lots of subtle floating point bugs that people
> can't see! Ignorance is bliss and what you don't know about floating
> point can't hurt you!
Why do you think this change will give rise to 'lots of subtle
floating point bugs'? The new repr is still faithful, in the
sense that if x != y then repr(x) != repr(y). Personally, I'm
not sure that the new repr is likely to do anything for
floating-point confusion either way.
What's gone in 3.1 is the capricious nature of the old "produce
17 significant digits and then remove all trailing zeros" rule
For a specific example of the randomness of the current repr
rule, choose a random decimal in [0.5, 1.0) with at
most 12 places (say) after the decimal point; for example, 0.567819.
Now type that number into Python at the interpreter prompt.
Then there's approximately a 9% chance (where the number 0.09 comes
from computing 2.**53/10.**17) that you'll see the number you
typed in (possibly with trailing zeros removed if you typed something
like 0.846100), and a 91% chance that you'll get the full 17
Try the same experiment for random decimals in the
interval [1.0, 2.0) and there's about a 45% chance you'll get
back what you typed in, and a 55% chance you'll get 17 sig. digs.
With the new repr, a float that can be specified with 15 significant
decimal digits or fewer will always use those digits for its repr.
It's not a panacea, but I don't see how it's worse than the old
More information about the Python-list