[Pharo-dev] summary of "float & fraction equality bug"

raffaello.giulietti at lifeware.ch raffaello.giulietti at lifeware.ch
Fri Nov 10 06:59:49 EST 2017

I would like to summarize my perspective of what emerged from the
discussions in the "float & fraction equality bug" trail.

The topic is all about mixed operations when both Fractions and Floats
are involved in the mix and can be restated as the question of whether
it is better to automagically convert the Float to a Fraction or the
Fraction to a Float before performing the operation.

AFAIK, Pharo currently implements a dual-conversion strategy:
(1) it applies Float->Fraction for comparison like =, <=, etc.
(2) it applies Fraction->Float for operations like +, *, etc.

The reason for (1) is preservation of = as an equivalence and of <= as a
total ordering. This is an important point for most Smalltalkers.

The reason for (2), however, is dictated by a supposedly better
performance. While it is true that Floats perform better than Fractions,
I'm not sure that it makes a noticeable difference in everyday uses.
Further, the Fraction->Float conversion might even cost more than the
gain of using Floats for the real work, the operation itself. The
conversion Float->Fraction, on the contrary, is easier.

But the major disadvantage of (2) is that it enters the world of limited
precision computation (e.g., Floats), which is much harder to
understand, less intuitive, more surprising for most of us.

So, it might be worthwhile to suppress (2) and consistently apply
Float->Fraction conversions whenever needed. It won't make daily
computations noticeably slower and helps in preserving more enjoyable
properties than the current dual-conversion regime.

Also, it won't prevent the numericists or other practitioners to do
floating point computations in mixed contexts: just apply explicit
Fraction->Float conversions when so desired.

This will be at odd with other Smalltalk implementations but might end
up being a safer environment.

I would like to thank Nicolas in particular for being so quick in
answering back and for the good points he raised.


More information about the Pharo-dev mailing list