On Wed, Jun 16, 2021 at 10:52 AM Sven Van Caekenberghe <sven@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