Float bug toolkit: what the hash is this?

Tim Olson tim at jumpnet.com
Tue Feb 17 18:20:08 UTC 1998


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

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).

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

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?



     -- tim





More information about the Squeak-dev mailing list