Java:Why should we use BigDecimal instead of Double in the real world?

It's called loss of precision and is very noticeable when working with either very big numbers or very small numbers. The binary representation of decimal numbers with a radix is in many cases an approximation and not an absolute value. To understand why you need to read up on floating number representation in binary. Here is a link: http://en.wikipedia.org/wiki/IEEE_754-2008. Here is a quick demonstration:
in bc (An arbitrary precision calculator language) with precision=10:

(1/3+1/12+1/8+1/15) = 0.6083333332
(1/3+1/12+1/8) = 0.541666666666666
(1/3+1/12) = 0.416666666666666

Java double:
0.6083333333333333
0.5416666666666666
0.41666666666666663

Java float:

0.60833335
0.5416667
0.4166667

If you are a bank and are responsible for thousands of transactions every day, even though they are not to and from one and same account (or maybe they are) you have to have reliable numbers. Binary floats are not reliable - not unless you understand how they work and their limitations.

I think this describes solution to your problem: Java Traps: Big Decimal and the problem with double here

From the original blog which appears to be down now.

Java Traps: double

Many traps lay before the apprentice programmer as he walks the path of software development. This article illustrates, through a series of practical examples, the main traps of using Java's simple types double and float. Note, however, that to fully embrace precision in numerical calculations you a text book (or two) on the topic is required. Consequently, we can only scratch the surface of the topic. That being said, the knowledge conveyed here, should give you the fundamental knowledge required to spot or identify bugs in your code. It is knowledge I think any professional software developer should be aware of.

1. Decimal numbers are approximations

   While all natural numbers between 0 - 255 can be precisely described using 8 bit, describing all real numbers between 0.0 - 255.0 requires an infinitely number of bits. Firstly, there exists infinitely many numbers to describe in that range (even in the range 0.0 - 0.1), and secondly, certain irrational numbers cannot be described numerically at all. For example e and π. In other words, the numbers 2 and 0.2 are vastly differently represented in the computer.

   Integers are represented by bits representing values 2n where n is the position of the bit. Thus the value 6 is represented as 23 * 0 + 22 * 1 + 21 * 1 + 20 * 0 corresponding to the bit sequence 0110. Decimals, on the other hand, are described by bits representing 2-n, that is the fractions 1/2, 1/4, 1/8,... The number 0.75 corresponds to 2-1 * 1 + 2-2 * 1 + 2-3 * 0 + 2-4 * 0 yielding the bits sequence 1100 (1/2 + 1/4).

   Equipped with this knowledge, we can formulate the following rule of thumb: Any decimal number is represented by an approximated value.

   Let us investigate the practical consequences of this by performing a series of trivial multiplications.

   System.out.println( 0.2 + 0.2 + 0.2 + 0.2 + 0.2 );
   1.0
   

   1.0 is printed. While this is indeed correct, it may give us a false sense of security. Coincidentally, 0.2 is one of the few values Java is able to represent correctly. Let's challenge Java again with another trivial arithmetical problem, adding the number 0.1 ten times.

   System.out.println( 0.1f + 0.1f + 0.1f + 0.1f + 0.1f + 0.1f + 0.1f + 0.1f + 0.1f + 0.1f );
   System.out.println( 0.1d + 0.1d + 0.1d + 0.1d + 0.1d + 0.1d + 0.1d + 0.1d + 0.1d + 0.1d );
   
   1.0000001
   0.9999999999999999
   

   According to slides from Joseph D. Darcy's blog the sums of the two calculations are 0.100000001490116119384765625 and 0.1000000000000000055511151231... respectively. These results are correct for a limited set of digits. float's have a precision of 8 leading digits, while double has 17 leading digits precision. Now, if the conceptual mismatch between the expected result 1.0 and the results printed on the screens were not enough to get your alarm bells going, then notice how the numbers from mr. Darcy's slides does not seem to correspond to the printed numbers! That's another trap. More on this further down.

   Having been made aware of mis-calculations in seemingly the simples possible scenarios, it is reasonable to contemplate on just how quickly the impression may kick in. Let us simplify the problem to adding only three numbers.

   System.out.println( 0.3 == 0.1d + 0.1d + 0.1d );
   false
   

   Shockingly, the imprecision already kicks in at three additions!

2. Doubles overflow

   As with any other simple type in Java, a double is represented by a finite set of bits. Consequently, adding a value or multiplying a double can yield surprising results. Admitedly, numbers have to be pretty big in order to overflow, but it happens. Let's try multiplying and then dividing a big number. Mathematical intuition says that the result is the original number. In Java we may get a different result.

   double big = 1.0e307 * 2000 / 2000;
   System.out.println( big == 1.0e307 );
   false
   

   The problem here is that big is first multiplied, overflowing, and then the overflowed number is divided. Worse, no exception or other kinds of warnings are raised to the programmer. Basically, this renders the expression x * y completely unreliable as no indication or guarantee is made in the general case for all double values represented by x, y.

3. Large and small are not friends!

   Laurel and Hardy were often disagreeing about a lot of things. Similarly in computing, large and small are not friends. A consequence of using a fixed number of bits to represent numbers is that operating on really large and really small numbers in the same calculations will not work as expected. Let's try adding something small to something large.

   System.out.println( 1234.0d + 1.0e-13d == 1234.0d );
   true
   

   The addition has no effect! This contradicts any (sane) mathematical intuition of addition, which says that given two numbers positive numbers d and f, then d + f > d.

4. Decimal numbers cannot be directly compared

   What we have learned so far, is that we must throw away all intuition we have gained in math class and programming with integers. Use decimal numbers cautiously. For example, the statement for(double d = 0.1; d != 0.3; d += 0.1) is in effect a disguised never ending loop! The mistake is to compare decimal numbers directly with each other. You should adhere to the following guide lines.

   Avoid equality tests between two decimal numbers. Refrain from if(a == b) {..}, use if(Math.abs(a-b) < tolerance) {..} where tolerance could be a constant defined as e.g. public static final double tolerance = 0.01 Consider as an alternative to use the operators <, > as they may more naturally describe what you want to express. For example, I prefer the form for(double d = 0; d <= 10.0; d+= 0.1) over the more clumsy for(double d = 0; Math.abs(10.0-d) < tolerance; d+= 0.1) Both forms have their merits depending on the situation though: When unit testing, I prefer to express that assertEquals(2.5, d, tolerance) over saying assertTrue(d > 2.5) not only does the first form read better, it is often the check you want to be doing (i.e. that d is not too large).

5. WYSINWYG - What You See Is Not What You Get

   WYSIWYG is an expression typically used in graphical user interface applications. It means, "What You See Is What You Get", and is used in computing to describe a system in which content displayed during editing appears very similar to the final output, which might be a printed document, a web page, etc. The phrase was originally a popular catch phrase originated by Flip Wilson's drag persona "Geraldine", who would often say "What you see is what you get" to excuse her quirky behavior (from wikipedia).

   Another serious trap programmers often fall into, is thinking that decimal numbers are WYSIWYG. It is imperative to realize, that when printing or writing a decimal number, it is not the approximated value that gets printed/written. Phrased differently, Java is doing a lot of approximations behind the scenes, and persistently tries to shield you from ever knowing it. There is just one problem. You need to know about these approximations, otherwise you may face all sorts of mysterious bugs in your code.

   With a bit of ingenuity, however, we can investigate what really goes on behind the scene. By now we know that the number 0.1 is represented with some approximation.

   System.out.println( 0.1d );
   0.1
   

   We know 0.1 is not 0.1, yet 0.1 is printed on the screen. Conclusion: Java is WYSINWYG!

   For the sake of variety, let's pick another innocent looking number, say 2.3. Like 0.1, 2.3 is an approximated value. Unsurprisingly when printing the number Java hides the approximation.

   System.out.println( 2.3d );
   2.3
   

   To investigate what the internal approximated value of 2.3 may be, we can compare the number to other numbers in a close range.

   double d1 = 2.2999999999999996d;
   double d2 = 2.2999999999999997d;
   System.out.println( d1 + " " + (2.3d == d1) );
   System.out.println( d2 + " " + (2.3d == d2) );
   2.2999999999999994 false
   2.3 true
   

   So 2.2999999999999997 is just as much 2.3 as the value 2.3! Also notice that due to the approximation, the pivoting point is at ..99997 and not ..99995 where you ordinarily round round up in math. Another way to get to grips with the approximated value is to call upon the services of BigDecimal.

   System.out.println( new BigDecimal(2.3d) );
   2.29999999999999982236431605997495353221893310546875
   

   Now, don't rest on your laurels thinking you can just jump ship and only use BigDecimal. BigDecimal has its own collection of traps documented here.

   Nothing is easy, and rarely anything comes for free. And "naturally", floats and doubles yield different results when printed/written.

   System.out.println( Float.toString(0.1f) );
   System.out.println( Double.toString(0.1f) );
   System.out.println( Double.toString(0.1d) );
   0.1
   0.10000000149011612
   0.1
   

   According to the slides from Joseph D. Darcy's blog a float approximation has 24 significant bits while a double approximation has 53 significant bits. The morale is that In order to preserve values, you must read and write decimal numbers in the same format.

6. Division by 0

   Many developers know from experience that dividing a number by zero yields abrupt termination of their applications. A similar behaviour is found is Java when operating on int's, but quite surprisingly, not when operating on double's. Any number, with the exception of zero, divided by zero yields respectively ∞ or -∞. Dividing zero with zero results in the special NaN, the Not a Number value.

   System.out.println(22.0 / 0.0);
   System.out.println(-13.0 / 0.0);
   System.out.println(0.0 / 0.0);
   Infinity
   -Infinity
   NaN
   

   Dividing a positive number with a negative number yields a negative result, while dividing a negative number with a negative number yields a positive result. Since division by zero is possible, you'll get different result depending on whether you divide a number with 0.0 or -0.0. Yes, it's true! Java has a negative zero! Don't be fooled though, the two zero values are equal as shown below.

   System.out.println(22.0 / 0.0);
   System.out.println(22.0 / -0.0);
   System.out.println(0.0 == -0.0);
   Infinity
   -Infinity
   true
   

7. Infinity is weird

   In the world of mathematics, infinity was a concept I found hard to grasp. For example, I never acquired an intuition for when one infinity were infinitely larger than another. Surely Z > N, the set of all rational numbers is infinitely larger than the set of natural numbers, but that was about the limit of my intuition in this regard!

   Fortunately, infinity in Java is about as unpredictable as infinity in the mathematical world. You can perform the usual suspects (+, -, *, / on an infinite value, but you cannot apply an infinity to an infinity.

   double infinity = 1.0 / 0.0;
   System.out.println(infinity + 1);
   System.out.println(infinity / 1e300);
   System.out.println(infinity / infinity);
   System.out.println(infinity - infinity);
   Infinity
   Infinity
   NaN
   NaN
   

   The main problem here is that the NaN value is returned without any warnings. Hence, should you foolishly investigate whether a particular double is even or odd, you can really get into a hairy situation. Maybe a run-time exception would have been more appropriate?

   double d = 2.0, d2 = d - 2.0;
   System.out.println("even: " + (d % 2 == 0) + " odd: " + (d % 2 == 1));
   d = d / d2;
   System.out.println("even: " + (d % 2 == 0) + " odd: " + (d % 2 == 1));
   even: true odd: false
   even: false odd: false
   

   Suddenly, your variable is neither odd nor even! NaN is even weirder than Infinity An infinite value is different from the maximum value of a double and NaN is different again from the infinite value.

   double nan = 0.0 / 0.0, infinity = 1.0 / 0.0;
   System.out.println( Double.MAX_VALUE != infinity );
   System.out.println( Double.MAX_VALUE != nan );
   System.out.println( infinity         != nan );
   true
   true
   true
   

   Generally, when a double have acquired the value NaN any operation on it results in a NaN.

   System.out.println( nan + 1.0 );
   NaN
   

8. Conclusions

   1. Decimal numbers are approximations, not the value you assign. Any intuition gained in math-world no longer applies. Expect a+b = a and a != a/3 + a/3 + a/3
   2. Avoid using the ==, compare against some tolerance or use the >= or <= operators
   3. Java is WYSINWYG! Never believe the value you print/write is approximated value, hence always read/write decimal numbers in the same format.
   4. Be careful not to overflow your double, not to get your double into a state of ±Infinity or NaN. In either case, your calculations may be not turn out as you'd expect. You may find it a good idea to always check against those values before returning a value in your methods.

While BigDecimal can store more precision than double, this is usually not required. The real reason it used because it makes it clear how rounding is performed, including a number of different rounding strategies. You can achieve the same results with double in most cases, but unless you know the techniques required, BigDecimal is the way to go in these case.

A common example, is money. Even though money is not going to be large enough to need the precision of BigDecimal in 99% of use cases, it is often considered best practice to use BigDecimal because the control of rounding is in the software which avoids the risk that the developer will make a mistake in handling rounding. Even if you are confident you can handle rounding with double I suggest you use helper methods to perform the rounding which you test thoroughly.