Boost :

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-09 18:04:45

Ed Brey wrote:

>
> - To avoid the currencies-not-adding embarrassment, the calculation
> should return a fixed-point number, properly rounded off, even if this
> causes the total to not be equal to fixed<2>(1.23 * (1 + rate1 +
> rate2)). (Another approach is to figure out the final total by adding
> the rates first, and then work backwards, fudging the taxes to make it
> all add up. I don't know whether this is common practice in the
> business world, but in any case it seems like it would have to be hand
> crafted beyond what the "fixed" class would provide.)

In business and law, there are usually some (often not
well specified) rules as to HOW to do calculations.

For example, to calculate tax, if one does it
item by item

amt tax taxed amt
------ --- ---------
\$12.00 \$1.20 \$13.20
\$00.12 \$0.01 \$00.13
------ ----- ------
TOTALS: \$12.12 \$1.21 \$13.33

It may be that the 'tax' on the 'total' is not actually 10%,
even rounded. Too bad. The tax is calculated PER ITEM here,
and everything else is just addition, which is always exact.
The total amt, plus the total tax, always equals the total
taxed amt.

If you calculate tax on the total, then you probably
shouldn't show the 'tax' and 'taxed amt' columns.

My point is that the 'embarrasment' is usually wrong
design by the programmer, who isn't thinking
like an accountant (but should be). Wrong
designs can't be fixed by nice properties of
library routines!

```--
John (Max) Skaller, mailto:skaller_at_[hidden]
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net