Post Reply 
Rounding approach
04-12-2014, 07:29 PM
Post: #1
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?
Find all posts by this user
Quote this message in a reply
04-13-2014, 06:44 AM
Post: #2
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-
Visit this user's website Find all posts by this user
Quote this message in a reply
04-13-2014, 09:16 AM
Post: #3
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
Find all posts by this user
Quote this message in a reply
04-13-2014, 11:41 AM (This post was last modified: 04-13-2014 11:45 AM by Dieter.)
Post: #4
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
Find all posts by this user
Quote this message in a reply
Post Reply 




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