- Pharo-users - lists.pharo.org

Re: Problem installing 9.0 on MacMini M1

by Tim Mackinnon

Worth saying that while Brew is handy on a mac (and avoid installing it as a sudo user) - you shouldn't need it do anything with Pharo either with with the launcher (graphical) or via the console (command line). Its worth checking you have properly read the download instructions on pharo.org - for command line it does say use "curl" and "wget if curl not available". For your pharo damaged question - have you tried just creating a fresh directory, cd'ing into it and then running the command line instructions for a fresh install. You can then make sure sure pharo works correctly command line - and if so, this is then possibly a 32 vs 64 bit image difference. You could investigate this - or simply create a new image and install your code into it as a fresh install - which might be better anyway, while your getting things sorted. Others may have more tips for you. Tim On Tue, 15 Jun 2021, at 5:58 PM, Rob Sayers wrote: > Hi, I can't help with the Pharo specific issue, but for installing brew, you can find the directions here: https://brew.sh/ > > On Tue, Jun 15, 2021 at 10:16 AM David Pennington <david(a)totallyobjects.com> wrote: >> Hi everyone. It is your favourite newbie speaking :-) >> >> I have now got a new M1 MacMini which I want to configure up as a server for my Seaside apps. >> >> So far, I have found that the Mac mini doesnât have wget or brew installed! I have sorted wget but not brew. >> >> Secondly, I have transferred all of my 9.0 stuff across but when I try and execute both paharo-ui or pharo (as terminal scripts) they both fail as they say that the âPaharoâ is damaged and canât be opened. You should move it to the bin. >> >> I can open Pharo 9.0 directly but it tells me that the VM is too old for this image. >> >> Can anyone help me please? (In words that I can understand:-) >> >> David > > > -- > Rob Sayers > www.robsayers.com >

June 15, 2021

Re: Problem installing 9.0 on MacMini M1

by Rob Sayers

Hi, I can't help with the Pharo specific issue, but for installing brew, you can find the directions here: https://brew.sh/ On Tue, Jun 15, 2021 at 10:16 AM David Pennington <david(a)totallyobjects.com> wrote: > Hi everyone. It is your favourite newbie speaking :-) > > I have now got a new M1 MacMini which I want to configure up as a server > for my Seaside apps. > > So far, I have found that the Mac mini doesnât have wget or brew > installed! I have sorted wget but not brew. > > Secondly, I have transferred all of my 9.0 stuff across but when I try and > execute both paharo-ui or pharo (as terminal scripts) they both fail as > they say that the âPaharoâ is damaged and canât be opened. You should move > it to the bin. > > I can open Pharo 9.0 directly but it tells me that the VM is too old for > this image. > > Can anyone help me please? (In words that I can understand:-) > > David -- Rob Sayers www.robsayers.com

June 15, 2021

Problem installing 9.0 on MacMini M1

by David Pennington

Hi everyone. It is your favourite newbie speaking :-) I have now got a new M1 MacMini which I want to configure up as a server for my Seaside apps. So far, I have found that the Mac mini doesnât have wget or brew installed! I have sorted wget but not brew. Secondly, I have transferred all of my 9.0 stuff across but when I try and execute both paharo-ui or pharo (as terminal scripts) they both fail as they say that the âPaharoâ is damaged and canât be opened. You should move it to the bin. I can open Pharo 9.0 directly but it tells me that the VM is too old for this image. Can anyone help me please? (In words that I can understand:-) David

June 15, 2021

Re: Rounding in Floats

by Sven Van Caekenberghe

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

June 15, 2021

Re: Rounding in Floats

by Esteban Maringolo

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

June 15, 2021

Re: Rounding in Floats

by Esteban Maringolo

Hi Richard, > Whether 6.7 - 2.2 gives 4.5 or something else is a subtle issue, > starting with the fact > that 6.7 and 2.2 cannot be represented precisely in floating-point > format. In this particular case, the errors happen to match up. > What you *can* rely on in Smalltalk is that (67/10) - (22/10) = (9/2). > > Let's just consider h * s / 113 + (r - p). > If h, s, r, and p are all exact numbers (Integers or Fractions) the > result will be an exact number. > So what kinds of number are h, s, r, and p, and *why* are they > like that? If you are reading them from a file, consider that > Fraction readFrom: '6.7' readStream >>> (67/10) I'm not reading them from a file, although some numbers come from an API as a JS number (float). Using Fractions wherever possible seems to be the right solution to this. And given that I already know the precision (it's always 1 decimal as much) I can turn everything into that and store them as DECIMAL in the database. I'm reluctant to perform such a change because everything has been working fine and this is just an edge case, but I think it is the right thing to do. > Is there a specification you could show us? There is no specification other than the formulas: https://www.usga.org/content/usga/home-page/handicapping/roh/2020-rules-of-… Section III -> Rules 6.1 and 6.2 There is only a remark after 6.1b that you must retain full precision in intermediate calculations. "the full calculated value is retained and rounding occurs only after the Playing Handicap calculation." > Some test data? Not that I could find, I've been adding cases to my tests to assert it behaves properly. Thanks! Esteban A. Maringolo On Tue, Jun 15, 2021 at 4:13 AM Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > On Tue, 15 Jun 2021 at 14:24, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > On Mon, Jun 14, 2021 at 10:37 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > > > For what it's worth, I expected ScaledDecimal to act like fixed point > > > arithmetic, and implemented it that way in my own Smalltalk library, where > > > two ScaledDecimals *do* print the same if and only if they are numerically > > > exactly the same. > > > What Squeak and Pharo do is exceedingly odd: a ScaledDecimal > > > is an exact rational number (Integer or Fraction) combined with a precision that > > > is used for printing, not for calculation. > > > > I pointed out before the weird behavior of ScaledDecimals in Pharo, > > two ScaledDecimal that print the same are not equal. Giving some weird > > comparison issues as result. > > > > > There really isn't any principle of least surprise when it comes to floating- > > > point arithmetic. It's full of surprises and edge cases. Excel in particular > > > is notorious for messing up due to trying to pretend all is well. > > > In this particular case, the exact result is 4.5 > > > > Well... for the end user, it produces what they'd expect. So it might > > mess up, but in a spreadsheet 6.7 - 2.2 should give 4.5. > > > > > There are at least three rules for rounding such numbers: rounding out (5), > > > rounding in (4), and rounding in [banker'salgorithm] (4 here, but 5.5 -> 6). > > > So you are pushing up against an edge case for exact hand calculation! > > > > I implemented a Float>>#roundedHandicap method that does something > > like the banking algorithm, but rounds positive numbers towards the > > next integer and negative numbers towards zero. > > E.g. > > 0.49 -> 0 > > 0.5 -> 1 > > -0.5 -> 0 > > -0.51 -> -1 > > > > Nothing uses more than one decimal, so a ScaledDecimal would work but > > the specification says that it should use all possible precision in > > intermediate calculations, so I cannot use it. > > > > > I think you need to re-express your entire calculation to use exact arithmetic. > > > > I really don't know how to do this, any pointers? > > > > Nothing is more straightforward than addition and subtraction to me, > > 6.7 - 2.2 is the simplest it can get. > > > > The common formula here is: h * s / 113 + (r - p), but in this > > particular case s was 113 so it removed the "troubling" part. > > > > > That or get agreement on "de minimis non curat lex". > > > > I had to search for that expression. Now I know, I agree. > > > > Regards, > > > > Esteban A. Maringolo > > > > > > > > > > > > > > > On Tue, 15 Jun 2021 at 08:45, Esteban Maringolo <emaringolo(a)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. > > > > > > > > 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(a)gmail.com> wrote: > > > > > > > > > > On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <raoknz(a)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

June 15, 2021

Re: Rounding in Floats

by Esteban Maringolo

Well... fixed point numbers (aka ScaledDecimals) had their issues as well. And in this particular case, it might cause issues, since the "full precision" (whatever that means) must be retained when using such a number to derive another one. E.g. in my case: ch := 6.7 + (32.8 - 35). "course handicap" allowance := 0.85. "85%" ph := (ch * allowance) roundedHandicap. "playing handicap" The #roundedHandicap is like #rounded but rounds -0.5 towards -1 instead of toward 0. My first approach was to use fixed points, but then I hit issues where some results also produced "wrong" numbers (according to the reference), also in Pharo some ScaledDecimals compare as different even when they're printed as the same (which is not correct, IMO). I just tested using everything as fractions and converting to float (or ScaledDecimal) at the very last step and it produces the expected result. I'll review and convert whatever is needed (including database fields) to work with this. The good thing is that all the involved numbers only have one decimal as much. Thanks! Esteban A. Maringolo On Tue, Jun 15, 2021 at 3:48 AM Steffen MÃ¤rcker <merkste(a)web.de> wrote: > > Have you considered using fixed-point arithmetic? For example: > 7.1s2 roundTo: 0.1s2 > > The rule of thumb I stick to is to use FP only if I know the inaccuracies > won't bite me. Funny enough, both 7.1 and 0.1 are already not accurately > representable as floats. (And by coincidence, I prepared exam questions > about floats for my students yesterday. ) > > Kind regards, > Steffen > > > Konrad Hinsen schrieb am Dienstag, 15. Juni 2021 07:02:30 (+02:00): > > > On 15/06/2021 01:03, Esteban Maringolo wrote: > > > Sure, but what initiated this thread was a reference to roundTo: 0.1 > > > which produced a "wrong" output. > > > > > > (9.1 + (-2.0)) roundTo: 0.1 "=> 7.1000000000000005" > > > 7.1 roundTo: 0.1 "=> 7.1000000000000005" > > > > > > However, at this point I know that Pharo "does the right, raw, thing" > > > (at least compared to other mainstream languages), but it still > > > produces a surprise effect. > > > > That's the "floating point surprise" that everyone has at some point, no > matter the language and runtime system. If that surprise is a problem for > you, are you sure that floating-point arithmetic is what you really want? > Maybe your needs are better served with integers and fractions. > > > > > > Konrad. > > > > > -- > Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com > herunter.

June 15, 2021

R: [ANN] Pharo-ODBC

by Lorenzo

Great work John! Tante grazie. Lorenzo Da: John Aspinall [mailto:john.aspinall@gmail.com] Inviato: lunedÃ¬ 14 giugno 2021 11:29 A: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Oggetto: [Pharo-users] [ANN] Pharo-ODBC There is now an ODBC framework for Pharo, available at the pharo-rdbms github site: https://github.com/pharo-rdbms/Pharo-ODBC This is based on the Dolphin Smalltalk Database Connection ODBC framework. Provided a suitable driver manager is installed this should work on MacOS and Linux in addition to Windows. Thanks to InfOil for supporting the development, to Torsten for tidying up and hosting the code, and Andy and Blair (Dolphin developers) for the original framework. Regards, John Aspinall

June 15, 2021

Re: Rounding in Floats

by Richard O'Keefe

Whether 6.7 - 2.2 gives 4.5 or something else is a subtle issue, starting with the fact that 6.7 and 2.2 cannot be represented precisely in floating-point format. In this particular case, the errors happen to match up. What you *can* rely on in Smalltalk is that (67/10) - (22/10) = (9/2). Let's just consider h * s / 113 + (r - p). If h, s, r, and p are all exact numbers (Integers or Fractions) the result will be an exact number. So what kinds of number are h, s, r, and p, and *why* are they like that? If you are reading them from a file, consider that Fraction readFrom: '6.7' readStream >>> (67/10) Is there a specification you could show us? Some test data? On Tue, 15 Jun 2021 at 14:24, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > On Mon, Jun 14, 2021 at 10:37 PM Richard O'Keefe <raoknz(a)gmail.com> wrote: > > > For what it's worth, I expected ScaledDecimal to act like fixed point > > arithmetic, and implemented it that way in my own Smalltalk library, where > > two ScaledDecimals *do* print the same if and only if they are numerically > > exactly the same. > > What Squeak and Pharo do is exceedingly odd: a ScaledDecimal > > is an exact rational number (Integer or Fraction) combined with a precision that > > is used for printing, not for calculation. > > I pointed out before the weird behavior of ScaledDecimals in Pharo, > two ScaledDecimal that print the same are not equal. Giving some weird > comparison issues as result. > > > There really isn't any principle of least surprise when it comes to floating- > > point arithmetic. It's full of surprises and edge cases. Excel in particular > > is notorious for messing up due to trying to pretend all is well. > > In this particular case, the exact result is 4.5 > > Well... for the end user, it produces what they'd expect. So it might > mess up, but in a spreadsheet 6.7 - 2.2 should give 4.5. > > > There are at least three rules for rounding such numbers: rounding out (5), > > rounding in (4), and rounding in [banker'salgorithm] (4 here, but 5.5 -> 6). > > So you are pushing up against an edge case for exact hand calculation! > > I implemented a Float>>#roundedHandicap method that does something > like the banking algorithm, but rounds positive numbers towards the > next integer and negative numbers towards zero. > E.g. > 0.49 -> 0 > 0.5 -> 1 > -0.5 -> 0 > -0.51 -> -1 > > Nothing uses more than one decimal, so a ScaledDecimal would work but > the specification says that it should use all possible precision in > intermediate calculations, so I cannot use it. > > > I think you need to re-express your entire calculation to use exact arithmetic. > > I really don't know how to do this, any pointers? > > Nothing is more straightforward than addition and subtraction to me, > 6.7 - 2.2 is the simplest it can get. > > The common formula here is: h * s / 113 + (r - p), but in this > particular case s was 113 so it removed the "troubling" part. > > > That or get agreement on "de minimis non curat lex". > > I had to search for that expression. Now I know, I agree. > > Regards, > > Esteban A. Maringolo > > > > > > > > > On Tue, 15 Jun 2021 at 08:45, Esteban Maringolo <emaringolo(a)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. > > > > > > 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(a)gmail.com> wrote: > > > > > > > > On Tue, Sep 8, 2020 at 12:16 AM Richard O'Keefe <raoknz(a)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

June 15, 2021

Re: Rounding in Floats

by Steffen MÃ¤rcker

Typo: FP should read floating point and not fixed point. Steffen MÃ¤rcker schrieb am Dienstag, 15. Juni 2021 08:47:24 (+02:00): > Have you considered using fixed-point arithmetic? For example: > 7.1s2 roundTo: 0.1s2 > > The rule of thumb I stick to is to use FP only if I know the inaccuracies > won't bite me. Funny enough, both 7.1 and 0.1 are already not accurately > representable as floats. (And by coincidence, I prepared exam questions > about floats for my students yesterday. ) > > Kind regards, > Steffen > > > Konrad Hinsen schrieb am Dienstag, 15. Juni 2021 07:02:30 (+02:00): > > > On 15/06/2021 01:03, Esteban Maringolo wrote: > > > Sure, but what initiated this thread was a reference to roundTo: 0.1 > > > which produced a "wrong" output. > > > > > > (9.1 + (-2.0)) roundTo: 0.1 "=> 7.1000000000000005" > > > 7.1 roundTo: 0.1 "=> 7.1000000000000005" > > > > > > However, at this point I know that Pharo "does the right, raw, thing" > > > (at least compared to other mainstream languages), but it still > > > produces a surprise effect. > > > > That's the "floating point surprise" that everyone has at some point, no > matter the language and runtime system. If that surprise is a problem for > you, are you sure that floating-point arithmetic is what you really want? > Maybe your needs are better served with integers and fractions. > > > > > > Konrad. > > > > > -- > Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com > herunter. > -- Gesendet mit Vivaldi Mail. Laden Sie Vivaldi kostenlos von vivaldi.com herunter.

June 15, 2021