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

Christopher Browne cbbrowne at
Sun Sep 29 13:06:53 EDT 2002

Quoth "Steve Holden" <sholden at>:
> <sismex01 at> 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.

The problem with FP is that FP involves the use of binary
approximations, which commonly cannot exactly represent decimal

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.

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!"

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.
(concatenate 'string "aa454" "")
Rules of the Evil Overlord #195. "I will not use hostages as bait in a
trap.  Unless  you're going  to use them  for negotiation or  as human
shields, there's no point in taking them."

More information about the Python-list mailing list