On 2017-11-10 19:45, Martin McClure wrote:
On 11/10/2017 03:59 AM, raffaello.giulietti@lifeware.ch wrote:
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.
[...]
Thanks for the summary, Raffaello. One can choose to convert Float -> Fraction (because fraction is the more general format, in that it can represent more of the real numbers) or to convert Fraction->Float (because a Float is considered an approximation of a real number).
But more important, I think, is that whichever choice is made, the *same* choice must be made in *all* operations that involve both Floats and Fractions.
Regards, -Martin
Doing only Fraction->Float conversions in mixed mode won't preserve = as an equivalence relation and won't enable a consistent ordering with <=, which probably most Smalltalkers consider important and enjoyable properties. Nicolas gave some convincing examples on why most programmers might want to rely on them. Also, as I mentioned, most Smalltalkers might prefer keeping away from the complex properties of Floats. Doing automatic, implicit Fraction->Float conversions behind the scenes only exacerbates the probability of encountering Floats and of having to deal with their weird and unfamiliar arithmetic.