Skip to main content
This revision made January 08, 2013 19:58, by Anatole


JSR 354 - Aspects regarding Precision


Basically it is required to support very large numbers and a very large number of decimal places. There is quite some debate on how this can be realized efficiently. Candidates identified are

  • BigDecimal
  • single long
  • two longs (pounds & fraction)
  • new Decimal class (probably wrapping two longs)
  • double should be ruled out as inaccurate
  • Number should be ruled out as being abstract and non-precise

It was decided on using a Decimal class, that will encapsulate 2 longs - one long for the integer part and the other for the fractional part. Arithmetic needs to take this into account. But also it was clearly identified that different use cases and different environments have completely different requirements for representation.

Additionally different precision types were identified:

  • internal precision defines the precision used for performing arithmetical operations. By default a MonetaryAmount will always represented/rounded to this internal precision internally. This allows to separate concrete rounding requirements from the types numeric representation.
  • external precision is the precision applied, when a MonetaryAmount is externalized, e.g. by calling one of the int toInteger(), double toDoubple(), float toFloat() etc. methods, or by calling T asType(Class). Hereby the precision basically should be the same as the internal precision, but the representation of the externalized value may require to reduce the precision. In case of the toInteger() method this is quite obvious.
  • formatting precision this is the precision (or rounding) applied, when a monetary amount should be formatted for print out or display.

All these must be clearly separated, especially external and formatting precision are not part of the monetary amount's value type. Nevertheless the internal precision also must be serialized somehow, since different VMs may operate with different internal precisions. Therefore it is important that the precisoin information is also available on the target VM, so different precisions can be managed..

Difference compared to previous revision
=
JSR 354 - Aspects regarding Precision


Basically it is required to support very large numbers and a very large number of decimal places. There is quite some debate on how this can be realized efficiently. Candidates identified are ** BigDecimal ** single long ** two longs (pounds & fraction) ** new Decimal class (probably wrapping two longs) * double should be ruled out as inaccurate * Number should be ruled out as being abstract and non-precise We=
JSR 354 - Aspects regarding Precision


Basically it is required to support very large numbers and a very large number of decimal places. There is quite some debate on how this can be realized efficiently. Candidates identified are * BigDecimal * single long ... * two longs (pounds & fraction) * new Decimal class (probably wrapping two longs) * double should be ruled out as inaccurate * Number should be ruled out as being abstract and non-preciseIt hwaves decided on using a Decimal class, that will encapsulate 2 longs - one long for the integer part and the other for the fractional part. Arithmetic needs to take this into account. But also it was clearly identified that different use cases and different environments have completely different requirements for representation. Additionally different precision types were identified: * '''internal precision''' defines the precision used for performing arithmetical operations. By default a MonetaryAmount will always represented/rounded to this internal precision internally. This allows to separate concrete rounding requirements from the types numeric representation. * '''external precision''' is the precision applied, when a MonetaryAmount is externalized, e.g. by calling one of the int toInteger(), double toDoubple(), float toFloat() etc. methods, or by calling T asType(Class). Hereby the precision basically should be the same as the internal precision, but the representation of the externalized value may require to reduce the precision. In case of the toInteger() method this is quite obvious. * '''formatting precision''' this is the precision (or rounding) applied, when a monetary amount should be formatted for print out or display. All these must be clearly separated, especially external and formatting precision are not part of the monetary amount's value type. Nevertheless the '''internal precision''' also must be serialized somehow, since different VMs may operate with different internal precisions. Therefore it is important that the precisoin information is also available on the target VM, so different precisions can be managed..
 
 
Close
loading
Please Confirm
Close