Fraction equality and Float infinity problem
Andreas Raab
andreas.raab at gmx.de
Tue Mar 28 10:45:31 UTC 2006
Wow. Great catch. Clearly, this is broken. I think we need to change
this coercion to something that deals with the issue properly (e.g.,
responding false to the comparison in question). Any ideas how to fix that?
Cheers,
- Andreas
nicolas cellier wrote:
> Large Fraction asFloat do overflow and answer Float infinity.
> ((11 raisedTo: 400) / 2) asFloat = Float infinity. "is true"
> So far, nothing wrong, except i prefer exception, but that was another
> discussion.
>
> But then they also equal Float infinity, and that sound strange to me:
> ((11 raisedTo: 400) / 2) = Float inifinity. "is true"
>
> What is bad in this behavior ? It is that you don't have equality transitivity
> property any more, and that is a flaw:
> ((11 raisedTo: 400) / 2) = Float inifinity. "is true"
> ((13 raisedTo: 400) / 2) = Float inifinity. "is true"
> ((11 raisedTo: 400) / 2) = ((13 raisedTo: 400) / 2). "is false"
>
> Then you can expect very weird bugs again in Sets. Add these 3 objects to a
> Set. Since transitivity is broken, the size of the set will vary according to
> the order you will add objects to it, the hash code algorithm and the set
> capacity. Something very nasty.
>
> Sure, few people use Large Fractions, and knowing this, they'd rather not, but
> this is not the right argument.
>
> Also, the hash correction i'am proposing is likely to make things worse.
> So we have to fix this one. Any idea but testing for infinity in
> adaptToFraction:andSend: / adaptToFloat:andSend: ?
>
> This is another reason why i really prefer arithmetic exceptions: handle such
> case. But i cannot move to arithmetic exception alone.
>
>
>
More information about the Squeak-dev
mailing list
|