BUG gst2.2: Fraction hash

Fraction>>hash does inline Fraction as Float with a different algorithm
than Fraction>>asFloat...

Consequently, when numerator and/or denominator grows big, a bug appears:

| xFrac xFloat |
xFrac := 9/10 raisedToInteger: 400.
xFloat = xFrac asFloatD.
xFrac hash = xFloat hash

xFrac and xFloat will answer true to equality (this is arguable, because
only their floating point approximation are equal, not their
exactFraction representation, but this is another thread).

But their hash code will not be equal... Bad thing for Set and
Dictionary mixing Fraction and Float...


Nicolas Cellier



_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk

> xFrac and xFloat will answer true to equality (this is arguable, because
> only their floating point approximation are equal, not their
> exactFraction representation, but this is another thread).

That's a bug, but not one for which I have a quick solution except
making Fractions "more general" than Floats (in fact they are) and
implementing

Fraction>>coerce: x
     ^x asExactFraction

Any objections?  This is a 2.4 change anyway.

Paolo


_______________________________________________
help-smalltalk mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/help-smalltalk