1 2 Previous Next 15 Replies Latest reply on Jul 17, 2007 3:42 PM by 794069

# Floating points

I was reading a book about java and they pointed to some mathematical errors (minor ones) that might become huge working in a money business.

Why does this errors happen? The book doesnt explain me so well :s
``````float x = 0.1f;
NumberFormat nf = NumberFormat.getNumberInstance();
nf.setMinimumFractionDigits(10);
System.out.println(nf.format(x));``````
This code here has the following output in the console:

0,1000000015

Also, why do we always have to put that "f" in the initialization of the float variable? In double variables your not forced to to that, why? :s
• ###### 1. Re: Floating points
http://docs.sun.com/source/806-3568/ncg_goldberg.html

The f is to denote it is a float and not a double. Same way as you place an L for longs.
• ###### 2. Re: Floating points
wow this is..complicated..looks like my computer architecture class :s
Thanks :)
• ###### 3. Re: Floating points
The bottom line is, don't use floating point (float or double) for money. Use BigDecimal.
• ###### 4. Re: Floating points
or use int or long and divide by 100 when you need to display.

ie \$4.36 becomes 436
• ###### 5. Re: Floating points
use int only if you know you are dealing in less than a billion bucks ...
• ###### 6. Re: Floating points
ok thanks :)
• ###### 7. Re: Floating points
or use int or long and divide by 100 when you need to
display.

ie \$4.36 becomes 436
What if your currency doesn't use cents ;) and how would you handle currencies that us a different minimum to 1cent, eg 5cent (CHF)

Might be best to use doubles for calculations, and use a currency formatter when you want to display them.
• ###### 8. Re: Floating points
Might be best to use doubles for calculations
No, no, no, no, no. See reply #3.
• ###### 9. Re: Floating points
Might be best to use doubles for calculations
No, no, no, no, no. See reply #3.
Reply #3 is your assertion, with no evidence to back it up.
• ###### 10. Re: Floating points
FP is unsuitable for use on currency quantities by virtue of not having any of the desired behaviour of a fixed-point decimal-based number system, which is what currencies are expressed in, and they are generally implemented using round-to-even.

Reply #3 is the correct answer. The paper that is cited in this thread is the only reference or evidence required. If you knew anything at all about it you would know that without requiring 'evidence' at this late date. If you want to argue further about it please take it up with the designers of RPG, Cobol, SQL, the IBM 360, packed-decimal, the Intel x86 family, ...
• ###### 11. Re: Floating points
FP is unsuitable for use on currency quantities by
virtue of not having any of the desired behaviour of
a fixed-point decimal-based number system, which is
what currencies are expressed in, and they are
generally implemented using round-to-even.
No currency I know of uses round half even, they use round half up.

>
cited in this thread is the only reference or
evidence required.
Yes it proves that FP isn't the best system if you require accuracy to more than 16 significant figures.
If you knew anything at all about
it you would know that without requiring 'evidence'
at this late date.
There are always trade offs, and for normal currency transactions, in amounts that are used in the currencies I use on a day to day basis, double precision is more than sufficient.
If you want to argue further about
it please take it up with the designers of RPG,
Cobol, SQL, the IBM 360, packed-decimal, the Intel
x86 family, ...
If I need more accuracy then I wouldn't be using Java.
• ###### 12. Re: Floating points
No currency I know of uses round half even, they use
round half up.
If you have to pay, the amount to pay is rounded up.
If you get the amount, it is rounded down...
Yes it proves that FP isn't the best system if you
require accuracy to more than 16 significant
figures.
Or any accuracy, the exact accuracy depending on the system you're working on.
There are always trade offs, and for normal currency
transactions, in amounts that are used in the
currencies I use on a day to day basis, double
precision is more than sufficient.
Not really. Rounding errors tend to accumulate.
While in each individual calculation it may be too small to notice, when using those results to perform other calculations over and over again it gets constantly worse.
Even with a few iterations you can get significant differences (and remember that a difference of a cent on a million Euro can be significant!).
• ###### 13. Re: Floating points
Not really. Rounding errors tend to accumulate.
While in each individual calculation it may be too
small to notice, when using those results to perform
other calculations over and over again it gets
constantly worse.
Even with a few iterations you can get significant
differences (and remember that a difference of a cent
on a million Euro can be significant!).
While I would have been banging the BigDecimal for all currency calculations a while back, in my experience in real life systems those kinds of calculations don't take place... Even our most complicated system to date (where we did us BigDecimal btw), simply did some additions, and rate conversion calculations. For these cases the inconvenience, and performance hit of using BigDecimal wasn't justified. Also, since most developers hadn't used BigDecimal before, we had to spend far too much time ensuring that they used the String constructor (so as to actually get the benefit from BigDecimal).

If I had the choice to do it over, I would have gone with doubles, and used a specialised currency formatter for display purposes (and possibly persistance as well) -- Although we probably would have had to spend just as long showing the self same developers how to use the formatter, and trying to ensure they weren't ignoring it (*sigh*)
• ###### 14. Re: Floating points
Although we probably would
have had to spend just as long showing the self same
developers how to use the formatter, and trying to
ensure they weren't ignoring it (*sigh*)
And to use an epsilon when comparing for equality. :-)
1 2 Previous Next