Float comparison bug
Hernan Wilkinson
I'm having a problem comparing a floats.
I get false when I inspect:
(1.001 * 1000)=1001
But I get true if I inspect:
1001.0 = 1001
The representation of (1.001 * 1000) is not the same as 1001.0
I think this is a bug... Any suggestion?
Thanks,
Hernan.
Louis LaBrunda
This is a common problem with float data in any language. It is a "feature" of
float data that doing some math on it brings out some fuzziness. It has to do
with representing a real number (the fraction part) in binary (base 2 or 8 or
16) as opposed to base 10. Comparing two floats or a float and an integer (or
any other data type) for equality is always risky. You might try to convert the
float to an integer (asInteger) first.
For example:
(1.001 * 1000) asInteger = 1001
answers true. This is because the comparison is forced to be between two
integers. In your example, the integer, 1001 is converted to a float and there
is some noise between that conversion and (1.001 * 1000).
You might also try ScaledDecimal numbers. They give you decimal values in a
smaller range than floats but can almost always be compared safely.
For example:
(1.001s3 * 1000) = 1001
and
(1.001s3 * 1000) = 1001s3
answer true.
Lou
-----------------------------------------------------------
Louis LaBrunda
Keystone Software Corp.
SkypeMe callto://PhotonDemon
mailto:L...@Keystone-Software.com http://www.Keystone-Software.com
Hernan Wilkinson
I knew about this problem with floats but it look so obvious...
It is a pitty that Smalltalk does not solve this problem automatically...
Thanks again.
Hernan.
John O'Keefe
Solve this problem automatically? Not likely in any programming language.
Just how close is close enough? If the 2 floats are different in the 3rd
decimal position, are they equal? What about the 9th? If you want to
implement a solution, then you could add a closeTo: or approximatelyEqual:
method to Float that would use an epsilon value to determine just how close
the 2 numbers should be. Or, better yet, use ScaledDecimal numbers as Louis
suggested.
John O'Keefe
IBM Smalltalk
"Hernan Wilkinson" <h.wil...@mercapsoftware.com> wrote in message
news:cip7hv$7nce$1...@news.boulder.ibm.com...
Hernan Wilkinson
before I explain what I meant, I'd like to say that I love Smalltalk,
I work with Smalltalk and I'm not even thinking about going to a
"oriented language" like java o c#.
Now, when I said "automatically" I did not mean that Smalltalk should
know "how close" is a float of another float that represents the same
number as the first float (even it sounds crazy to talk like this!).
Isn't it obvious if you write (1.001 * 1000)=1001 that the result
should be true?... but it returns false!!...the current implementation
is not "intention revealing".
Lou suggest that I can use ScaledDecimal, but with scaled decimal I
have to write 1.001s3 instead of 1.001 and that's not natural.
My questions is, why do we have to bother about precision when I'm
not telling that to Smalltalk?... Dan Ingalls once said something like
"the implementation details should be hidden"
What I'm suggesting is that the Smalltalk parser should not use float
for numbers with decimal point unless I tell it to. It could use
fractions, for example, so I don't loose precision unless I want to
(that is, if I want to use Floats).
So, if I write (1.001 * 1000), the parser would convert that to
(1001/1000) * 1000. Doing so, (1.001 * 1000)=1001 would return true and
a lot of confusion would be avoided.
You can say, "well, when you write 1.001 you are telling Smalltalk to
use a float". That's true, and that is what I'm questioning... why a
float? I think it would be better another representation that does not
loose precision.... also I promise to put an "intention revealing"
subject the next time...
Anyway, that was what I meant.
Hernan.