Float bug toolkit: what the hash is this?
tim at jumpnet.com
Tue Feb 17 18:20:08 UTC 1998
>>"" (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
>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
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?
More information about the Squeak-dev