Java's Floating-Point (Im)Precision

You can clear many of your doubts regarding data types in Core Java through Merit Campus, visit: http://java.meritcampus.com..., http://java.meritcampus.com...

Not only data types, we also have each and every topic in Core Java with example for each. You can read lot of sessions and can write many practice tests in Merit Campus Java website. visit: http://java.meritcampus.com... to know more.

Eric,

Even if this is a Java specific blog, I think it should be mentioned that this behavior is due to the way IEEE 754 Floating Point Arithmetic standard works, and that it is not specific to Java. I do not like the statement that "...shortcuts are taken with float and double" (by Java). Even int and long have a finite number of bits and so cannot represent numbers larger than MAXINT or MAXLONG exactly. The difference is that with floating point numbers, the numbers that cannot be represented exactly are interspersed with those that can, so there is no fixed range within which they are always exact.

Thank you for that thorough explanation. I'll check out that paper. Thanks again.

Floating point does give exact answers given the right conditions.

E.g. if you supply a value with five decimal digits before conversion to decimal, you should convert to a maximum of five digits when converting back to decimal.

Double gives you 16 decimal digits of precision. So if you convert a decimal number with 16 digit or less to FP and back you get the exact result. But you need to round to the number of significant digits you expect since FP does not keep track of that for you.

Then you may lose precision during operations, For multiplication and division, a rule of thumb is that you lose at most one digit per operation. For addition and subtraction it is more complicated, but think of it as aligning around the decimal point. If the maximum number of digit before and after the decimal point, including the result, overall is larger than 16 digit, you lose precision, otherwise you don't.

In your example you need eight digits, well withing the precision of double, so the result when converted back to decimal with the significant number of digits, is in fact exact. The error in the original code is that it outputs the results with excess precision.

IEEE floating point is exact, as long as you don't overstep the precision, which means you need to estimate the total error in your calculations regardless of whether you are counting pennies or forecasting the weather.

For money this is problematic because most calculations fit fine within the precision of double, but just barely and many accountants expect that even amounts of a thousand trillions are computed to the penny, because that's how debit and credit are balanced.

As for "can't use for money", I think that statement is invalid. Excel is the most widely used tool for monetary calculations and it uses floating point. Sure people make huge mistakes in their spreadsheets, but that's not due to the use of floating point. Trading systems also use floating point heavily, so apparently it works quite well.

C/C++ programmers on many platforms can use long double which has 35 or so decimal digits which allows for quite a lot of calculations before any significant loss of precision occurs.

Of course the safe way is to use BigDecimal and only BigDecimal. You mix double and BigDecimal which bad and is likely to get you into trouble someday. I've seen worse though. BigDecimal has a constructor from String, so you could write this instead that has no floating point at all.

BigDecimal a = new BigDecimal("106838.81");
BigDecimal b = new BigDecimal("263970.96");
BigDecimal c = new BigDecimal("879.35");
BigDecimal d = new BigDecimal("366790.80");

BigDecimal total = BigDecimal.ZERO;
total = total.add( a );
total = total.add( b);
total = total.subtract( c );
total = total.subtract( d );

There is a paper called "What Every Computer Scientist Should Know About Floating Point" that explains all the details of when you can expect exact results from floating point.

I think it's not just that people don't know about BigDecimal (they probably pass it in JavaDoc many times), but that using BigDecimal means (1) your formulas become far more obtuse and hard to read, and (2) you can't use floating-point libraries and frameworks.

Leaving operator overloading out of Java was probably a good thing, but it makes it a bad language for finance. I'd say just use Scala, but then you'd have to spend two years learning Scala-- which is made harder because of... operator overloading.

Ha! You caught us tripping over our attempts to be clever in headline writing. In all fairness to Eric, that was my goof in editing the blog post. The correction has been made.

"Inprecise" is more imprecise than floating-point! :)

I am more mystified by the title. I was looking for the 'hook' as to why floating point math is 'in-precise' as opposed to 'imprecise'. I guess it was just a typo. Please be more careful when using terms that are either incorrect or imprecise, as they are more misleading in the context in which they are used.

It is ridiculous, as you state. This problem has been known for years and, esp. in Java, there are classes specifically created to solve this problem (that is, the BigDecimal that Eric discusses). This is where, I believe, the self-taught history of some programmers comes back to bite them: they don't know what they don't know.

I'm utterly depressed by the fact that twenty years after even I started working in banking I.T there still seem to be people who don't know that you can't use fp data types for financial calculations.
Please RTFM!
No matter what the language I'm sure it will say the same thing.

Thanks for the comment. I focused on Java since this is a Java specific blog, that's why I didn't say it was a flaw or bug. I didn't compare it to the behavior of other compilers and runtimes. Instead I focused on how to properly handle floating point math for financial calculations in Java using BigDecimal. I apologize if the title is misleading.

I'm mystified by this article. Not the observed behavior, but the explanation.

Here's the output from the same initial code using C++ (g++ on Linux Mint):

total: 3139.6200000000535510

That's the same result because it's calculated using IEEE 754 double precision floating point math - just as it is in Java. IEEE floating point math is well known to be unsuitable for financial calculations.

Please make it clear that this is in no way unique to Java, as even the title implies. It's simply a function of the normal behavior of IEEE floating point.