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