Hello, I am doing extensive calculations in my project which involves the use of "double" variable type as it is big enough to hold its values. However I came across some bizare results! Take for example in the code below:

Now, I am expecting the total to be 8961.28, but the result I am getting is "a: 4190.04 b:4771.24 total:8961.2799999999" Surely a simple addition of two doubles shouldn't be required to be rounded everytime? Is there a solution to this problem? I am using jdk1.3.1b if that would be any help! Thanks

double a=4190.04d; double b=4771.24d; double total =0d; total=total+a+b=0d+4190.04d+4771.24d=8961.28d as you wish.But the result 8961.2799999999 is what the double precision make sense!Double type always keep the precision fragment as long as it can.In other words,8961.28d equal to 8961.2799999999.

(Marilyn formatted code so it's not all on one line) [ December 19, 2002: Message edited by: Marilyn de Queiroz ]

Just a little more info: If you really want to see your results with, say two decimal places, just do the following

Darren Tweedale
Greenhorn

Joined: Jan 30, 2002
Posts: 16

posted

0

I am sorry Marilyn, but I still can't understand why there should be a loss of 0.0000001 in the simple addition of two double values! Thanks to norm, however, I need functionaility to either round up or down to so many decimal places (i use BigDecimal.setScale to do this) and store its proper values into the double varable) and I don't display the results. Oh well, it looks like I have to change everything to long or float as they seemed to work! Thanks for your inputs. Bye

The problem isn't with Java or any programming language in particular. Remember that all numbers are stored as binary in the computer. Many floating point numbers cannot be stored accurately, so there will always be round off errors when doing any kind of calculations with them (even addition). To help you understand, a simple example may make it more clear. Take the fraction 1/3. In base 10 decimal, this can be written as .33333-repeating forever. However, most people get tired of writing 3's forever, so we settle for rounding off to a certain number of digits. Let's just say we take two digits after the decimal place. So we can add .33 + .33 + .33 = .99. However, adding the original fraction we get 1/3 + 1/3 + 1/3 = 3/3 = 1. During the calculation, we lost .01. The same thing happens when decimals are converted to binary floating point numbers. The loss of precision happens during the conversion, not when the converted numbers are added.