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
|