-
Enhancement
-
Resolution: Fixed
-
P4
-
7
-
b123
-
x86
-
windows_7
-
Not verified
A DESCRIPTION OF THE REQUEST :
The code in Math.max and Math.min looks like this:
private static long negativeZeroFloatBits = Float.floatToIntBits(-0.0f);
public static float max(float a, float b) {
if (a != a) return a; // a is NaN
if ((a == 0.0f) && (b == 0.0f)
&& (Float.floatToIntBits(a) == negativeZeroFloatBits)) {
return b;
}
return (a >= b) ? a : b;
}
so negativeZeroFloatBits can never equal one of the NaN bit pattern. As the result of floatToIntBits(a) is only used to compare to negativeZeroFloatBits there is no need to do NaN normalization.
JUSTIFICATION :
Using floatToRawIntBits() is faster then floatToIntBits() and the additional logic performed in floatToIntBits() has no impact on the decision of Math.max() - esp as the NaN is already handled.
The code in Math.max and Math.min looks like this:
private static long negativeZeroFloatBits = Float.floatToIntBits(-0.0f);
public static float max(float a, float b) {
if (a != a) return a; // a is NaN
if ((a == 0.0f) && (b == 0.0f)
&& (Float.floatToIntBits(a) == negativeZeroFloatBits)) {
return b;
}
return (a >= b) ? a : b;
}
so negativeZeroFloatBits can never equal one of the NaN bit pattern. As the result of floatToIntBits(a) is only used to compare to negativeZeroFloatBits there is no need to do NaN normalization.
JUSTIFICATION :
Using floatToRawIntBits() is faster then floatToIntBits() and the additional logic performed in floatToIntBits() has no impact on the decision of Math.max() - esp as the NaN is already handled.
- relates to
-
JDK-7128441 StrictMath performance improvement not shared with Math
-
- Closed
-