Different float values for same bytes on JVM/CLR

Question

I'm porting a program originally written in VB.NET to Java. I'm reading from a file which stores 32 bit floats in little endian order.

The original program does this:

Dim br As BinaryReader = ...
Dim f_vb As Single = br.ReadSingle

Java is big endian, so I reverse the bytes before converting to a float.

RandomAccessFile raf = // ...
int i = raf.readInt();
int bigEndian = Integer.reverseBytes(i);
float f_java = Float.intBitsToFloat(bigEndian);

As far as I can tell, f_vb and f_java contain the same bits. That is, BitConverter.ToInt32 on f_vb and Float.floatToIntBits (and floatToRawIntBits) on f_java give the same thing. However, the floats are not equal. For example, let bigEndian == 0x4969F52F. Java will report 958290.94, and VB.NET will report 958290.938. I'm guessing this comes from a difference in the way the JVM and CLR handle floating point numbers, but I don't know enough about floating point issues to figure out why. This loss of precision is causing trouble down the line, so I'd like to identify the source.

See also http://stackoverflow.com/questions/2053462/library-for-strict-floating-point-math-in-net — Pavel Savara, Jul 15 '12 at 18:47

score 6 · Accepted Answer · answered Jul 14 '12 at 03:35

The exact value represented by those bits is 958290.9375. It may be that whatever you used to display the value in Java, which displayed “958290.94”, rounds by default to two decimal places or eight significant figures, and whatever you used in VB.NET, which displayed “958290.938”, rounds by default to three decimal places or nine significant figures. Alternatively, one of them may be poor at converting floating-point to decimal for display.

If there are options to display more digits, try them. Alternately, construct the value 958290.9375, subtract it from the f_java, and test whether the result is exactly zero. It should be.

The single-precision floating-point numbers nearest 958290.9375 are 958290.875 and 958291. Neither of those could be displayed as “958290.94” or “958290.938” by any halfway decent formatter, so it is very unlikely the float you have is anything other than 958290.9375.

Hmm - I guess I will keep hunting for the source of my precision errors, then. Thanks for the help. — Eric W., Jul 14 '12 at 04:35
+1 Given `float` only has about 7 digits of accuracy, the shorter number is a better indication of the accuracy of the number. — Peter Lawrey, Jul 14 '12 at 07:35

Different float values for same bytes on JVM/CLR

1 Answers1