Rounding approach
04-12-2014, 07:29 PM
Post: #1
 Tugdual Senior Member Posts: 738 Joined: Dec 2013
Rounding approach
My question is indirectly related to calculators since they have a finite number of decimal places. I am working on a software that does price calculations. Typically you have 2 decimal places and you may think it will be easy to implement. Unfortunately there are a number of things you can do, like rebates, exchange rates, quantity, price total, price each, sometime forward or backward calculations (i.e. start from net price or from discount). After a couple of divisions, multiplications and rounding at each step, chaos comes and it is hell to ensure that the price and all the details are consistent. Then you can expect sarcasms regarding your inability to program a simple sum...

Another common issue causing programs to crash being that when you expect zero you may find very small values so you would find yourself testing abs(value) < epsilon instead of value == 0.

I was wondering if there was a theory (or at least libraries or algorithms) to handle that properly?
04-13-2014, 06:44 AM
Post: #2
 Joe Horn Senior Member Posts: 1,468 Joined: Dec 2013
RE: Rounding approach
Rounding is a huge topic. You can't put it in a single algorithm, because there are so many different kinds of rounding. Here's a good article about it: http://en.wikipedia.org/wiki/Rounding

<0|ɸ|0>
-Joe-
04-13-2014, 09:16 AM
Post: #3
 Paul Dale Senior Member Posts: 1,481 Joined: Dec 2013
RE: Rounding approach
I've got half a dozen textbooks dedicated to rounding and how to deal with it. It is a very complex and rather subtle subject.

There are several packages which guarantee the rounding of the result. Typically, they are space and/or time intensive. I.e. not suitable for a limited resource calculator.

- Pauli
04-13-2014, 11:41 AM (This post was last modified: 04-13-2014 11:45 AM by Dieter.)
Post: #4
 Dieter Senior Member Posts: 2,398 Joined: Dec 2013
RE: Rounding approach
(04-12-2014 07:29 PM)Tugdual Wrote:  I was wondering if there was a theory (or at least libraries or algorithms) to handle that properly?

The main problem is not the limited number of digits, it's the general rounding to two decimal places. Consider a very simple case like calculating the VAT amount when the gross price is given and the tax rate is 19%. This means that plus or minus cent gross price means 0,86 cent net price difference. Which inadvertedly leads to 1-cent-differences:

Code:
gross price: 103,00 EUR ./. VAT 19%:  16,45 EUR   ' exact: 16,4454 = net price:  86,55 EUR   net price:  86,55 EUR  +  VAT 19%:  16,44 EUR   ' exact: 16,4445 gross price: 102,99 EUR

The exact VAT amount is 16,4454 EUR which mathematically rounds to 16,45. However, your local legislation may state that the result has to be rounded down to the next lower cent. In this case it works:

Code:
gross price: 103,00 EUR     VAT 19%:  16,44 EUR   ' exact: 16,4454   net price:  86,56 EUR   net price:  86,56 EUR     VAT 19%:  16,44 EUR   ' exact: 16,4464 gross price: 103,00 EUR

So if and how to round is not just a mathematical question.

Dieter
 « Next Oldest | Next Newest »

User(s) browsing this thread: 1 Guest(s)