## [JSR-currency] Re: Important use case regarding rounding

• From: Victor Grazi <vgrazi@...>
• To: jcurrency_mail@...
• Subject: [JSR-currency] Re: Important use case regarding rounding
• Date: Tue, 1 Jan 2013 16:16:13 -0500

That's exactly the point.
I think your divideAndSeparate is a good approach. But I believe the issue is not limited to division, we would need to think it through and provide similar divide and conquer methods to other arithmetic operations where appropriate

Regards
Victor

On Jan 1, 2013 3:17 PM, "Anatole Tresch" <atsticks@...> wrote:
Basically we have a represntation problem. When using decimals for numeric representation then it is NOT possible to accurately model a real number, some rounding is required. Basically this is the case for BigDecimal, as well for doubles. If you are rounding after a calculation step 100/3 to a precision of 2 you get a error of 0.003. When multiplied up again, these missing 0.003 will inevitably also multiplied accordingly, resulting in a loss of 0.003*3, which is 0.009. Since again rounding on a precision of 2 is applied, 0,01 are missing at the end. The root cause is that you loose significant information by reusing a rounded value for further calculations. One could say, then just omit rounding, but this is not possible since the numeric representation requires it. So... "Houston, we have a problem!".
My opinion is that it is conceptually wrong to use a rounded value for further calculations in that case. When using a precision of 0, for example the error produced is even worse.

I have written a small program, that shows the rounding differences for similar use cases, where I also print out the rounding differences. When the precision is increased the possible rounding error decreases in the same magnitude. So in our example, where the first division 100/3 results in a 0.003 error, when using a precision of 4 instead of 2, the error will be only 0.00003. Again summed up again by the following multiplication, the overall error will be 0.00009, which is exactly 100 times less than with precision 2. Similarly when a precision of, for example, 20 is applied, the error will be much smaller.

Sinse the required precision may greatly vary (e.g. when calculating an interest or option price it must be relatively precise, whereas as when summing up amount for total bank risk evaluation, much less is required) it is useful that the client can decide on the precision to be used. Nevertheless I think it is important that developers that re not aware of the numeric pitfalls here in almost every cases must be more or less safe, so I suggest to use not a very small precision to be used internally. Similaryl frameworks that make use of the new money classes can decide on their specific use cases how to handle that.

In your special use case I think this is not an arithemtic issue: in financial mathematics it is common, to book rounding differences on some sort of special rounding accounts to reestablish a correct balance. In your case this could be done similarly. Finally the rounding differences can be printed out separatly in your balance, or as you propose summed up with one of the positions. Both variants may be correct, but seem to me more determined by the booking standards than the Amount's core arithmetics.

Nevertheless we can try to model an additional operation that would be able to cover that variant:

public Amount[] divideAndSeparate(Amount totalAmount, Number divisor, boolean addDifferenceToLastValue);

But I do not see such an operation on a

Also the show case clearly shows

2013/1/1 Victor Grazi
Guys, my point is the following...
Suppose you are modeling a balance sheet, and you have 2/3 in liabilities, 1/3 in assets and 1/3 in retained earnings, on a nominal base of 100. So the model produces 66.67 for liabilities, 33.33 for assets, and 33.33 for retained earnings.

Now the balance sheet is off by a penny: liabilities = assets + retained earnings... 66.67!= 33.33+33.33
Is there anything we can do to help with that calculation? The internal precision proposed by Anatole I don't think would do the job.

Thanks, Victor

On Tuesday, January 1, 2013, Werner Keil wrote:

Currently it isn't.
If CLDC plans to add it, then it would make sense. Instead of wrapping BigDecimal or similar it is a replacement, similar to what JavaFX Binding does. As there are basic NumberBindings in FX, that might further appeal.

Beside trying to avoid BigDecimal for getMinor or Major (in most cases these would be integer values anyway, so long seems sufficient, even for Nanos, which BitCoin knows btw;-) any method that says "Amount" in Amount seems redundant. Let's either drop that or use a different term like Part or Value.

Cheers,
Werner

Am 01.01.2013 11:40 schrieb "Anatole Tresch" <atsticks@...>:
I think this is a good point. Basically we have to check where we best should integrate with other parts of the SE environment. One thing that comes in my mind is
supporting Formattable.
Basically also we should discuss, if we want to model Amount by an interface (as it is now) or by by subclassing the abstract java.lang.Number (I assume Number is also part of ME, if not then I dot see this as an option).

2012/12/31 Werner Keil
Anatole/all,

Thanks a lot for the update. Great using Git forks for this
JScience the proposed RI for JSR 275 at the time (and now at least partially implementing Unit-API) had a very similar concept and an Amount type.
Except for the BigDecimal import and reference in the interface (not sure, if it's used or not) it looks good.

Somewhere along the lines of JavaFX Binding:

Given, JavaFX at least on the SE side is on its way to become an integral part of Java, adding something like a MonetaryBinding could even be part of an RI or at least optional extension to the API. Looks like a good idea.

Werner

On Mon, Dec 31, 2012 at 11:35 PM, Anatole Tresch wrote:

Hi Werner /all

Thanks a lot for the update. I think we may consider one or the other JIRA tickets for this. Your java.net account should be in the position to raise one already, please let me know, if there is any problem with JIRA.
I will let you know, if I have some issues with JIRA (I do not expect them, either). I thought it would be better to have a discussion here first, and after we have successfully agreed on the key points to switch over on JIRA. Perhaps this was different as of today, so let me know ;-)

Regarding A.6 and B.5 which classes or interfaces do you propose to hold these methods? Some existing in the draft repository or new elements?
Why is the type of internal() simply Object and not a generic value?
Basically the root cause was that I had an interface in mind, where all internals are completely hidden from the clients, including the internal representation. The benefit is that such an interface, e.g. called Amount (see https://github.com/atsticks/javamoney/blob/master/core/src/main/java/javax/money/Amount.java) could enable code to be portable between SE and ME. Whereas when including the type of internal representation into the interface, e.g. as currently modelled in Monetary<T> then a dependency on T is created. When using the Monetary<T>, of course, T internal() would be much more accurate.
On the other side using Monetary<T> would even allow us to mix different representations in one VM but supporting type safety on compile level.
Arithmetics should be possible in both variants, as it is possible to evaluate the concrete internal representation during runtime. If the internal type representation do not match, a corresponding valueOf

--
Anatole Tresch