On Wed, Jun 16, 2021 at 10:52 AM Sven Van Caekenberghe <s...@stfx.eu> wrote: > > I am also a bit intrigued by this. Like you said: several other programming > languages (I tried a couple of Common Lisp and Scheme implementations) do the > same as Pharo, but handheld calculators, normal and scientific, do not. > > I think that going for 1/10 fractions/precision is not going to help: you got > a division by 113 in your formula > [https://en.wikipedia.org/wiki/Handicap_(golf)], this will give smaller > fractions.
And the reasons behind why they chose 113 are still unknown, because that number is used to get a "difficulty coefficient", so if the course is rated a 125, then 125/113 will give you roughly a ~1.1 coefficient. They could have used 100. > The problem is not the calculation (modern 64-bit floats as in Pharo are > plenty accurate), it is how you handle results. You should just round it > correctly and be done with it. > Note that > a roundTo: 0.00000000000001. (1e-14) still gives 4.5 > it is only one step further that you hit the limit and get the ugly but > correct result. I'm not doing that, and I only store the original number (which has a fixed decimal) and the "rounded" (to no decimals) number, all intermediate numbers are re-calculated (maybe cached) but not stored elsewhere. What I might be doing wrong is to store the original index as float instead of a Decimal number. > When computing with money, you would be inclined to put everything in cents > (because you cannot divide them further). But once you start computing > percentage discounts or taxes, you again get problems. At each of those steps > you must make sure that no cents are lost. And that includes adding a "rounding" item for any difference in all invoices, orders, etc. Regards! Esteban A. Maringolo
