Floating point inaccuracy

[Aga]

Hi,

I have the following code:

System.out.println(" fac5 = ln(fac2 / fac3) = " + fac5);
System.out.println(" fac4 / fac2 = " + fac4 / fac2);
System.out.println(" fac4 / fac3 = " + fac4 / fac3);
double FAC1 = (fac4 / fac2) - (fac4 / fac3);
System.out.println(" FAC1 = fac4 / fac2 - fac4 / fac3 = " + FAC1 );
double FAC2_1 = fac5 + FAC1;
double FAC2_2 = fac5 + (fac4 / fac2) - (fac4 / fac3);
System.out.println(" FAC2_1 = fac5 + fac4 / fac2 - fac4 / fac3 using FAC1= " + FAC2_1 );
System.out.println(" FAC2_2 = fac5 + fac4 / fac2 - fac4 / fac3 computed= " + FAC2_2 );

whose output is:

fac5 = ln(fac2 / fac3) = -7.294165271787545E-14
fac4 / fac2 = 1.000000000000219
fac4 / fac3 = 1.0000000000001459
FAC1 = fac4 / fac2 - fac4 / fac3 = 7.30526750203353E-14
FAC2_1 = fac5 + FAC1= 1.1102230245985246E-16
FAC2_2 = fac5 + fac4 / fac2 - fac4 / fac3 = 0.0 !!!!!:confused:

Incredibly, FAC2_1 and FAC2_2 give different results when they are the same calculation made in two different ways.

I'd appreciate any help on clarifying why this happens. Thank you.

[KevinWorkman]

That's expected. For a full article, google "what every computer scientist should know about floating-point arithmetic".

But the gist of it is, many numbers can not be represented in binary, so they must be rounded to something that can. This leads to inaccuracies when dealing with small numbers.

PS- When posting code, it should be in the form of an SSCCE, and you should use the code tags. What you posted really doesn't give us any idea what you're doing.

[JosAH]

Read this: http://www.cse.msu.edu/~cse320/Docum...atingPoint.pdf

kind regards,

Jos

[JosAH]

But the gist of it is, many numbers can not be represented in binary, so they must be rounded to something that can. This leads to inaccuracies when dealing with small numbers.

Not only with small numbers; for very large numbers the absolute accuracy gets worse; see that mysterious ulp( ... ) method in the Math class.

kind regards,

Jos

[Aga]

Thank you all so much for your answers and the reference.

I would not have expected a 1.0E-16 result using DOUBLE primitives to be rounded off to zero, thus my surprise. I wonder whether C or FORTRAN would have the same problem. Any guesses??

[JosAH]

Thank you all so much for your answers and the reference.

I would not have expected a 1.0E-16 result using DOUBLE primitives to be rounded off to zero, thus my surprise. I wonder whether C or FORTRAN would have the same problem. Any guesses??

Not a guess, but a fact: Java uses the same IEEE/754 floating format rules as C and Fortran do; don't be mislead by the textual representation of those numbers (i.e. when you print them).

kind regards,

Jos

[toadaly]

Thank you all so much for your answers and the reference.

I would not have expected a 1.0E-16 result using DOUBLE primitives to be rounded off to zero, thus my surprise. I wonder whether C or FORTRAN would have the same problem. Any guesses??

One thing java does have though , is a class arbitrary precision floating point - if you need more precision than a double will give. Take a look at java.math.BigDecimal.

Many 64 bit linux machines also have a 'long double' type, that's 16 bytes. There is no direct representation for that (yet) in java.