Best datatype for money

[WJ]

What is the best data type for doing money type calculations, such as
compound interest and such?

 

[Tony Morris]

What is the best data type for doing money type calculations, such as
compound interest and such?

An integral type.
http://www.xdweb.net/~dibblego/java/faq/answers.html#q41

--
Tony Morris
(BInfTech, Cert 3 I.T.)
Software Engineer
(2003 VTR1000F)
Sun Certified Programmer for the Java 2 Platform (1.4)
Sun Certified Developer for the Java 2 Platform

 

[Roedy Green]

What is the best data type for doing money type calculations, such as
compound interest and such?

see http://mindprod.com/jgloss/currency.html

Usually long suffices. Sometimes you need BigDecimal or a special
currency class.

 

[WJ]

So you both are saying I basically have to take money values, multiply them
by 100 to get the int, manipulate them, then divide back by 100 to get the
true dollars and cents?


Hmmm. . . .I've encountered the problem with floats. Seems like there
should be an integral with an optional precision to determine how many
decimal places to the right it can support.

Just a thought. . . .

 

[Kevin McMurtrie]

So you both are saying I basically have to take money values, multiply them
by 100 to get the int, manipulate them, then divide back by 100 to get the
true dollars and cents?


Hmmm. . . .I've encountered the problem with floats. Seems like there
should be an integral with an optional precision to determine how many
decimal places to the right it can support.

Just a thought. . . .

A float is a "floating point decimal." The decimal can float past 1
cent precision. There also isn't an exact conversion between binary and
decimal fractions so you always have rounding going on.

Use fixed point math. Currency is often a 32 bit signed integer
multiplied by 100.

 

[Thomas Weidenfeller]

So you both are saying I basically have to take money values, multiply them
by 100 to get the int, manipulate them, then divide back by 100 to get the
true dollars and cents?

Only at I/O. In your scenario: When a number comes in, it is multiplied
by 100. And that result is used all over the place in your software.
When you have to display/print/write some result out, you divide by 100.
This limits such conversions to a few well defined places in your software.

BTW: There is more to writing accounting software than just using
integers. You still have rounding errors when dividing (e.g. needed to
calculate VAT) which you must take care of. Often, the way you have to
take care about it is prescribed by accounting rules or laws.

Hmmm. . . .I've encountered the problem with floats. Seems like there
should be an integral with an optional precision to determine how many
decimal places to the right it can support.

I suggest you give the API documentation of the java.math package a very
good reading. Especially the classes called Big....

/Thomas

 

[Jacob]

So you both are saying I basically have to take money values, multiply them
by 100 to get the int, manipulate them, then divide back by 100 to get the
true dollars and cents?

Thinking in dollars and cents just confuses you.

Program as everything is cents. Store them as long
to handle big amounts. Only in GUI you may convert
amounts to/from something more human readable.

Do not use floats or doubles or Big*.

 

[Michael Borgwardt]

Thinking in dollars and cents just confuses you.

Program as everything is cents. Store them as long
to handle big amounts. Only in GUI you may convert
amounts to/from something more human readable.

Do not use floats or doubles or Big*.

Bad advice. BigDecimal hast at least one crucial advantage over using
long: it allows you to use a variety if rounding modes, and in
financial applications, the rounding mode is often a hard requirement
that may even be mandated by law.

 

[Jacob]

Bad advice. BigDecimal hast at least one crucial advantage over using
long: it allows you to use a variety if rounding modes, and in
financial applications, the rounding mode is often a hard requirement
that may even be mandated by law.

There will be many cases where you need to handle
fractional amounts. This must always be done with
care in order to prevent accumulated errors, and
rounding must be done correctly according to the
case at hand.

Still, when such operations has been made, always
put the result back into an integral type. That is
the only way to properly control where/when and
how rounding should be applied.

 

[Michael Borgwardt]

There will be many cases where you need to handle
fractional amounts. This must always be done with
care in order to prevent accumulated errors, and
rounding must be done correctly according to the
case at hand.

Still, when such operations has been made, always
put the result back into an integral type. That is
the only way to properly control where/when and
how rounding should be applied.

I don't think you understand what BigDecimal is if you
think it does not fit these requirements.

It was explicitly created for this case and allows
you to handle it with far fewer opportunities for
errors than mucking around with longs.

 

[David Segall]

What is the best data type for doing money type calculations, such as
compound interest and such?

Assuming you mean Java data type, you wish to minimise inaccurate
results rather than memory and you don't have, or wish to write, a
specialised money data type, I suggest you use doubles.

You will find many articles on the Internet that tell you that you can
precisely represent your pennies, cents, lira etc with a long integer
and so you must use one. They ignore the fact that you may not be able
to represent an interest rate or a currency conversion as precisely.
They also ignore the fact that you must convert the "real world"
decimal data to binary. Although your processor probably supports
decimal number calculations
(http://www.intel.com/design/Pentium4/manuals/25366515.pdf Chapter
4.7), Java does not.

Doubles cater for about 15 digits of accuracy so, assuming that your
bank account is around a million dollars and your interest rate is to
four decimal places you still have few digits to spare. There is at
least one hundred years experience behind minimising and understanding
the errors associated with floating point calculations. Be careful to
follow their advice and check your calculations accordingly but I
don't think adopting some other data type will afford better
protection from the inevitable errors in any numeric calculations.

 

[Michael Borgwardt]

Assuming you mean Java data type, you wish to minimise inaccurate
results rather than memory and you don't have, or wish to write, a
specialised money data type, I suggest you use doubles.

Extremely bad, counter-productive advice.

You will find many articles on the Internet that tell you that you can
precisely represent your pennies, cents, lira etc with a long integer
and so you must use one. They ignore the fact that you may not be able
to represent an interest rate or a currency conversion as precisely.

Wrong. You can be as precise as you want in exactly the same way,
just specify the number of fractional digits.

They also ignore the fact that you must convert the "real world"
decimal data to binary.

Wrong again. With integer types, this conversion is not problematic.

Although your processor probably supports
decimal number calculations
(http://www.intel.com/design/Pentium4/manuals/25366515.pdf Chapter
4.7), Java does not.

It does, in the form of BigDecimal. The only difference in the
*calculations* is the rounding anyway.

Doubles cater for about 15 digits of accuracy so, assuming that your
bank account is around a million dollars and your interest rate is to
four decimal places you still have few digits to spare. There is at
least one hundred years experience behind minimising and understanding
the errors associated with floating point calculations.

For *decimal* floating point calculations, the experience is much, much
longer. For binary ones, I'm pretty sure it's far less than 100 years.
That is, by the way, exactly the reason why financial applications usually
must adher to strictly specified *decimal* rounding rules.

And you CANNOT EVEN REPRESENT most decimal fractions exactly with a double!

 

[sks]

Thinking in dollars and cents just confuses you.

Program as everything is cents. Store them as long
to handle big amounts. Only in GUI you may convert
amounts to/from something more human readable.

What happens if you use a long and you need 1 tenth of a cent ?

 

[Michael Borgwardt]

What happens if you use a long and you need 1 tenth of a cent ?

Program like everything is tenths of cents. To be flexible, store then
number of fractional digits along with the value; that allows you to
mix cent and tents-of-cents values. Realize that BigDecimal already
implements this (and a lot more).

 

[Jim Cochrane]

I would think the best data type for this would be Money, or Currency, or
whatever the author of the library intended for that purpose has named the
class. I find it hard to believe that such a library does not exist.
If not, then you should probably be asking for advice on how to implement
such a class.

 

[Roedy Green]

What happens if you use a long and you need 1 tenth of a cent ?

you use 1000 as your scale factor instead of 100.

 

[Roedy Green]

And you CANNOT EVEN REPRESENT most decimal fractions exactly with a double!

Mike Cowlishaw, the creator of NetRexx argues passionately why
floating point hardware should be decimal based.

 

[Roedy Green]

I would think the best data type for this would be Money, or Currency, or
whatever the author of the library intended for that purpose has named the
class. I find it hard to believe that such a library does not exist.
If not, then you should probably be asking for advice on how to implement
such a class.

see http://mindprod.com/jgloss/currency.html

There have been such classes even since the very early days before
BigDecimal.

 

[eliza81]

Converting datatype in Java

Below are some examples of conversion from one data type to another in java.

double to String :
String str = Double.toString(i);

long to String :
String str = Long.toString(l);

float to String :
String str = Float.tString(f);

String to integer : str = "25";
int i = Integer.valueOf(str).intValue();
or
int i = Integer.parseInt(str);

String to double :
Double d = Double.valueOf(str).doubleValue();

String to long:
long l = Long.valueOf(str).longValue();
or
Long L = Long.parseLong(str);

String to float :
Float f = Float.valueOf(str).floatValue();

decimal to binary : int i = 42;
String bin = Integer.toBinaryString(i);

I hope this tip would be useful.Any suggestions are welcomed.