On 16/06/2021 15:52, Sven Van Caekenberghe wrote:

Handheld calculators use decimal floats, not binary floats. That doesn't
remove rounding issues, but it makes conversion to and from print
representations loss-free.

Konrad

On Wed, Jun 16, 2021 at 10:49 AM Richard O'Keefe raoknz@gmail.com wrote:

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.

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.

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.

Try to ask one federation how they calculate the PCC, and they won't
tell you, it's like the coca-cola formula.

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.

On Wed, Jun 16, 2021 at 10:52 AM Sven Van Caekenberghe sven@stfx.eu wrote:

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.

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.

And that includes adding a "rounding" item for any difference in all
invoices, orders, etc.

Regards!

Esteban A. Maringolo

I didn't know there were decimal floats.

Are they used elsewhere?

Esteban A. Maringolo

On Wed, Jun 16, 2021 at 11:20 AM Konrad Hinsen
konrad.hinsen@fastmail.net wrote:

mmm, this is interesting.

It would be possible (and maybe it has already been done) to implement/add such a decimal floating point number to Pharo. It would require reimplementing all operations from scratch (esp. sin/cos/tan log/exp and so on), it would be slow, but interesting.

Sven Van Caekenberghe sven@stfx.eu writes:

That would be an interesting experiment indeed. Either use one of the
IEEE754 decimal float formats
(https://en.wikipedia.org/wiki/Decimal_floating_point), or Douglas
Crockford's DEC64 proposal (https://www.crockford.com/dec64.html, which
strangely enough does not refer to the older IEEE standard). There are
implementations of both for various other languages that can serve as
inspiration.

Konrad.

2Decimal floats are (a) part of the IEEE 758-2008 standard for
floating-point arithmetic,
(b) implemented as part of the instruction set in IBM z/Series and
POWER computers,
(c) allowed for in the current C standard, (d) partially supported by GCC
https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Decimal-Float.html
and (e) available for most machines via the "reference implementation" in C.
The current COBOL standard basically defines its arithmetic in terms of this.
Java of course has BigDecimal.  While decimal floats became part of IEEE 754 in
2008, they were previously covered by IEEE 854.

Reverting to ScaledDecimal, let us consider the 10.0s1 / 3 example.
There is a huge problem here with no really satisfactory answer.
In my library, it currently answers 3.3s1, exactly equal to 33/10.
In Squeak/Pharo, it answers "I am really 10/3 but print me with one decimal",
so you see 3.3a1 but it behaves like 10.3.
In VisualAge Smalltalk you get  3.333333333333333333333333333333
If it were not for the fact that the ANSI Smalltalk standard appears to
require that <scaled decimal> / <integer> yield a <scaled decimal>,
I would prefer to answer 10/3.  Decimals just plain are not closed under
division (although they are closed under addition, subtraction, and
multiplication).  When it comes to scaled decimals, the ANSI Smalltalk
standard is frankly a mess.  Amongst other things, it defers the
semantics of operations on them to the Language-Independent
Arithmetic standard, which explicitly denies having anything to say about them!

I understand why my library does what it does.  I even tried to
publish a paper about it.
I understand why VisualAge Smalltalk does what it does.  (I've read
IBM/360 PrincOps.)
I do NOT understand why Squeak and Pharo do what they do, and if anyone knows
the rationale for their ScaledDecmal please tell me.

On Thu, 17 Jun 2021 at 06:29, Esteban Maringolo emaringolo@gmail.com wrote:

"first we are not good in math"
First, I am not criticising YOU.  Pharo's weird ScaledDecimal is
Squeak's weird ScaledDecimal
and you have not changed it.  Fine.
"second Pharo is what we have and we never said that it is the best
system ever"
True, but irrelevant.
"third I never saw a piece of code from you"
That is not true.  Why, in this thread alone I contributed
#roundOut.  I have provided several
pieces of code in this mailing list over the years. You can say that
my code is no good, or
that you don't want it, or that you think there is a better way to
do the (admittedly small)
things that I have provided, but if you never saw them you must have
shut your eyes.
In addition, a snapshot of my system is available on the web for
anyone to play with.
I shall post here when my GitHub repository is populated; I just
have to clear a few more
things out of the local directory that I don't have the right to distribute.
(For example, benchmarking my CSV library against NeoCSV meant having to have
NeoCSV, but it's not mine to distribute.)

On Thu, 17 Jun 2021 at 08:45, ducasse stepharo@netcourrier.com wrote: