Skip to main content

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

  • From: Sascha Freitag <dunschtig@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-currency] Re: Important use case regarding rounding
  • Date: Thu, 03 Jan 2013 22:28:08 +0100

Hi all,

here my 5 cents to the topic (this English phrase is funny and at the same time potentially misleading in this context ;-) ).

I also think we should keep in mind, that we like to have a value type approach. So the more complicate stuff (or even most of the calculations) should go to utility package/classes. Around rounding we already had some discussions. And I still think the basic calculations should be precise i.e. not apply some rounding. The rounding should be done at the end of the various calculations and will vary between the different use cases, as also already mentioned. So how to deal with the rounding has to be defined by the client code and we can decided how much convenience we will provide. Apart of the common book keeping roles, like defined in the different GAAP's, the roles might even change more or less over time. So it's questionable how much we really should implement in such a basic library. Maybe a better approach would be to have a kind of example, best practice library which shows this. And will also provide more flexibility to be adopted over time or for special use cases.

Regards Sascha
On 01.01.2013 23:26, Victor Grazi wrote:
It would be great if we could create an "invariant" _expression_. For example, "X+Y=Z". Pass this to the Divide and Conquer calculator, so that when calculating X, Y, and Z, if a rounding error causes a loss of accuracy, it would automatically adjust one of the variables making the invariant accurate.

If we had binding, that would be one way to do it. Barring that, we would need some facility for calculating the invariant, and for figuring out how to adjust it.

Regards
Victor


On Tue, Jan 1, 2013 at 4:20 PM, Werner Keil <werner.keil@...> wrote:
Similar to the earlier "internal" discussion, to a certain extent it may still make sense to keep those with a value type like Amount, but some more sophisticated calculations we might think of a different place, along the lines of FX Binding, or the module Stephen suggested somewhat inspired by JSR 310 where the expressions used are comparable.

Regards,
Werner


On Tue, Jan 1, 2013 at 10:16 PM, Victor Grazi <vgrazi@...> wrote:

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 <vgrazi@...>
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 <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 <atsticks@...> 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
Java Lead Engineer, JSR Spec Lead
Gärnischweg 10
CH - 8620 Wetzikon

Switzerland, Europe Zurich, GMT+1
Twitter:  @atsticks




-- 

Sascha Freitag v/o Dunschtig


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

Anatole Tresch 01/01/2013

<Possible follow-up(s)>

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

Anatole Tresch 01/01/2013

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

Werner Keil 01/01/2013

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

Victor Grazi 01/01/2013

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

Anatole Tresch 01/01/2013

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

Anatole Tresch 01/01/2013

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

Victor Grazi 01/01/2013

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

Werner Keil 01/01/2013

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

Victor Grazi 01/01/2013

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

Sascha Freitag 01/03/2013

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

KFSC 52 01/07/2013

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

KFSC 52 01/07/2013

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

Werner Keil 01/01/2013

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

Anatole Tresch 01/01/2013

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

Werner Keil 01/01/2013

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

Anatole Tresch 01/01/2013

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

Victor Grazi 01/01/2013

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

Werner Keil 01/01/2013

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

Anatole Tresch 01/02/2013

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

Anatole Tresch 01/02/2013
 
 
Close
loading
Please Confirm
Close