On 11/10/2017 11:33 AM, [email protected] wrote:
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.
Good point. I agree that Float -> Fraction is the more desirable mode
for implicit conversion, since it can always be done without changing
the value.
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.
One problem is that we make it easy to create Floats in source code
(0.1), and we print Floats in a nice decimal format but by default print
Fractions in their reduced fractional form. If we didn't do this,
Smalltalkers might not be working with Floats in the first place, and if
they did not have any Floats in their computation they would never run
into an implicit conversion to *or* from Float.
As it is, if we were to uniformly do Float -> Fraction conversion on
mixed-mode operations, we would get things like
(0.1 * (1/1)) printString -->
'3602879701896397/36028797018963968'
Not incredibly friendly.
Regards,
-Martin
