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

henry henry at callistohouse.club
Fri Nov 10 07:05:56 EST 2017


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.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20171110/1f032878/attachment-0002.html>


More information about the Pharo-dev mailing list