On Mon, 29 Nov 1999 16:26:34   David N. Smith (IBM) wrote:
>At 17:33 -0600 11/28/99, R. A. Harmon wrote:
>>I found the following:
>>
>>         2 = 2.0 -> true
>>         2 hash = 2.0 hash ->false
>>
>>I think this is a bug.  Is it?
>
>Good question. The blue book says:
>
>"... Any two objects that are equal must return the same value for 
>#hash. Unequal values may or may not return equal values for hash. 
>Typically, this integer is used as an index to locate the object in 
>an indexed collection..."
>[Pg 96].
>

[snip]


>
>I'd argue that having (2.0 = 2) answer false is better than forcing 
>the hashes to be equal. Besides, comparing floats is a sin one should 
>not encourage. I'd rather see #= answer false and that some other 
>method be used for 'has equivalent value'.

[snip]

I'm not sure this is a better answer than 
David's, but from a numerical standpoint
there is a lot of justification in 
defining

    2.0 = 2.0 --> false

or any two flonums.  This is because the
only way that flonums can be considered
"equal" is by specifying a context dependent
tolerance, as 

    ((a - b) abs) < tol

where tol is some multiple of machine
epsilon.

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.

So, like Dave, I see the hash behavior of
really not being pertinent.

>
>
>But you did ask a good question, and I didn't really answer it. 
>Anyone have a better answer?
>
[snip]


---
___________________________________________
demiourgos at smalltalk.org        squeak.org/
home.stny.rr.com/algebraist/ 
www.smalltalk.org/ jtgalkowski at alum.mit.edu



Get your FREE, private e-mail account at http://www.salonmember.com.