Against PEP 240

[Tim Peters]

[Clark C . Evans, on financial calculations]
> Nod. You'd be amazed what kind of "tricks" people use
> to get the "right" answer.

Sorry, I'm too old for amazement <wink>.  The first time I bumped into this
phenomenon was when staring at a Fortran program for computing the
departmental budget.  It added 0.03 to the sum at the end.  What?!  Turned
out the manager who wrote this couldn't get the pennies to add up right, so
fudged it by hand to deliver the result he wanted.

> It works in the short term,

The program above worked great, until one of the inputs changed <wink>.

> but when the money is aggregated, taxes are calculated,
> and other numeric operations are carried out these
> "tiny" errors do accumulate.  One "minor" mistake in
> an accounting program and it brings into question the
> data integrety of evertyhing...

Understood.

> ...
> There are two general approaches: (a) do all of your
> calculations in "cents", or (b) use a BCD (binary
> coded decimal) library.
>
> Unfortunately the former isn't always an option...
> for two reasons, first people don't think in cents
> so it makes calculations quite a bit harder.  Second,
> for some currencies, numeric overflows are too common.
> Let's say the annual revenue of your company was
> 1.5 million dollars.  This is 342,540,983,606 Lire*100.
> With this number, you just had an overflow if you
> were using long (32) bit integers (4,294,967,296)

Well, Python has unbounded ints, so there's no overflow worry here.  The
FixedPoint class (mentioned frequently over the last week) wraps this trick
inside objects so you don't have to worry about the details.

> ...
> More and more people will be using Python for financial
> applications, from accounting to purchase order processing.
> Must we require each of these programmers, who perhaps
> have business degrees, to completely "grok" all of the
> subtleties of numeric analysis before they can write
> their first invoice?    Certainly we could write and
> publish a "BCD" library...  but I question how many
> junior programmers would know what BCD is... let alone
> taking active initiative to look for BCD.

Aahz is working on that approach.

> I'd rather have the default be some sort of BCD
> representation... where the programmer has to "work"
> to get the innaccuracy of a floating point representation.

It's not a cure-all, though.  For example, dividing by 7 can lead to
roundoff error in either approach.  Rational arithmetic cannot in that case.