Hi.

>>>"[1]" (10 raisedToInteger: 600) = (10.0 raisedToInteger: 800)  "alt-p"
>>Nonono.... (10 raisedToInteger: 600) is anInteger, while the other (if 
>>finished correctly) is aFloat.
>Correct.  The problem occurs when the #= message is sent to the 
>LargePositiveInteger with the argument a Float (+Infinity).  This causes 
>the LargePositiveInteger to be adapted to a Float (resulting in 
>+Infinity, as well).

I guess the conversion should be aborted if the converted value is 
infinity. Anyway, I think that anInteger = aFloat should answer self error: 'Should 
not perform'.

>>If aFloat turns out to be infinite, an error should be posted.
>This would have to be tested in the Float primitives in the VM whenever 
>an overflow (or NaN, I suppose) is generated.  However, I *think* (VM 
>experts correct me, here) that all they can do is fail rather than 
>returning a succesful value, so all of the Float code that invokes 
>primitives would have to be rewritten to test and reflect this 
>overflow/exception failure.

Maybe it's already fixed, but I still use 1.23... so I still can't check 
it. BTW, I couldn't figure out what NaN stands for. Could you please tell me?

Wild guess: Not a Normalized answer...

>The IEEE "default" operation is to silently return the default values 
>(Inf or NaN), rather than generating an exception.  What should the 
>standard for Squeak be?

I think that the default operation should be adopted, and then that the 
numbers in Squeak behave adequately with respect to those answers. For instance, 
if aFloat turns out to be +inf, then it cannot be compared for equality to 
anInteger (for instance), since:

(10 raisedToInteger: 1000) = (10.0 raisedToInteger: 1000)

should answer false, not true (no float exists for that integer). What I 
don't like about this is the whole idea of using #= where it doesn't fit. It's 
much more comfortable to let them be #=, only when it works as expected. 
Leandro Caniglia had some trouble with floats when crunching money amounts 
because of the error carried all over. The figures he was working on weren't that 
big. He had specific trouble with a float around 2200, and had pinpointed the 
exact numbers involved.

IMHO, using #= isn't correct when comparing floats with integers or 
fractions. Mainly because, in this case, Floats belong to the 
LimitedPrecisionArithmetic world, whereas IntegersAndFractions belong to the 
ArbitraryPrecisionArithmetic universe. Both IntegersAndFractions are subsets of Rationals thought 
up to represent any desired rational number. On the other hand, Floats are 
thought up to lower the space used up to represent such numbers. John von 
Neumann was really against them. When he died in 1956, people started to use floats 
instead of bigIntegers. Ok, at that time big numbers could eat up all the 
memory available. This is hardly the case today. Operation is also faster with 
floats (for big numbers). I see it as a Speed vs. Accuracy choice... you can 
have only one of those. I think that if you choose one, then you should stick 
with it. Incidentally, transitions between those two only increase the error 
already accumulated.

Andres.