> 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