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