Wednesday, February 29, 2012

Java is considered very safe programming language compared to C and C++ as it doesn't have free() and malloc() to directly do memory allocation and deallocation, You don't need to worry of array overrun in Java as they are bounded and there is pointer arithmetic in Java. Still there are some sharp edges in Java programming language which you need to be aware of while writing enterprise application. Many of us make subtle mistake in Java which looks correct in first place but turn out to be buggy when looked carefully. In this series of java articles I will be sharing some of common Java mistake programmers make while programming application in Java. As I have said earlier every day we learn new things but we forget something equally important. This again highlight importance of code review and following best practices in Java. In this part we will discuss why double and float should not be used in monetary or financial calculation where exact result of calculation is expected.

Using double and float for exact calculation

This is one of common mistake Java programmer make until they are familiar with BigDecimal class. When we learn Java programming we have been told that use float and double to represent decimal numbers its not been told that result of floating point number is not exact, which makes them unsuitable for any financial calculation which requires exact result and not approximation. float and double are designed for engineering and scientific calculation and many times doesn’t produce exact result also result of floating point calculation may vary from JVM to JVM. Look at below example of BigDecimal and double primitive which is used to represent money value, its quite clear that floating point calculation may not be exact and one should use BigDecimal for financial calculations.

From above example of floating point calculation is pretty clear that result of floating point calculation may not be exact at all time and it should not be used in places where exact result is expected.

Using Incorrect BigDecimal constructor

Another mistake Java Programmers make is using wrong constructor of BigDecmial. BigDecimal has overloaded constructor and if you use the one which accept double as argument you will get same result as you do while operating with double. So always use BigDecimal with String constructor. here is an example of using BigDecmial constructed with double values:

difference between 2.15 and 1.0 using BigDecmial is: 1.049999999999999822364316059974953532218933105468750

I agree there is not much difference between these two constructor but you got to remember this.

Using result of floating point calculation in loop condition

One more mistake from Java programmer can be using result of floating point calculation for determining conditions on loop. Though this may work some time it may result in infinite loop another time. See below example where your Java program will get locked inside infinite while loop:

double amount1 = 2.15;

double amount2 = 1.10;

while((amount1 - amount2) != 1.05){

System.out.println("We are stuck in infinite loop due to comparing with floating point numbers");

}

Output:

We are stuck in infinite loop due to comparing with floating point numbers

We are stuck in infinite loop due to comparing with floating point numbers

……………

…………..

This code will result in infinite loop because result of subtraction of amount1 and amount 2 will not be 1.5 instead it would be "1.0499999999999998" which make boolean condition true.

That’s all on this part of learning from mistakes in Java, bottom line is :

Funny to read about financial calculation. This java double format is useless for science too. Or want someone used that to calculate statistics of medical drugs safety for example?

I think this type actually is mistake. Seams that someone forgot to set all bits from 8 byte number to 0 and rounds some memory garbage from a tail in every operation. And the most evil you can not predict this error - next operation you can add it in your result or multiply

And BigDecimal is not a cure, because it is limited to use only functions - not operators. As for me it is horror to write some opeartion like a = x*b+c*b using BigDecimal class and it's functions.

Using float and double for financial calculations can be serious mistake. Great to see that you are educating people with this kind of practical advice, long is also not a perfect solution, as monetary calculation for notional and future predictions may go beyond range of long data type.

float and double data types are mainly provided for scientific and engineering calculations. Java uses binary floating point calculations which is good for approximation but doesn't provide exact result. Bottom line is, don't use float/double when exact calculation is needed. You can not represent values like 0.1 or 0.01 or any negative power of 10 accurately in Java. calculating interest, expenses is one example of this.

You shouldn't use BigDecimal for financial calculations either. You should really use a specific Currency class instead. Imagine this: You calculate a discount of 50% on a price of $5.55. That results in a discount of $2.755 and a discounted price of $2.755. Since we cannot pay $2.755 we need to round the numbers. So we round them. Result: Discount is now $2.76 and price is now $2.76 . Total is $0.02 higher than the total price before discount. The solution is of course to calculate the discount, round it, and then *subtract* it from the original price, in order to get the discounted price. You can do this with a BigDecimal, but a designated Currency class is just a better approach. A Currency class with discount() and other methods on, which perform these calculations correctly.

This is nonsense and a damn myth. Double is fine for financial calculations, given you understand its limitations, and only want cent precision.

The first important part to understand is that you can't use the == operator to determine equality for doubles (you shouldn't ever do this).

Instead, you use an operator like boolean equalsWithinPrecision(double a, double b, double eps) { return Math.abs(a-b) < eps;}where a sane value for eps varies with application. 1E-2, 1E-10, whatever. It's also common to have rounding as the last step in any sequence of calculations.

The second part is to understand that doubles begin to lose precision at very large values. Although this doesn't become a problem until about 2^52 (10^15-ish). So unless you're dealing in sums in the trillions of dollars, you're basically fine.﻿

It is not a myth. Manually rounding on doubles is the same a applying duct tape: it will usually work, for a while... Its better to use a type/library that can represent your financial amounts exactly, with the exact/correct decimal rounding applied automatically after every operation.﻿

By Jelle Foks,The keyword for financial calculations, is not "arbitrary precision math", it is decimal fixed or floating point. The difference is in the rounding. There is a reason why it's defined as part of IEEE 754-2008, and if you don't use it where you should, people can end up with other people's money, that's why people tend to find it more important to do the calculation right than to do it fast.﻿See more discussion on this thread :https://plus.google.com/b/116401207721513511359/116401207721513511359/posts