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.
The explanation can be found in Joshua Bloch’s Effective Java:
floatandFloatneed special treatment because of the existence of-0.0,NaN, positive infinity, and negative infinity. That’s why the Sun JVM’sFloat.equals()looks like this (6u21):So, no,
Math.abs()with an epsilon is not a good alternative. From the Javadoc:That’s why Eclipse’s autogenerated code does that for you.