Decimal arithmetic as used in REXX

[Glen Ditchfield]

I found this in the World Wide Web Consortium's working draft for the data
model in the next version of forms (<http://www.w3.org/TR/xforms-datamodel/>)
It turns out that [ANSI X3-274] is the REXX language.  Maybe GnuCash can pick
up some implementation or interface tips there.

----------  Forwarded Message  ----------

The proposal is for XForms expressions to conform to
<http://www.w3.org/TR/xforms-datamodel/#ref-ansi-x3-274> [ANSI X3-274] for
arithmetic. This features full-function decimal floating point arithmetic
with integers as a seamless subset. It preserves matissa length, e.g. 1.20 x
2 gives 2.40 (not 2.4) and provides for an exact representation as expected
for values such as 0.1 (not 1/16 + 1/32 + 1/256 + 1/512 + 1/4096 + 1/8192 +
... ).

This standard has been used heavily over 16 years by IBM and its customers
and is based on feedback from users, mathematicians, data processing
experts, and financial experts, etc. The overhead in processing time is
expected to be negligible in practice, with a fixed code overhead of about 2
to 4 K bytes.


appendix_decimalAppendix C: Rationale Behind Decimal Arithmetic
(Non-Normative)


Contributed by Mike Cowlishaw, IBM

Why is decimal arithmetic the right thing to use?

-- Many common decimal quantities (for example, 0.1) cannot be represented
exactly in a binary floating point representation; binary floating point is
a lossy encoding of decimal numbers. This leads to anomalies, even after a
single operation, for example:

Division: 1/0.1 ==> 10 (correct) Remainder: 1%0.1 ==> 0.0999999999999995
(incorrect, it should be 0)

Anomalies build up even more rapidly under repeated operations.

-- These anomalies are visible even if rounding is applied (the latter
result, for example, rounds to 0.1 instead of 0).

-- The anomalies lead to discrepancies between the results obtained
'manually' and those obtained by computer. This makes it difficult and
expensive to verify algorithms and test software.

-- As a result, customers complain at unexpected results and there are
significant increased costs in application development, service calls, and
maintenance.

Issues of performance:

Binary floating point is often carried out in hardware, and is in that case
faster than decimal arithmetic which on most computers is implemented in
software. However:

-- Few commercial applications spend much time carrying out arithmetic;
measurements in an interpreted environment using decimal arithmetic suggest
a typical figure is 8% of execution time is in arithmetic.

-- Conversions between decimal and string (readable) forms are simpler and
more efficient than those between binary and string.

-- The bulk of numeric data stored in databases is held in decimal form (to
avoid the anomalies described above); converting these to and from a binary
form is inefficient as well as lossy.

-- In practice, the 'default' decimal precision (9 digits) can be very
efficiently implemented using 32-bit integers for mantissa and exponent.
This implementation would be especially attractive on 'small' devices.

-- In addition, all widely used microprocessor, mini, and mainframe
computers (other than RISC machines) provide native decimal instructions or
decimal adjustment operations.