[Pharo-dev] summary of "float & fraction equality bug"

Tudor Girba tudor at tudorgirba.com
Fri Nov 10 07:18:35 EST 2017


Thanks indeed for the summary. I like this.

Doru


> 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.
> 
> Greetings
> Raffaello
> 

--
www.tudorgirba.com
www.feenk.com

"Yesterday is a fact.
 Tomorrow is a possibility.
 Today is a challenge."








More information about the Pharo-dev mailing list