On 11/10/2017 9:39 AM, Florin Mateoc wrote: > I think we should also mention that the literal 0.1 is not the number in base > ten that we all learned in school, despite > both using base 10 for printing and despite both being printed the same way - > this is the crux of the problem. > > But there is such a number in the system, called ScaledDecimal, for which the > equality stands: > > 0.1s = (1/10) > > We could have chosen ScaledDecimal as backing for our decimal literals (the > literal 0.1 being translated by the > parser/compiler as a ScaledDecimal and only have say the literal 0.1f being > translated to an imprecise float) and we > would not have had this problem. We could probably still do it > > Florin
Sorry to follow up on myself, but the more I think about it, the more I like my own proposal It would make the choice/compromise to be fast but imprecise explicit > > On 11/10/2017 7:18 AM, Tudor Girba wrote: >> Thanks indeed for the summary. I like this. >> >> Doru >> >> >>> On Nov 10, 2017, at 12:59 PM, raffaello.giulie...@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. >>> >>> 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. >>> >>> Greetings >>> Raffaello >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> >> >>
