RFC 8010430: Math.round has surprising behavior for odd values of ulp 1

[Brian Burkhalter]

This request for comment concerns this issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8010430.

The behavior in question occurs when the value of the unbiased exponent is equal to the signficand precision excluding the implicit leading bit, i.e., 23 in the case of float [1] or 52 in the case of double[2] , and the least significant bit in the significand is unity. As Math.round(a) is defined to be Math.floor(a+0.5) in these cases, the intermediate sum is calculated using the round-to-nearest rule so that the return value does not equal the parameter when the parameter is odd, even though the latter is a mathematical integer.

There are in effect two ways to resolve this issue:

A) Change the implementation to return (int)a or (long)a if the unbiased exponent of the value's floating point representation is greater than 22 or 51, respectively.

B) Change the specification to state, or add an implementation note stating that the behavior is defined to be round(a) = floor(a+0.5F) where round-to-nearest is applied to the intermediate sum.

Note that for comparison, GCC-compiled C code on Mac OS X and Ubuntu 12.04 follows the behavior of option A.

Thanks,

Brian

[1] https://en.wikipedia.org/wiki/Single_precision_floating-point_format
[2] https://en.wikipedia.org/wiki/Double-precision_floating-point_format