Forum: Building APIs & Wire Protocol

Post: Official Java Bit Patterns for Nan and Infinities

Official Java Bit Patterns for Nan and Infinities
henning
Apr 25, 2010
In case s.o. needs to encode NaN and Infinities, building an API for a different language:


Java has official bit values for them, which are not part of the IEEE 754 standard. There are many other bit patterns that are also NaNs.


This can be useful because NaN and Infinities can be send to a Stored Procedure, though not stored in the database.


POSITIVE_INFINITY: 0x7f800000
NEGATIVE_INFINITY: 0xff800000
NaN: 0x7fc00000


From: http://www.docjar.com/html/api/java/lang/Float.java.html


Home Open-JDK-6.b17-src java lang source

48 * @since JDK1.0 49 */
50 public final class Float extends Number implements Comparable<Float> {
51 /**
52 * A constant holding the positive infinity of type
53 * {@code float}. It is equal to the value returned by
54 * {@code Float.intBitsToFloat(0x7f800000)}.
55 */
56 public static final float POSITIVE_INFINITY = 1.0f / 0.0f;
57
58 /**
59 * A constant holding the negative infinity of type
60 * {@code float}. It is equal to the value returned by
61 * {@code Float.intBitsToFloat(0xff800000)}.
62 */
63 public static final float NEGATIVE_INFINITY = -1.0f / 0.0f;
64
65 /**
66 * A constant holding a Not-a-Number (NaN) value of type
67 * {@code float}. It is equivalent to the value returned by
68 * {@code Float.intBitsToFloat(0x7fc00000)}.
69 */
70 public static final float NaN = 0.0f / 0.0f;
Good news!
aweisberg
May 7, 2010
Hi Henning,


I have done some code snooping in Java's ByteBuffer class and it turns out that it takes care of the conversion from Java floats to IEEE 754 floats. If you try and send a Java float to us on the wire it might get mangled when ByteBuffer attempts to decode it as an IEEE 754 float. We still need better test coverage of floating point expressions involving Nan and +-Inf, but there is no reason to think they wouldn't behave as expected.


-Ariel
Ieee 754
henning
May 16, 2010
Are there any other differences between Java and IEEE 754 except for the NaN types and their flags?


Not in the representation of 'real' float numbers I take it?


Thanks,
Henning
Here is the JVM spec for
aweisberg
May 17, 2010
Are there any other differences between Java and IEEE 754 except for the NaN types and their flags?


Not in the representation of 'real' float numbers I take it?


Thanks,
Henning


Here is the JVM spec for floats and doubles
http://java.sun.com/docs/books/jvms/second_edition/html/Concepts.doc.html#33377
The elements of the float value set are exactly the values that can be represented using the single floating-point format defined in the IEEE 754 standard, except that there is only one NaN value (IEEE 754 specifies 224 - 2 distinct NaN values). The elements of the double value set are exactly the values that can be represented using the double floating-point format defined in the IEEE 754 standard, except that there is only one NaN value (IEEE 754 specifies 253 - 2 distinct NaN values). Note, however, that the elements of the float-extended-exponent and double-extended-exponent value sets defined here do not correspond to the values that can be represented using IEEE 754 single extended and double extended formats, respectively.
VoltDB expects true IEE 754 floats and doubles on the wire and not the Java version. This is because Java already correctly handles the conversion from IEEE 754 to Java floats/doubles in ByteBuffer.
Shift to "Wire Protocol Forum"
henning
May 16, 2010
This thread could be shifted to the new Wire Protocol Forum I think.
Scarlett
Oct 29, 2014
This is usually solved by structuring your application and procedures so that the procedures are idempotent and can be retried.

The right way to do that is application specific, and we should drill down on why you can't call the procedure multiple times.