4 hundred quadrillonth?

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Fri May 22 22:53:35 EDT 2009


On Fri, 22 May 2009 13:05:59 -0700, Mark Dickinson wrote:

>> > 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.

I'm sorry, did I forget a wink? Apparently I did :)

I don't think this change will *cause* bugs. However, it *may* (and I 
emphasis the may, because it hasn't been around long enough to see the 
effect) allow newbies to remain in blissful ignorance of floating point 
issues longer than they should.

Today, the first time you call repr(0.8) you should notice that the float 
you have is *not quite* the number you thought you had, which alerts you 
to the fact that floats aren't the real numbers you learned about it 
school. From Python 3.1, that reality will be hidden just a little bit 
longer.


[...]
> 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 repr.

It's only worse in the sense that ignorance isn't really bliss, and this 
change will allow programmers to remain ignorant a little longer. I 
expect that instead of obviously wet-behind-the-ears newbies asking "I'm 
trying to creating a float 0.1, but can't, does Python have a bug?" we'll 
start seeing not-such-newbies asking "I've written a function that 
sometimes misbehaves, and after heroic effort to debug it, I discovered 
that Python has a bug in simple arithmetic, 0.2 + 0.1 != 0.3".

I don't think this will be *worse* than the current behaviour, only bad 
in a different way.


-- 
Steven



More information about the Python-list mailing list