On 15 Jun 2021, at 16:19, Esteban Maringolo <emaringolo@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 <sven@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 <sven@stfx.eu> wrote:
On 14 Jun 2021, at 22:44, Esteban Maringolo <emaringolo@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 <emaringolo@gmail.com> wrote:
On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <raoknz@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