Double precision discrepancy between C and Java

Question

I'm writing code in different languages that involves double precision arithmetic. Ideally the programs need to yield exactly the same values. I'm aware that not all double/float arithmetic is deterministic (explained nicely here: https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/), so I need to be carefeful. Can someone explain what is going on here though?:

C program:

#include <stdio.h>
#include <stdlib.h>

int
main(void) {
    printf("%.52f\n", 1.66007664274403694e-03);
    return (EXIT_SUCCESS);
}

Result: 0.0016600766427440369430584832244335302675608545541763

"Equivalent" Java 8 program:

class A {
    public static void main(String args[]) {
        System.out.printf("%.52f\n", 1.66007664274403694e-03D);
    }
}

Result: 0.0016600766427440370000000000000000000000000000000000

The results are different. I have a feeling that this may be related to floating point rounding modes, however, as far as I can see C and Java have the same defaults (?).

How can I ensure the two programs have the same result?

EDIT:

FWIW, If I print the constant as a BigDecimal: System.out.printf("%.52f\n", new BigDecimal(1.66007664274403694e-03));, I get: 0.0016600766427440369430584832244335302675608545541763. This might prove that this is not a display issue, but who knows what magic the JVM does underneath.

EDIT2:

Using strictfp as @chris-k suggests, I annotated the class, and the result remains as 0.0016600766427440370000000000000000000000000000000000.

EDIT3:

Another suggestion was to try System.out.printf("%.52f\n", new BigDecimal("1.66007664274403694e-03")); which gives a result we have not seen yet: 0.0016600766427440369400000000000000000000000000000000.

Answer 1

I think this is a display issue. The precision specifier in System.out.printf is not allowing the precision to be increased beyond a certain point (after that, it just prints trailing 0 digits).

If you don't care so much about the printed value and just want it to be the same between the two, extract the sign/mantissa/exponent and print them, eg in Java:

    long mantissa = Double.doubleToLongBits(f) & 0x000fffffffffffffL;
    long exponent = Double.doubleToLongBits(f) & 0x7ff0000000000000L;
    long sign = Double.doubleToLongBits(f)  & 0x8000000000000000L;

    // Exponent is encoded with a bias, so to see the actual exponent
    // value:
    exponent >>= (13 * 4);
    exponent -= 1023;

    // Leading 1 bit for mantissa isn't stored:
    mantissa |= 0x0010000000000000L;

    if (sign != 0) sign = 1;
    System.out.println("" + sign + "/" + mantissa + "/" + exponent);

For Java this prints:

    0/7655752242860553/-10

Equivalent C code (works with GCC on x86-64):

#include <string.h>
#include <stdio.h>

int main(int argc, char ** argv)
{
    double f = 1.66007664274403694e-03;

    long long doubleBits;
    memcpy(&doubleBits, &f, sizeof(long long));

    long long mantissa = doubleBits & 0x000fffffffffffffLL;
    long long exponent = doubleBits & 0x7ff0000000000000LL;
    long long sign = doubleBits  & 0x8000000000000000LL;

    // Exponent is encoded with a bias, so to see the actual exponent
    // value:
    exponent >>= (13 * 4);
    exponent -= 1023;

    // Leading 1 bit for mantissa isn't stored:
    mantissa |= 0x0010000000000000L;

    if (sign != 0) sign = 1;
    printf("%lld/%lld/%lld\n", sign, mantissa, exponent);

    return 0;
}

On my machine, it produces the same output. This shows that the internal representation of the constant is the same on both platforms (of course this might not be universally true across architectures and implementations). The discrepancy in the output from your original programs is due to differences in the implementation of the printf functions. (The Java version apparently stops calculating digits after some point and prints 0's instead, possibly to avoid printing floating point constants differently to how they are written in the source code).

On the other hand if this were a calculated value rather than a constant you are likely to have a more difficult time getting the value between C and Java to match :)

Answer 2

You could very well have a display issue here only. However during calculations Java is free to differ from C's behaviour.

Java is free to use extra precision in a floating point calculation if it is available on a platform. However Java does offer an override, declare your double as being strictfp and that will inform the JVM to restrict the calculations making them more portable.

You may also want to check out the class StrictMath in Java, it also has a few utils that have been implemented in C for compatibility purposes.

Answer 3

Use BigDecimal in Java for such operations:

    BigDecimal x = new BigDecimal(1.66007664274403694e-03D);
    System.out.printf(x.toPlainString());

A primitive float in Java is only 4 bytes wide.