Float equality? (was: [BUG] Float NaN's)

Chris Muller afunkyobject at yahoo.com
Tue Sep 14 17:45:13 UTC 2004


Travis Griggs wrote:

I remember researching this to try and get VW up to date w.r.t. ieee fp 
math and learning something interesting things about NAN. It is the 
singularity event horizon of fp math. Any math you do with it will turn 
into a NAN. Even +/-infs. All roads lead to NAN. And when you get 
there, it refuses to be "truth"ful about anything...<snip> The thing is the
"false" hole.

===

I love this Hawking'esh description!  :)  While we're on the subject, can
anyone tell me whether Float equality is a reliable concept in a program?

For example:

	101.10001 = 101.10001  "true"

but:

	(Float fromIEEE32Bit: (101.10001 asIEEE32BitWord)) = 101.10001 "false"

Why?  Ahh, here we see the precision is skewed a bit in the to/from conversion:

	(Float fromIEEE32Bit: (101.10001 asIEEE32BitWord))  "101.1000061035156"

But, yet:

	(Float fromIEEE32Bit: (101.10001 asIEEE32BitWord)) = 101.1000061035156

still returns false!

and further:

	(101.1000061035156 roundTo: 0.00001) = 101.10001

also answers false!

None of this makes sense to me so, obviously, I have a poor understanding of
the underlying Float implementation, but that's not what I want to know more
about at the moment.  What I'm wondering is does anyone have experience with
using Floats in a program that caused equality logic to be skewed and what are
some best-practices for dealing with it?  For example, I thought using roundTo:
might take care of it, but the above example proves this not to be the case.

If I want to write a financial application, should Floats be avoided? 
Fractions provide unlimited precision at a pretty severe performance cost and
Decimals appear to use an underlying Fraction too, not to mention there are not
many users of Decimal so its kind of a murky cloud for me.

Any commentary is appreciated.

 - Chris



More information about the Squeak-dev mailing list