On Wed, Jun 16, 2021 at 10:49 AM Richard O'Keefe <rao...@gmail.com> wrote: > The problem is that while it is possible to read the ANSI Smalltalk standard > as requiring ScaledDecimals to be fixed point numbers (which are a kind of > exact rational number of the form x * 10**y, x and y integers), in Squeak and > Pharo ScaledDecimal numbers are NOT fixed-point numbers. They are unlimited > rational numbers with the scale being used for printing purposes only. This > creates enormous confusion and I really don't see any point in Squeak/Pharo > ScaledDecimal existing at all.
I only used decimals in other platforms, and only for accounting purposes, but to me if two scaled decimals print the same but answer false to #= then something is wrong conceptually. I can identify the issue, but the reasoning behind how it works, or even more, how to fix it, is above my level. > There *is* point in having fixed-point decimal numbers as they are a perfect > match for SQL data bases and several programming languages. That's the only use I gave it. So if we divided 10.0s1 / 3 ended up with 3.3s1 each, and we had to calculate the rounding errors (0.1s1 in this case) to make all balance. > I've now located a PDF of the USGA Rules of Handicapping. Wow. 128 pages. That's just USGA, there is a "World System" but each "region" or local federation does a variation of the "world system". So Belgium does one thing, Australia another one, Argentina another one, England decided to only take one part... standards, they call it :-) I Implemented a couple of them. > And with all that they couldn't explain the calculations precisely. Try to ask one federation how they calculate the PCC, and they won't tell you, it's like the coca-cola formula. > Rounding > arrives in more than one place. For example you might have to average the > best 1-8 of the last (as many as are available up to 20) scores and then round > to one decimal, but it is not stated how ties are to be broken (which can > arise > for the best 2, 4, 6, or 8). In this computation, the tie doesn't matter, because you start with an _already rounded_ number (called a "differential"), so it doesn't matter if you choose 11.4 from the 5th or 11.4 from the 19th. The rounding happens at the very end and determines a new rounded (to one decimal) number that's going to be used in other formulas (like the one that re-kicked this thread). The ties in competitions are solved differently. In real tournaments by playoff, or in amateur tournaments either by playoff or by a hole by hole comparison. If that even happens[*], there is the option to toss a coin to untie it. [*] In +400 tournaments managed by my software (involving ~15000 scorecards), that never happened. So to wrap up and bring it back to the topic, a proper ScaledDecimal implementation would help me storing the numbers as such guaranteeing no floating point funny thing happens, but since there is no such thing, I'll rather build the scaled decimals manually (e.g. ScaledDecimal fromFraction: 67/10) or not use scaled decimals and try to use the Fractions directly wherever possible. It's always good to learn new things.
