2

I understand that computer can not represent non-integral numbers precisely. so when I add 2 doubles in java for example:

724.64d + 1000d

the console print out 1724.6399999999999

but why for 724.64d + 100d and 724.64d + 10000d

the console print out 824.64 and 10724.64 separately?

is there a way to know at what condition when I add the 2 doubles, the sum is the exact number ?

The reason why I ask is because that our old program use double to do calculation. and use double comparison to validate the numbers. for example: let us say the total is 1849.64, all the inputs amounts added up must be equals to total which is 1849.64

input 1: 724.64
input 2: 1125

will not work, because the sum will be 1849.6399999999999

but if we input like this below will work, and the sum is 1849.64

input 1: 24.64
input 2: 1825

so how to find those combinations that work? Note, I do not have access to this specific very old program. when the validation failed, we have to manually find a walk around like the second inputs combination. Thanks.

Improve this question
8
  • You will have to accept certain amount of error here I think. Commented Oct 26, 2012 at 20:30
  • 1
    if you wish to know for which numbers there's exact representation in Java, you will have to understand Java Language Spec, item 4.5.3 which points to IEEE 754. Lots of concrete undergrad math there. But it makes little sense, unless you going to develop your own programming language. Commented Oct 26, 2012 at 20:37
  • I am trying to figure out a quick way to manually change the inputs combination for our customers to pass the validation. I do not have access to change the code to the old program. Commented Oct 26, 2012 at 20:45
  • @huahua You need to choose numbers whose mantissas in IEEE 754 representation have lots of trailing zeroes. Reasonably small integers such as 100d and 1000d are such numbers. 724.64d isn't but 724.5d and 724.75d and 724.625d are. Commented Oct 26, 2012 at 21:17
  • @PascalCuoq In fact, all integers up to 2^54 are exactly representable in a double. Commented Oct 27, 2012 at 6:44

5 Answers 5

Reset to default
2 
BigDecimal bigDecimal = new BigDecimal(724.64);
bigDecimal = bigDecimal.add(new BigDecimal(1000.0));
System.out.println(bigDecimal.floatValue());<--Works fine 
System.out.println(bigDecimal.doubleValue());<--Works as mentioned in Question

Output:

1724.64
1724.6399999999999

In the first case it works because of narrowing primitive conversion happens. But with Floating-Point numbers you will have to accept and live with it.

As I stated the reason it is valid for primitives 

double d = 724.64;
double d1 = 1000.0;
System.out.println(d + d1);
System.out.println((float) (d + d1));

Output:

1724.64
1724.6399999999999
Improve this answer
Sign up to request clarification or add additional context in comments.

2 Comments

thanks sorry forget to mention I do not have access to the code of the old program
I think this line: System.out.println((float) (d + d1)); is narrowing primitive conversion. it convert double to float which narrows the precision.
1

Floating-point numbers don't represent numbers in the decimal, but in binary system and obviously they are of only finite precision, so there is a mismatch between the exact values a decimal system represents and those a floating-point number can represent. You must not expect it to do so.

Improve this answer

2 Comments

I know some number can not be represented exactly by binary just like some number can not be represented by decimal exactly such as π . The only choice I have right now is to guess what other combination to pass the validation. I am wondering is there a guild line to do such guess? sometimes we got customer call, they complain about such validation failure stuff, we just need to tell them to try to input this number and that number instead.
Go to this page where they have a Java applet to set each individual bit in a double. All numbers that have zeros in the right part of the mantissa will be easier to represent in decimal form. Play around with it a bit to see how it works.
1

Rather than try to determine what conditions result in exact or inexact calculations consider using BigDecimal for these situations.

Improve this answer

Comments

1

To answer your final question, a double is exact if the fractional part is a negative power of two, for example zero, 1/2, 1/4, 1/16, ..., It will appear to be exact in some other cases, like the ones you posted, if the API you use to convert them to decimal (for example System.out.println()) does rounding or truncation and the value is close enough that the rounding or truncation yields the expected answer.

Improve this answer

1 Comment

so how to locate some other combination quickly to make the sum is 1849.64. such as: input 1: 24.64 input 2: 1825 . or we can only do a random guess?
0

If comparison is the issue, as a workaround, I would advice to format the numbers in string with 2 decimal places and rounding done and then compare the strings:

        double expectNum = 1849.64;
        double resultNum = 1849.639999;

        String expectedString = String.format("%.2g%n", expectNum);
        String resultString = String.format("%.2g%n", resultNum);

        if(expectedString.equals(resultString)){
           //result matched
           //return true;
        }else{
           //return false;
        }
Improve this answer

3 Comments

@EJP: I mentioned in the beginning itself. Its work around solution for comparison.
He doesn't have control of the source code. He is looking for test data that will work with the existing comparison. Not an answer.
my question is not to fix the program, but find a way to give customer a walk around to pass the validation.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.