Key: 
JAVAMONEY18

Type: 
New Feature

Status: 
Resolved

Resolution: 
Fixed

Priority: 
Critical

Assignee: 
atsticks

Reporter: 
atsticks

Votes: 
0

Watchers: 
0

If you were logged in you would be able to see more operations.



Several aspects of arithmetic precision 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.
 When MonetaryAmount with different precision are used for a caclulation:
 then the higher of both precisions is used for the result. This is also the case if the system's internal precision is less.
 If the higher of both precisions is less than the internal precision, the result has the internal precision.
 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> T asType(Class<T>). 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.
So the following points must be considered:
 internal precition must be defined (by default)
 internal precision must be accessible
 the default precision
 the effective precision on an instance
 precision must be adaptable based on the use case
 precision must be serialized
 mechanisms must be defined and implemented that ensure correct precision handling.

Description

Several aspects of arithmetic precision 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.
 When MonetaryAmount with different precision are used for a caclulation:
 then the higher of both precisions is used for the result. This is also the case if the system's internal precision is less.
 If the higher of both precisions is less than the internal precision, the result has the internal precision.
 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> T asType(Class<T>). 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.
So the following points must be considered:
 internal precition must be defined (by default)
 internal precision must be accessible
 the default precision
 the effective precision on an instance
 precision must be adaptable based on the use case
 precision must be serialized
 mechanisms must be defined and implemented that ensure correct precision handling.

Show » 
Sort Order:
made changes  16/Feb/13 04:00 PM
Field 
Original Value 
New Value 
Component/s

Standalone: exchange rates and currency conversion
[ 14821
]


Component/s

Spec: Specification
[ 14828
]


made changes  16/Feb/13 04:10 PM
Fix Version/s


1.0b01
[ 16318
]

made changes  26/Apr/13 06:08 PM
Fix Version/s

0.4EDR1
[ 16318
]


Affects Version/s


0.4EDR1
[ 16318
]

made changes  30/Aug/13 06:26 AM
Status

Open
[ 1
]

Resolved
[ 5
]

Assignee


atsticks
[ atsticks
]

Fix Version/s


0.5
[ 16430
]

Resolution


Fixed
[ 1
]


Two important use cases for precision are performing calculations (especially division) and pricing, i.e. ticks. There's a list of some common ones here: http://en.wikipedia.org/wiki/Commodity_tick^{}.
Exchange rates are a specialised case of pricing, and we might also need to consider whether that has any impact on the user view of an exchange rate (thats for another issue I guess).