Avoiding round-off error in calculating taxes

Should you decide to follow the (good) suggestion given by ozo, be sure to use __int64 rather than int, because otherwise an overflow may occur on bigger sums of money. If __int64 is not an option, at least use unsigned int (its numeric limit is pow(2,32) which is over 4 billion as opposed to around 2 billion for int; it means you can use unsigned to process sums up to 40 mln dollars).

ozo, the problem remains here:

448500 / 1000

the result should be a floating point number, otherwise (if you use int) its just 448


david_johns, add 0.005 and then just print the value to the last two digits ("%.2f" in the printf-statement does the trick)

    float val = 4.4849997f;
    printf( "original: %f  rounded: %.2f\n", val, val + 0.005f );

output:

    original: 4.485000  rounded: 4.49


ike

you lose more precision with fixed-point arithmetics like shown above. depending on the number of digits for a fixed point (lets take 2 here):

10 / 3 * 3 = 9.99

with floats you get 10 as outcome ..

to be clear, you cant avoid rounding errors, you can just minimize it and cut the unnecessary information ("%.2f") when you present the result to the user.

@ozo @gurudenis, of course in a given range you can reach the same precision with fixed-points, but its overkill here since you can do the same with types the compiler provides

I said to round 448500 / 1000 to 449000 / 1000
If you try to convert convert 4.485 to floating point depending on your implementation it may really be 4.8849999999999997868371792719699442386627197265625

>> I said to round 448500 / 1000 to 449000 / 1000

misunderstood, nevermind.;)

>> If you try to convert convert 4.485 to floating point depending on your implementation it may really be 4.8849999999999997868371792719699442386627197265625

thats not a problem, because you dont show it to the user ..

the thing with the fixed point is, you have to transform it from normal numbers (*1000) before calculations and back (/1000) after calculations. dont get me wrong, you can perfectly do it, but its overkill here

It can be a problem if you try to do calculations with it.
If the only place that you use floating point is as a parameter to printf("%.2f",float) then it need not be a problem.

>> It can be a problem if you try to do calculations with it.

can you show how the fpu can cause a problem in this calculation with input in the right range

  gross = round( net * taxrate );

The original question showed an example of
4.4849997 rounded to 4.48 instead of 4.485 rounded to 4.49

well i dont have a problem here with this example, can you run

float net = 69.0f;
float tax_rate = 0.065f;
float tax = net * tax_rate;
printf( "ori: %f  rounded: %.2f\n", tax, tax + 0.005f );

and send the output. dont trust the debugger in this case ..

+ 0.005f would cause an error if the true value was 4.484 which would need to be rounded to 4.48

>> + 0.005f would cause an error if the true value was 4.484 which would need to be rounded to 4.48

good catch, you're right. changing from floats to doubles with their higher precision and adjusting the rounding functions gives the desired outcome.
its important that the "net * tax_rate" is already calculated with doubles instead of floats.
so finally it works, not with floats but with doubles ;)

#include <cstdio>
#include <math.h>
 
double round_2nd( double val )
{
    return floor( val * 100.0 + 0.5 ) / 100.0;
}
 
int main()
{
    double net = 69.0;
    double tax_rate = 0.065;
    double tax = net * tax_rate;
    printf( "ori: %f  rounded: %.2f\n", tax, round_2nd( tax ) );
 
    return 0;
}

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:

With doubles, 0.065 might be stored as the more accurate value
0.065000000000000002220446049250313080847263336181640625
instead of
0.064999998
but it is still wrong.
and if you are legally required to to follow precise rounding rules when dealing with money, then you don't want to be dealing with FPU approximations

ok thats true. the question is if the fpu-approximation-error is high enough to give a wrong result. i could not see that yet.
you can ignore the error you were talking about, because the (wanted)rounding(error) itsself is between 0.0<=e<0.01 which is more than a billion times higher than the fpu-approximation-error in your above example. so the rounding itsself is more critical than the fpu here.
but i might be wrong, please can you show some examples.

>> please can you show some examples

i dont mean it polemic. im really interested in that matter. if you can find some please post it :)

The crux of tax calculation is the realisation of the following facts:

1. You cannot charge the customer a fraction of a penny/cent.

2. If you don't charge enough the tax-man will get you.

3. If you charge too much the customers will get you.

So ... from 1 ... forget floats/doubles etc. use integers capable of handling the largest amount possible.

And ... from 2 and 3 ... be sure you are as close as possible but if a choice is inevitable, round up. A run-in with the tax-man can cost you severely while a run-in with a customer may cost you a penny/cent.

Paul

hey paul, thanks for that :)
is your point:

1) the fpu would cause errors
or
2) dont use fpu, because you can do the same with int's
or
3) something else

because we focused on 1) so far.

If the rule is to round up when the true value is exactly in the middle, then a slightly too large value may let you err on the safe side (unless you do enough calculations to compound errors across a threshold )
But it can be tricky to predict which floats or doubles will be slightly to big and which will be slightly too small.
On my machine, 0.065 comes out slightly too big,
but 0.06 or 0.075 come out slightly too small.
So if your tax rate changes, or your code runs on a different machine, or your sale item is different, you may suddenly find yourself with a run-in with someone.
Simply increasing precision doesn't always help.  You might get closer to the true value but cross from one side of the threshold to the other.

Hi Ike,

Essentially, this kind of calculation should:

1. Use integers (int/long/_int64).
2. Round at the end, as near to print time as you can.
3. Round .5 up.

Paul

thanks ozo, i see your point. to you too paul :)

i found this money class:

http://www.di-mare.com/adolfo/p/money.htm

it is sort of combining what we were talking about. it uses a double as storage, but it scales all *incoming* values (assignment from doubles or floats) by a given factor (most common one is hundret for cents) and then it gets rid of the post decimal positions with the FIX()-member. so its like using an int, isnt it?
now im sort of confused what is the right way to do it, can you have a look it?
i could not find an example with simply an int-implementation.

at least this class worths it for this one, i never saw it before:

#define TENPOW(n)  1.0e##n

great trick :)

@david, sorry for hijacking this, but i guess youre interested too, right :)

thanks guys

Definitely!  Great discussion.  Thanks for all the ideas.  I'm still thinking through how I want to approach it.  The first thing I tried was switching the storage of the tax rate from a ratio (i.e. 0.065) to a percentage (i.e. 6.5).  This fixes the problem in this case.  I am trying to decide if it will generically fix the problem, or just for this case.

>> I am trying to decide if it will generically fix the problem, or just for this case.

if i understood ozo's post right, even if you solve one case at one cpu, you cannot predict how it will behave on another if you use floats or doubles.

im gonna double check my tax-papers next time ;)

In this case, binary floating point can represent a value like 6.5 exactly.
But it still can't represent 4.485 exactly, or prices like 69.01 exactly, so there may still be potential for trouble at the boundaries.  

Another approach is to use strings instead of floating-point. Of course, the mathematical operations would need to be (re)implemented  to allow for this change.

If you can arrange for all calculated values to end up in the middle of a range
instead of on the edge between different ranges, and you can put a bound on how much error your floating point numbers might have and how much errors can accumulate as you do repeated calculations, and can guarantee that that will always be less than the amount of error it would take to cross a boundary, then it can be safe to use floating point representations.