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

Alex Martelli aleax at
Mon Sep 23 09:54:30 CEST 2002

Robin Becker wrote:
> rules evolved before modern computers are mostly computable using
> fingers and counting. In particular almost all the calculations have to
> be with pre-specified precision and rounding rules.


> EG a bond pays fixed amounts of money at pre-specified intervals, no
> calculations are involved at all. Of course when I want to compute the
> yield or npv I need to do some arithmetic and FP is usually easiest and
> faster as well.

Wrong!  At least, if you have to follow legally mandated procedures
to post the yield, etc -- and at least in the EU there are quite a
few cases where you do.  For example, whenever you offer something
for sale to the public on any kind of instalment-payment plan, you
have to publish TWO different values for the interest rate that the
buyer ends up paying, exactly because there are subtly different
ways to compute such things and the legislators wanted to make VERY
certain that no seller tries to skew the computation and thereby
misinform buyers.  The two ways of computing interest use the
acronyms TAEG and TAEV in Italy -- I'm not sure what they refer to,
exactly: in practice, everybody looks at the higher one of the two
before entering into any financially substantial transaction (and/or
for a LARGE discrepancy between them, to take as an indication that
there is something fishy about the whole deal -- but fractions of a
percent of difference are quite typical, and the numbers are posted 
with specified accuracy of two decimal digits, e.g. "TAEG 10.23%").

I don't think there's any degree of freedom about how you can perform
these calculations -- the whole purpose of the legislation seems to
be exactly to ensure that sellers do NOT get any freedom to choose
what numbers to display in order to mislead buyers in any way.  In
particular, I think rounding procedures are strictly specified (but
I don't know the exact details).

> Anyhow it seems to me that BCD is pretty good only for additive type
> calculations. I can't see that BCD is any better than FP at representing
> 1/3 unless we go fully rational, but that's another story.

Yes, but I don't see legal specifications to use such fractions; rather,
I see specifications such as "18.75% of the sum" -- always a finite
number of decimal digits.  Your quoted paragraph at the start may
explain why -- things must in principle be computable with "fingers
and counting"... and, of course, "pre-specified precision and
rounding rules", which are never expressed in terms compatible with
binary floating-point hardware... always in terms of somebody
conducting a decimal computation with finite numbers of digits.


More information about the Python-list mailing list