Skip to main content

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

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

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


[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
 
 
Close
loading
Please Confirm
Close