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

Chris Gonnerman chris.gonnerman at newcenturycomputers.net
Mon Sep 30 01:20:40 EDT 2002


----- Original Message -----
From: "Paul Rubin" <phr-n2002b at NOSPAMnightsong.com>


> No, I'm still not convinced.  Is business arithmetic well-
> defined enough that you can never do the same calculation two
> ways and get different results?
>
> Example: bunches are three for a dollar.  How much do you pay
> if you buy nine bananas?
>
>     Answer #1:
>       price_per_banana = 1.00 / 3
>       number_of_bananas = 9
>       total_price = number_of_bananas * price_per_banana
>       print total_price
>
>     Answer #2:
>       price_per_bunch = 1.00   # three bananas
>       number_of_bunches = 3
>       total_price = number_of_bunches * price_per_banana
>       print total_price
>
> With floating point and rounding on output, you get the same
> answer both ways.
>
> With decimal arithmetic, you get $2.97 the first way and
> $3.00 the second way.

Excellent example, wrong focus.  The business user (in this
case, the retail store owner/manager) would define which
method, and which results, are right.  The second mode is
the "canonical" way in the manual system, but lately I've
realized that many (most?) retail POS systems can do it "both"
ways, handling single items by a variation of method 1 which gives answers
consistent with method 2.

I'm glad I didn't have to write and debug that code.

> For "business arithmetic" to always give the same answer, it
> has to forbid at least one of those methods of doing the
> problem.

Except for the hack I described above, you're right.  *The
business user will define the rules* regarding when and to
how much you round.  You seem to think that I mean to round
to two places (as in US dollars and cents) when what I mean
is to handle numbers in (or as if in) base 10 all the time.

It isn't a question of when you round, so much as it is a
question of what *happens* when you round.  Proper floating
decimal numbers would also solve the problem; it's floating
binary that causes unexpected anomalies.

The banana problem might be solved in a given POS (point of
sale) system by using four or five decimals, then rounding to
two at the line-item level.  That would give correct results
for both methods above.

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





More information about the Python-list mailing list