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.

>"[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...

>In any of the examples, an attempt to print an infinity seems to cause
>Squeak to run amuck. It's the printing that is causing the low memory
>condition.

Interestingly enough, I've obtained low memory errors using Windows NT. But 
under Linux (2 different versions) the same virtual machines printed a Float 
Exception error and crashed (1.23 and 1.30)... really odd.

What I mean with this is not that (irritated tone) floats behave strangely: 
they do because they are floats (by definition). But if they behave 
strangely, then why care for a hash and equality since you can't guarantee #= will 
behave as expected? (this time, eXpected! ;-)

Andres.