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

Chris Gonnerman chris.gonnerman at
Sun Sep 29 18:33:57 EDT 2002

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

> On 29 Sep 2002 17:06:53 GMT, Christopher Browne <cbbrowne at> 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

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 

(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

More information about the Python-list mailing list