[Tutor] Float precision untrustworthy~~~

Jacob S. keridee at jayco.net
Tue Mar 29 05:13:10 CEST 2005


I've already deleted the recent thread--

But sometimes I agree with he who said that you can't trust floats at all.

The scientific theory suggests that if an output is not what it should be, 
then the hypothesis is untrue.
In this case, the hypothesis is the fact that float division should always 
produce the same output as our decimal division used in common schools 
today. Since that is not always true, then floats are not trustworthy~~~ 
frankly, the mere fact that floats are difficult to check with equality has 
bitten me more than anything I've met yet in python.

For example -- Unfortunatley, I can't give you the full setup due to I have 
forgotten it.
But it dealt with a taking a float to a float power -- Ah,


Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> 64.0**(1/3.0) == 4
False
>>> 64**(1.0/3) == 4
False
>>> from __future__ import division
>>> 64**(1/3) == 4
False
>>> 64**-3 == 4
False
>>> a = 1/3
>>> a
0.33333333333333331
>>> 64**a == 4
False
>>> b = float(64)
>>> b
64.0
>>> b**a
3.9999999999999996
>>> round(b**a,9) == 4
True
>>> round(7/2) == 4
True
>>> round(7/2) == 3.5
False
>>>

Well, somehow, working it out part by part, splitting each float into a 
variable, I managed to get it to come out true without rounding. (Again, I'm 
sorry that I don't have that which works...)

The last three checks also show that you need to define the places argument 
to get a good answer. Why not just implement decimal or some equivalent and 
get rid of hidden, hard to debug headaches?    I understand uses of floats 
where the precision isn't exact anyway -- i.e. sqrt(2)

Oh, by the way, just because today I fight against floats, tomorrow I might 
fight for them. I just like pointing things out. ;-)

Jacob 



More information about the Tutor mailing list