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

[Alex Martelli]

Paul Rubin wrote:

> Alex Martelli <aleax at aleax.it> writes:
>> Using double binary floating-point, the result of 0.70 x 1.05 is
>> 0.73499999999999998667732370449812151491641998291015625; the result
>> should have been 0.735 (which would be rounded up to $0.74) but instead
>> the rounded result would be $0.73.
> 
> Interesting.
> 
>> Should your business get tax-audited, inspectors may take a dim view
>> of your shaving a cent off the sales tax due on each and every item
>> you sell to the public at $0.70 -- "I found it hard to imagine" how
>> rounding effects might affect the result (when the law specifies
>> rounding to the nearest cent and always rounding half cents up) may
>> not be an acceptable defense.
> 
> I don't think they ask or care whether you round up or down on
> individual 70 cent items.  They want to know the total value of the
> stuff you sold, and then the tax you pay is X percent of that total,
> for whatever your local value of X is.

And they have no problems with letting you claim to your customers
that their sales tax is M cents when it's really N cents, N != M ...?

Wow -- your jurisdiction must be far laxer than ones I've dealt with.

Around here, if you assert the tax is M, and thus have the customer
pay an extra M, it HAD BETTER be M -- doing otherwise could be
constituted as fraud (depending on circumstances).

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.

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?  Surely it would not be a _mistake_ for
the rest of the program to sum up net-of-tax amounts and taxes
separately, item by item, rather than summing up just the
net-of-tax amounts and then recomputing overall tax based on
that -- then, the overall amount of tax computed and paid to
the authorities might be off by 1 cent per phone call billed,
which can sum up to quite a pretty sum (smacks of the "salami
slice fraud" to me, in fact).


Alex