> On 14 Jun 2021, at 22:44, Esteban Maringolo <emaring...@gmail.com> wrote:
> 
> I'm coming back to this because I've been bitten by these floating
> points things again.
> 
> If in Pharo [1] you do:
> a := 6.7 + (32.8 - 35)
> 
> It will produce:
> 4.499999999999997
> 
> Which, when rounded, will produce 4.

But,

a roundTo: 0.1 "=> 4.5"

> In other places [2] I do the same simple addition and subtraction it
> produces 4.5, that when rounded will produce 5.
> 
> I know now that Pharo doesn't lie to me while other systems do, and
> all that Richard pointed to before.
> 
> The issue here is that I'm following some calculation formula that was
> defined in some of the "other" systems, and so when I follow such a
> formula I get these edgy cases where my system produces a different
> output.
> 
> In this case the formula is for golf handicap calculations, and it
> caused my system to give 4 instead of 5 to a player, resulting in
> giving the first place to a player other than the one deserved.
> It was no big deal (it's not The Masters), but these cases appear from
> time to time.
> 
> Is there any way to "configure" the floating point calculation to
> behave as the "other systems"?
> 
> What is the best way to anticipate these situations, am I the only one
> being bitten by these issues?
> 
> Thanks in advance for any hints about these problems.
> 
> 
> Best regards,
> 
> [1] Dolphin Smalltalk, JS, Python, Ruby, Dart produces the same output as 
> Pharo.
> [2] VisualWorks, VAST, Excel, VB and all calculators I tried
> 
> 
> 
> Esteban A. Maringolo
> 
> On Tue, Sep 8, 2020 at 12:45 AM Esteban Maringolo <emaring...@gmail.com> 
> wrote:
>> 
>> On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <rao...@gmail.com> wrote:
>>> 
>>> "7.1 roundTo: 0.1 should return 7.1"
>>> You're still not getting it.
>> 
>> I was until Konrad explained it.
>> 
>>> Binary floating point CANNOT represent either of those numbers.
>>> You seem to be assuming that Pharo is making some mistake.
>>> It isn't.  All it is doing is refusing to lie to you.
>> <snip>
>>> The systems that print 7.1 are LYING to you,
>>> and Pharo is not.
>> 
>> I'm not assuming a mistake from Pharo, I had a wrong expectation what
>> to get if I round to that precision.
>> I don't know whether other systems lie or simply fulfill user
>> expectations, if you send the #roundTo: to a float, I did expect to
>> get a number with the same precision.
>> That is my expectation as a user. As in the other thread I expected
>> two scaled decimals that are printed equal to also be compared as
>> equal  (which they don't).
>> 
>> Whether there is a good reason for those behaviors is beyond my
>> current comprehension, but it certainly doesn't follow the "principle
>> of least surprise".
>> 
>> In any case, the method proposed by Tomohiro solved my issues.
>> 
>> Regards,
>> 
>> Esteban A. Maringolo

Reply via email to