monetary applications [was: Python GUI app to impress the bos s?]

Paul Rubin phr-n2002b at
Fri Sep 20 06:30:21 EDT 2002

Alex Martelli <aleax at> writes:
> Say that you publish the erroneous information that each phone
> call is $0.70 plus $0.03 sales tax for a total of $0.73.  Sales
> tax is actually $0.04.  Now, a customer makes 100 calls.  Do
> you charge them $74 explaining that 100 times 73 cents is 74
> dollars?  Or do you charge $73 and eat the dollar loss yourself?
> And even then, your tax books won't balance without fiddling --
> even if the unbalance is against your interests, as in this case,
> it's _still_ illegal (at least around here)... double-entry tax
> book-keeping is supposed to balance to the last cent.

Now that I think about it, the way it's done around here is you're
supposed to look up the amount of tax in a table, not calculate it.  I
remember giving my local ice cream store a hard time when I was
little.  I used to go in for an ice cream and coke, and because of how
the tax table worked, it was one cent cheaper to buy them in two
separate transactions than in one transaction, so I did that.

At the end of the day, though, I'm sure they just took the amount that
the cash register said was collected pre-tax, multiplied by the tax
rate and sent that amount to the state.  If the amount actually
collected was slightly lower or higher, they paid the difference or
kept it themselves.

> But what you said were that you had a hard time imagining any
> commercially significant computation being off by a whole penny
> (which, I imagine, means a whole cent) by using IEEE double
> (binary floating point).  Surely this one example IS enough to
> jog your imagination?  

Yes, point taken.

More information about the Python-list mailing list