[Pharo-dev] summary of "float & fraction equality bug"
fmateoc at gmail.com
Fri Nov 10 09:39:48 EST 2017
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
On 11/10/2017 7:18 AM, Tudor Girba wrote:
> Thanks indeed for the summary. I like this.
>> On Nov 10, 2017, at 12:59 PM, raffaello.giulietti at 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.
> "Yesterday is a fact.
> Tomorrow is a possibility.
> Today is a challenge."
More information about the Pharo-dev