+- HP Forums (https://www.hpmuseum.org/forum)
+-- Forum: Not HP Calculators (/forum-7.html)
+--- Forum: Not remotely HP Calculators (/forum-9.html)
+--- Thread: Rounding approach (/thread-1088.html)
Rounding approach - Tugdual - 04-12-2014 07:29 PM
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?
RE: Rounding approach - Joe Horn - 04-13-2014 06:44 AM
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
RE: Rounding approach - Paul Dale - 04-13-2014 09:16 AM
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
RE: Rounding approach - Dieter - 04-13-2014 11:41 AM
(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 EURThe 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 EURSo if and how to round is not just a mathematical question.
Dieter