Take the 2-minute tour ×

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

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():

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.

share|improve this question

3 Answers 3

up vote 12 down vote accepted

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.

share|improve this answer
In other words, this is completely superior to the epsilon approach? I can't believe my luck, if so. –  Nick Wiggill Sep 8 '10 at 13:38
Well, if you can guarantee that you will not get any NaNs or -0.0 or infinities, then using Math.abs() < epsilon might be faster. Maybe. –  The Alchemist Sep 8 '10 at 14:20
I see from comments below that I was mistaking what this does. It solves problems centred around the special float values; it does not deal with float inaccuracy -- as you initially stated in your answer. So ignore my last question. –  Nick Wiggill Sep 8 '10 at 14:30
Math.abs() < epsilon MIGHT be faster, but epsilon should(!!) change as your values change. See here for an explanation: randomascii.wordpress.com/2012/02/25/… Therefore, unless you implement your own function to calculate a good epsilon, you might as well just use equals() since it will always give you the correct answer (to the available precision of your system, and with the exception of -0.0f to 0.0f). –  dberm22 Apr 4 at 13:22

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:

share|improve this answer

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.

share|improve this answer

Your Answer


