-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
8, 11, 15, 17
A DESCRIPTION OF THE PROBLEM :
According to IEEE754, Section 5.5.1,
negation affects NaN's also. Applied to Double.NaN, we can see
that Double.doubleToRawLongBits(Double.NaN) == Double.doubleToRawLongBits(-Double.NaN),
which contradicts the standard.
According to the standard, there shall be also an absolute value function.
It seems as if Math.abs(...) satisfies the specification also for NaN and is thus ok.
The same is true for Double.copySign(double,double).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
evaluate
Double.doubleToRawLongBits(Double.NaN) == Double.doubleToRawLongBits(-Double.NaN)
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
negation shall even apply to NaN.
ACTUAL -
negation is neglected for NaN
---------- BEGIN SOURCE ----------
see above.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
write own negation routine.
FREQUENCY : always
According to IEEE754, Section 5.5.1,
negation affects NaN's also. Applied to Double.NaN, we can see
that Double.doubleToRawLongBits(Double.NaN) == Double.doubleToRawLongBits(-Double.NaN),
which contradicts the standard.
According to the standard, there shall be also an absolute value function.
It seems as if Math.abs(...) satisfies the specification also for NaN and is thus ok.
The same is true for Double.copySign(double,double).
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
evaluate
Double.doubleToRawLongBits(Double.NaN) == Double.doubleToRawLongBits(-Double.NaN)
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
negation shall even apply to NaN.
ACTUAL -
negation is neglected for NaN
---------- BEGIN SOURCE ----------
see above.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
write own negation routine.
FREQUENCY : always