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.