On 2017-11-10 19:45, Martin McClure wrote: > On 11/10/2017 03:59 AM, [email protected] 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.
