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