Float bug toolkit: what the hash is this?
sqrmax at cvtci.com.ar
sqrmax at cvtci.com.ar
Tue Feb 17 22:58:02 UTC 1998
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.
More information about the Squeak-dev
mailing list
|