[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