At 10:29 -0500 2/17/98, sqrmax at cvtci.com.ar wrote:
>Hi.
>
>>Floats only have a maximum exponent of about 308 when expressed in decimal.
>>It looks like Squeak is failing to detect exponent overflow.
>>(10.0 raisedToInteger: 307) hex  '7FAC7B1F3CAC7437'
>>(10.0 raisedToInteger: 308) hex  '7FE1CCF385EBC8A3'
>>(10.0 raisedToInteger: 309) hex  '7FF0000000000000'
>
>I didn't know that message... neat.
>
>>"[1]" (10 raisedToInteger: 600) = (10.0 raisedToInteger: 800)  "alt-p"
>>These are equal since both expressions end up answering a float with a
>>special value indicating positive infinity. Positive infinities are always
>>equal.
>
>Nonono.... (10 raisedToInteger: 600) is anInteger, while the other (if
>finished correctly) is aFloat. If aFloat turns out to be infinite, an error
>should be posted.

But when you try to compare them, the integer is coerced to a float. I
agree that floats need some bug fixes, and there is an effort underway to
fix things.




>>"[2]" (1 to: 1000) select: [:one | ((10 raisedToInteger: one) = (10.0
>>raisedToInteger: one)) not] "alt-p"
>>
>>Several things are happening with these results; first, not all integers
>>with the value 10^n are equal to a float with the value 10.0^n (for the
>>same n). This test violates a basic principle of floating point arithmetic:
>>never compare for equality.
>
>Ok, then why care for an equivalent hash for both floats and integers? See?
>1 = 1.0 should be false, since if that was true, then why should this
>evaluate to true also?
>
>(10 raisedToInteger: 25) = (10.0 raisedToInteger: 25)
>
>Equality only happens in a few cases...


No argument from me! Integers and floats with the 'same values' should not
have the same hash IMHO. (See my earlier posts on this issue.)

Dave

_______________________________
David N. Smith
IBM T J Watson Research Center
Hawthorne, NY
_______________________________
Any opinions or recommendations
herein are those of the author
and not of his employer.