Good summary. I must add to comparison and operations, I’d add encoding, where ASN.1 Reals MUST convert to Float before encoding with mantissa, exponent, etc. Here is another Fraction -> Float conversion. As well as ScaledDecimal -> Float conversion.
Sent from ProtonMail Mobile On Fri, Nov 10, 2017 at 06:59, <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
