> 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