[moneydance] Rounding in Java

[Edward Reid]

At 12:16 05/07/06 -0700, Randolph Fritz wrote:
>In the latest release of the API, 1.5, Java supports arbitrary precision
>decimal arithmetic. See
><http://java.sun.com/j2se/1.5.0/docs/api/java/math/BigDecimal.html> for
>details. That said, it's probably too early to use this in Moneydance,
>even if Sean wanted it; it would be a big change and everyone would have
>to upgrade Java.

There's no reason for MD to consider using this.

As I read the document, BigDecimal has two modes: integer and floating point.

Floating point is ALWAYS inappropriate for handling financial accounts. We 
don't care about relative precision. We must always keep every penny, or 
yen, or whatever the smallest unit is in the currency in use. So we must 
use integers.

Yes, if a long integer was not large enough for amounts of money, then 
BigDecimal would be attractive. But a long integer has 63 bits, which is 
about 21 digits. The biggest financial applications I've seen use 17 or 18 
digits. And that's for the total outstanding balance of all accounts at a 
large credit card company, with an ample margin allowed for growth.

If we really had to handle numbers which could potentially be more than 20 
digits, then BigDecimal might be attractive -- but still overkill, as a 
package which did arithmetic on 128-bit integers would be fairly easy and 
much faster. Only if we really could not place a limit on the number of 
digits would BigDecimal (in exact integer mode) become atractive.

>Hey, Java has finally caught up with COBOL!

Well, even COBOL does not have unlimited precision. The standards don't say 
what the maximum number of digits is, but there is always a limit. COBOL 
compilers usually generate inline code for arithmetic, not calls to routines.

What COBOL offers -- for example, in a PIC 9(12).99 -- is really only the 
scale factor and truncation at a power of ten.

Edward
Art works by Melynda Reid: http://paleo.org