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.�� There *is* point in having fixed-point decimal numbers as they are a perfect match for SQL data bases and several programming languages.

I've now located a PDF of the USGA Rules of Handicapping.�� Wow.�� 128 pages.

And with all that they couldn't explain the calculations precisely.�� 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).�� It is probably safe to assume rounding out.

Number>>roundOut

�� ^self negative

�������� ifTrue:�� [((self * 2 - 1) / 2) ceiling]

�������� ifFalse: [((self * 2 + 1) / 2) floor]

On Wed, 16 Jun 2021 at 02:06, Esteban Maringolo <emaringolo@gmail.com> wrote:

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@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.