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

[Chris Gonnerman]

----- Original Message ----- 
From: "Bengt Richter" <bokr at oz.net>


> On 29 Sep 2002 17:06:53 GMT, Christopher Browne <cbbrowne at acm.org> wrote:
> 
> >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..?)

Humans think in decimal.  To a human, 1.0/10.0 == 0.1, not
0.10000000000000001.  OK, so this *rounds* to 0.10 at two
decimal places, but what about:

>>> .70 * .05
0.034999999999999996

Rounded to two decimals, that's 0.03; but done in proper
decimal numbers, the answer should be 0.035, rounded to 0.04
using either "classic" or "banker's" decimal rounding.

If you are calculating sales tax, for instance, this is 
unacceptable.

(I borrowed this example from memory from a previous poster,
and if I could remember who it was I'd give credit...)

You ask how it is a different problem.  Simple.  A human,
training in decimal math in grade school, knows that 

    1/3 = 0.3333333...

and would *expect* it to round to 0.33 (still in two decimal
places).  The problem with *binary* floating point is the
"surprise factor."

So, Bengt, how do I do this right using only floats?  I can't.
I have to have decimal arithmetic to get the right answer.

Chris Gonnerman -- chris.gonnerman at newcenturycomputers.net
http://newcenturycomputers.net