same here
I always use aFloat closeTo: bFloat
Stef
closeTo: is not bad, but 0.0001 accuracy is really something arbitrary. An optional accuracy argument with default value 0.0001 would be better, like Andres suggested:
laysWithin: epsilon from: 2
Back to Andres very clever mail :
In other words, comparing constants makes it look much simpler than what it really is. Reading something like anInteger = 2.0 would be, from my point of view, highly questionable because it is an assertion that an approximation has an *exact* value. Nonsense.
That is the very right answer to something i said but did not find satisfying, if not stupid : i said Fraction are more general than Float, so Float could eventually convert to Fraction for doing arithmetics... ksss
The other point of view is to say that Float are inexact arithmetic, Fraction and Integer are exact.
And in this case, adding something exact with something inexact gives me something inexact. So this is a good reason for converting to Float.
Other points were already discussed, and we now have all elements in mind and must make a decision between the three possibilities: a) let things as is with broken Set and hash (meaning go to hell with your mixed Set) b) change int=float to be never true (implementation very easy, possible nasty side effect in existing code) c) change int=float to be true only if exact representation are equal (implementation already on mantis, but great hash code slow down)
What is the right place for such a vote ? Squeak chat ? squeak-dev ? mantis ?
Nicolas