> I would say, however, that the comparison
> of an integer to a flonum is an on-the-fence
> situation, but I'm inclined to insist, like
> David, that it be false, too.  If the
> integer is converted to a flonum, then it's apparent why this > must be so.  And to
> convert the flonum to an integer in this
> kind of situation is just wrong, unless one
> is trying to imitate FORTRAN's mixed mode.

I think any reasonable reading of the Number hierarchy suggests precisely that: Smalltalk numbers with their automated coercions expressly contemplate that numbers shall be converted as necessary.  Whether this is good or bad is not an issue on which I am prepared to pass, but there is no doubt that the auto-conversions is at present a Smalltalk feature.

Indeed, its far worse than you may have imagined.  "=" is so overloaded as to give meaning to expressions such as:

'1.0' + 0 = 1	which is true, and
'1.0' = 1		which is false.
 > So, like Dave, I see the hash behavior of
> really not being pertinent.

I disagree.  A number of Smalltalk classes depend upon the '='/hash property.  Either '=' should be defined to be identity with the default hash, or it should be redefined so as to assure the '='/hash concordance.

One serious aesthetic difficulty, of course, with algebraist's alternative definition of equality for floats is that it is not an equivalence relationship, because it is not transitive.  It would be a travesty to use the '=' sign with such a relation, better to use withinEps:of: or something like that.

And, while I appreciate the practical uselessness of strict floating point equality, it seems to me somewhat an exercise in sophistry to suggest that floats with identical values not be considered equal.  There are times when such comparisons are necessary, if only to give meaning to the order relationships (< and >).