Thanks Trygve and Andres,

I also agree that comparing float is a bad practice.
It is even worse outside squeak because of intel registers extra bits for
example (result will depend on use of registry or not and hence on compiler
optimization and neighbour code).

The question should (2 = 2.0) and (2.0 = 2.0) is interesting...

In my opinion, there are cases when float comparison is usefull: precondition
to guard against an exception (zero divide or whatever).

First solution i was proposing is to continue to answer true to that, since
 it can be valid as long as no inexact arithmetic took place (depends how we
 made the 2.0, but the conversion from string is OK).

I even happened to use float arithmetic once just to have cheap integer 
arithmetic on 53bits (OK, shame on me, but it works).

Hence we can modify = so as to answer true only in exact arithmetic sense
( (1/2)=0.5 but (1/10)~=0.1 ).

Concerning Set and hash code, we can make it working accordingly, using Float
asTrueFraction.
But there is a performance penalty (factor 100 on hash before optimization).

I am not totally opposed to more radical solution you seem suggesting: (2 =
2.0) never answer true.
In this case, we can still have efficient hash for comparing (2.0=2.0), and
 do not have to bother with Integer and Fraction.

There are some cases when i would like such a behavior:
For example, i want to use compiler to repeatedly evaluate an automatically
generated mathematical formula, but i face the too many literals byte code
limit. I can reduce number of literals by eliminating double entries, and use
a Set for that. Here, i do not want literal #(2.0) being replaced with #(2),
and in this case i would prefer 2~=2.0... (Yes, i can have array literals in
my formula due to matrix).

The only penalty of second solution is to break all bad-practice code...
It is always possible to force a conversion toward exact or inexact
arithmetic.
But people can have programmed with automatic conversion in mind...
For example, protect against zero divide with a~=0... (yes a isZero would be
better in this case).

Is there a lot such code in Squeak ? Hard to say...
We must inquire that and ask other squeakers opinion.
It is not a thin change...

Nicolas

Le Mercredi 29 Mars 2006 08:13, Trygve Reenskaug a écrit :
> I wholeheartedly agree. We have used tolerance tests for floats since 1962
> because equality tests are meaningless. = for floats should give error.
>
> Cheers
> --Trygve
>
> At 06:01 29.03.2006,  Andres wrote:
> >Hello ncellier,
> >
> >Tuesday, March 28, 2006, 7:25:46 AM, you wrote:
> >
> >nic> [number hashing is broken]
> >nic> What is your opinion ?
> >
> >IMHO... sometimes it may be convenient to have 2 = 2.0, but since they
> >represent different intentions, I would not expect that to happen.
> >Why should a perfectly specified integer be equal to, possibly, the
> >result of carrying calculations without infinite precision?  What
> >would it mean if theGreatDoublePrecisionResult = 2?  Wouldn't it be
> >more interesting (and precise) to ask laysWithin: epsilon from: 2?
> >
> >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.
> >
> > >From a more pragmatic point of view, there is also the issue of 2 =
> >
> >2.0, but things like
> >
> >   (1 bitShift: 1000) - 1
> >
> >cannot be equal to any floating point number supported by common
> >hardware.  Thus, exploiting anInteger = aFloat is intention obscuring
> >by definition since it may or may not work depending on the integer.
> >Again, highly questionable.
> >
> >In short: floating point numbers *may* be equal to integers, but the
> >behavior of #= cannot be determined a priori.  Since the behavior of
> >#= does not imply a relationship of equivalence, the behavior of #hash
> >is inconsequential.
> >
> >Adding integers and floats to a set gets messed up.  So we have two
> >options... a) don't do it because it is intention obscuring... or b)
> >make integers never be equal to floating point numbers.
> >
> >Same deal with fractions and the like.
> >
> >--
> >Best regards,
> >  Andres                            mailto:sqrmax at optonline.net

-------------------------------------------------------