Hi Sven, I accidentally skipped this.
How is this different from the GRNumberPrinter? Where is the code available? 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
