Financial operation [Hibernate]

[Mark Thornton]

On the other hand, accounting usually does require exactness.

Actually it isn't always exact either, it is just that it requires a
particular form of inexactness where the rules have been specified
assuming base 10.

Mark Thornton

 

[Mark Thornton]

The problem is that some bean-counter somewhere will get upset if values
in the millions or billions don't balance to the exact penny.

I take Patricia's point about projections (usually done with
spreadsheets, so using real numbers whether you like it or not) and the
same applies to the APR, i.e. projections and APR are never directly
converted to monetary values.

I once calculated the distribution cost of industrial gases in bulk and
cylinder form for a company. I had to start by 'predicting' the cost
using their then current practice applied to the previous years data.
The resulting cost estimate was the best they had because their
accounting system did not separate costs attributable to gas
distribution from other costs. Other interesting features were that bulk
liquified gas tankers lose up to 10% of the product in transit to
evaporation. With all these factors in play, even float would have
provided sufficient precision let alone double.

Mark Thornton

 

[Patricia Shanahan]

Actually it isn't always exact either, it is just that it requires a
particular form of inexactness where the rules have been specified
assuming base 10.

This does suggest some rules of thumb:

1. If the calculation is expected to be truly exact, no rounding at all,
either do it in an integer type, or use BigDecimal with rounding mode
UNNECESSARY. BigDecimal may be better because it will throw an exception
if any calculation is rounded, where int or long would silently truncate.

2. If the calculation has specified base 10 rounding rules do it in
BigDecimal with the appropriate rounding mode. Do not even think about
double. Accounting for a loan as it is being repaid falls in this category.

3. If rounding is necessary but not specified, there is more flexibility
and double may be appropriate, especially if the calculation requires
functions such as logarithms. This category includes necessarily inexact
financial projections.

Patricia

 

[Lew]

Lew wrote On 11/26/07 09:26,:

Yes, and you can use byte[], too, or even boolean[],
and it would still be foolish. If you think not, would
you care to exhibit FP-free code to solve the proposed
problem? For extra credit, explain why your FP-free
solution is better than an FP-ful one.

I canceled that post of mine about 30 seconds after I posted it. Cancellation
is a chancy thing.

As for posting such code, GIYF.