Problem with the addition of double numbers

Question

when we try to add the two double numbers say,
119.52, 10.00
here we should get 129.52
but it is giving as 129.51999999999998
This is happening only for sum numbers.
Here i want to round this to two digits after decimal point
if i round the above value i will get 129.52 and the problem will be solved.
But we don't know exactly on what basis we are getting the sum as 129.51999999999998.
Assume that, tomorrow when we are adding some other numbers we may got like
129.51444444444448
when we round this we get 129.51
but actually we have to get 129.52.
If anyone know why the system is giving that wrong sum , please give solution to avoid this.
In My application , i want the exact sum amount so if i add some numbers i should get exact sum.
like 119.52+10=129.52
i want exactly this. How to get this.

Answer 1

As another poster said, this is a topic worth reading up on, as there are subtleties involved in this kind of imprecise math. A couple of points to get you started though...
* Java's double type has a precision of something like 16 (20? 24?) decimal places. (You should be able to find the correct number in the lang. spec., or someone may be kind enough to post it here.) I don't remember the formal definition, but what this means, approximately, is that any number that can be represented will be accurate to within +/-0.5*10^-16 of its value. That is, if the actual value is 2e5, then the absolute value of the error in the representation will be less than 0.5e-11. (I might be off be a factor of 2 and/or an order of magnitude here, but you get the general idea.) The good news is, no value will be in error by more than that amount. The bad news is, any value could be in error by up to that amount. These are the two key points.
* Compare the precision implicit in your data and needed in your results to that of Java, along with the number of intermediate calculations you'll do to get a final result. For instance, if you're doing financial calcs in the tens of billions of dollars, and you need accuracy to the penny, that's one part in 10^-12. Assuming any given value is off by no more than one part in 10^-16, and assuming all errors are in the same direction, if you do 10^4 cumulative additions, you'll be off by a penny. Again, these are rough, and I may have missed something, but this is the kind of thing to look at to determine how the inherent imprecision will affect you.
* Don't round any intermediate results. Keep the precision you have. However, when you're comparing (as jschell demonstrated) make a copy of the value and round that copy before doing the comparison. Use the first two points above to determine whether that rounding will meet your needs for precision. Same goes for displaying.
* Finally, if the 10^-16 (or whatever it was) precision of a double is not sufficient, you can get arbitrary precision with BigDecimal. There are a couple of caveats, however. 1) It's a lot slower than using primitives ans 2) Arbitrary precision does not mean infinite precision. You can specify as many decimal places as you want (subject to time and memory constraints), but you even if you specify 1,000 decimal places, you can still be off by 5 in the 1001st place.