Why use Float.floatToIntBits() in Java float comparisons?

Question

In JBox2d, there exists the following code for Vec2.equals():

@Override
public boolean equals(Object obj) { //automatically generated by Eclipse
    if (this == obj)
        return true;
    if (obj == null)
        return false;
    if (getClass() != obj.getClass())
        return false;
    Vec2 other = (Vec2) obj;
    if (Float.floatToIntBits(x) != Float.floatToIntBits(other.x))
        return false;
    if (Float.floatToIntBits(y) != Float.floatToIntBits(other.y))
        return false;
    return true;
}

I am wondering what purpose the float<->int bit conversions functions serve, here. Does this provide a way to get around Java's float comparison inaccuracy problem (if such is even possible)? Or is it something else altogether? I am wondering if it is an alternative to the epsilon approach:

if (Math.abs(floatVal1 - floatVal2) < epsilon)

PS. for the sake of completeness and interest, here is Vec2.hashCode():

@Override
public int hashCode() { //automatically generated by Eclipse
    final int prime = 31;
    int result = 1;
    result = prime * result + Float.floatToIntBits(x);
    result = prime * result + Float.floatToIntBits(y);
    return result;
}

FYI, I can see perfectly why the conversion functions are used in hashCode() -- hash IDs must be integers.

Answer 1

The explanation can be found in Joshua Bloch's Effective Java: float and Float need special treatment because of the existence of -0.0, NaN, positive infinity, and negative infinity. That's why the Sun JVM's Float.equals() looks like this (6u21):

public boolean equals(Object obj)
{
    return (obj instanceof Float)
           && (floatToIntBits(((Float)obj).value) == floatToIntBits(value));
}

So, no, Math.abs() with an epsilon is not a good alternative. From the Javadoc:

If f1 and f2 both represent Float.NaN, then the equals method returns true, even though Float.NaN==Float.NaN has the value false. If f1 represents +0.0f while f2 represents -0.0f, or vice versa, the equal test has the value false, even though 0.0f==-0.0f has the value true.

That's why Eclipse's autogenerated code does that for you.

Answer 2

Double.Nan (Not-a-number) is a special value when it comes to comparison:

System.out.println(Float.NaN == Float.NaN);
System.out.println(Float.floatToIntBits(Float.NaN) == Float.floatToIntBits(Float.NaN));

This prints:

false
true 

Answer 3

I do not know 100%, but most probably they are trying to get around the NaN != NaN problem. If your float happens to be NaN you cannot compare to anything as the result is always false. Comparing the intBits will give you NaN == NaN.