Decimal arithmatic, was Re: Python GUI app to impress the boss?

[Bengt Richter]

On 29 Sep 2002 17:06:53 GMT, Christopher Browne <cbbrowne at acm.org> wrote:

>Quoth "Steve Holden" <sholden at holdenweb.com>:
>> <sismex01 at hebmex.com> wrote...
>>> >
>> [ ... ]
>> OK, so don't use whole pennies (or smallest currency) as your
>> base, use 10,000ths of a penny, but still use integer arithmetic
>> for your calculations.
>>
>> Floating point has too many rounding errors to be trustworthy;
>> or, looking at it from another angle, floating-point calculations
>> cannot be 100% accurate because of the way it's implemented.
Floating point IS EXACT over a large range of values and operations.
The problem is that people who don't understand exactly what is happening
want to be safe (fine) and substitute FUD or downright misinformation
(not fine) for fact in talking about it.
>
>The problem with FP is that FP involves the use of binary
>approximations, which commonly cannot exactly represent decimal
>values.
>
>Notably, the decimal fraction 0.1, which is /exactly/ 1/10, does not
>have any exact encoding in binary.  Its representation in binary is a
>repeating binary fraction.
How is that a significantly different problem from repeating decimal
fractions? (E.g., 1/3. or 1/7. or wxyz/9999. which will give you 0.wxyzwxzy..?)
>
>When the (not unreasonable!) expectation is that computers ought to be
>able to deal /exactly/ with plain simple decimal values turns out to
>be wrong, that ought to lead people to think.  
>
>But all too often it doesn't, as we get the typical reaction "Well,
>IEEE FP values can be sufficiently exact for this range of numbers;
>just use them right!"
>
>There's thirty years of experience now of programmers being able to
>use COBOL and PL/1 to manipulate decimal values without having to go
>into the numerical analysis effort to "just use FP right!"

There's thirty years of experience now of programmers being able to
use cars and trains to manipulate bodily location values without having to go
into the numerical analysis effort to "just use diesel compression ignition right!"

Many/most of them don't understand the details of the mechanisms they depend on,
and don't care whether they're using gas/sparks or steam/coal or diesel underneath.
Thirty years of commuting doesn't automatically give the commuter insight into
engine technology.

>
>The "FP way" is that once in a while, you've got to insert operations
>to round things appropriately.  The "old school" folks can
>legitimately gripe that they had decimal types that never required any
>of that nonsense, and that they had those types before many of the
>modern developers were even born.
I'm curious what those "old school" folks thought their programs did when
they had to divide or multiply, and how they conceived of the general rules
behind the results they got ;-)

IMO the big point re use of any kind of arithmetic in a program is that the
definitive rules come from the customer's requirements (whatever the process
of determining those ;-), and should be recorded as an unambigous specification.

Then it's either implemented correctly or not, and it doesn't matter if you are
internally manipulating decimals with digits represented in bi-quinary
or using floating point, other than optimization or real time issues (ok
possibly also understandability issues for the lucky maintainers ;-)

A customer who wants to convert between European currencies according to law
will probably have references to those laws in his spec. A customer who wants to
control machinery or compress music is going to give you other rules to get right
(not unlikely among them to watch out for patent and copyright law ;-)

Regards,
Bengt Richter