20

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.

mskfisher
  • 3,291
  • 4
  • 35
  • 48
Engineer
  • 8,529
  • 7
  • 65
  • 105

3 Answers3

23

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.

The Alchemist
  • 3,397
  • 21
  • 22
  • In other words, this is completely superior to the epsilon approach? I can't believe my luck, if so. – Engineer Sep 08 '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 08 '10 at 14:20
  • 1
    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. – Engineer Sep 08 '10 at 14:30
  • Math.abs() < epsilon MIGHT be faster, but epsilon should(!!) change as your values change. See here for an explanation: http://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/ 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 04 '14 at 13:22
10

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
gawi
  • 13,940
  • 7
  • 42
  • 78
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.

gpeche
  • 21,974
  • 5
  • 38
  • 51