> On 15 Jun 2021, at 16:19, Esteban Maringolo <emaring...@gmail.com> wrote:
>
> Hi Sven,
>
> I accidentally skipped this.
>
> How is this different from the GRNumberPrinter?
It is similar, but different (it does several things to produce cleaner
numbers). Basically, when I produced certain JSON with floats that were results
of calculations, I got these very long, ugly numbers. Forcing them to a certain
precision always added trailing zeros and made them floats. I also wanted
integers to be printed when possible (1 instead of 1.0, or 0 instead of 0.0). I
also have automatic switching to scientific notation outside a certain range.
> Where is the code available?
It is part of NeoJSON, https://github.com/svenvc/NeoJSON
Keep in mind that this is just an unfinished experiment.
> Thanks!
>
> Esteban A. Maringolo
>
> On Mon, Jun 14, 2021 at 6:30 PM Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>
>> BTW, I recently wrote my own float printer, as an experiment.
>>
>> NeoJSONFloatPrinter lowPrecision print: a.
>>
>> => 4.5
>>
>> What I wanted was a human friendly, compact float printer, that tries to go
>> for the shortest, simplest number. It prefers integers and goes to
>> scientific notation when needed, while limiting the precision. Maybe it is
>> interesting to look at the code.
>>
>> But I am far from an expert.
>>
>>> On 14 Jun 2021, at 23:23, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>>>
>>>
>>>
>>>> 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
