On , George White (2:440/4@fidonet) wrote: 
 RS> True, but fractional pence are hard to invoice and even harder to remit!
 > They can be required in invoice calculations though... The most common
 > occurance of fractional pence is in VAT ([Value Added Tax] which is more 
r
 > less equivalent to the US state Sales Tax) calculations. The current UK
 > rate is 17.5 per cent and the official rules are that when it is 
alculated
 > on a per line item basis either calculate to 0.5p (round to closest value)
 > or 0.1p (round down), with any fraction of a penny in the final total 
eing
 > ignored.
 > It's amazing how many commercial accounting packages do not follow these
 > rules, and work totally in pence, with the result that the difference in
 > VAT charged from the amount that should be charged if it was calculated
 > correctly being several pence as a result.
George...
  I included your whole message since someone else already called me on this 
and I think it bears repeating. The way I do this sort of thing is (using 
SNIPPETS)...
#include "snipmath.h"
        long sale;              /* expressed in pennies                 */
        double tax_rate;        /* expressed in decimal, e.g. 1% = .01  */
        sale = dbl2long((double)sale * (1.0 + tax_rate));
  Note that dbl2long() is a specialized version of the dblround() function 
which always rounds doubles properly to the closest integer - see 
DBLROUND.HOW, also in SNIPPETS, for more information on how it works.
  I find the use of dblround() and its related functions, such as dbl2long(), 
to be invaluable in a lot of calculations involving floating point data. The 
traditional macros (such as in SNIPPETS' ROUND.H) tend to be both inefficient 
and subject to error at the limits of integral precision. The dblround() 
function, OTOH, optimizes well and uses the information in float.h and 
limits.h to assure proper operation over the entire range of floating point 
values. 
--- QM v1.00
---------------