On Thu, 21 Jul 2022 21:22:19 GMT, Joe Darcy <da...@openjdk.org> wrote:
>> Initial implementation. > > Joe Darcy has updated the pull request with a new target base due to a merge > or a rebase. The incremental webrev excludes the unrelated changes brought in > by the merge/rebase. The pull request contains 20 additional commits since > the last revision: > > - Method rename. > - Merge branch 'master' into JDK-8289551 > - Respond to review feedback; improve tests. > - Add NaN test. > - Preserve NaN sign bit. > - Respond to review feedback. > - Correct carry-out bug; add full binade test. > - Improve NaN significand fidelity; refine tests. > - Partial implementation of review feedback; test refinement. > - Merge branch 'master' into JDK-8289551 > - ... and 10 more: https://git.openjdk.org/jdk/compare/97f81c3e...9b060185 Thanks for the review comments thus far. A few notes on the recently pushed update, corresponding to webrev 04. The conversion methods have been renamed as suggested in comments received outside of the PR. Thinking more about how a future possible value class for the binary16 format might be structured (java.math.FloatBinary16? java.math.Binary16?), even if such a class cannot extend java.lang.Number, it could still implement the conversion methods found on Number. In particular, a value class for binary16 could have a "floatValue" method as well as factory to convert from float to binary16. Therefore, there need not be any overloading concerns with the methods defined on Float for this issue. (As an aside, it might be helpful to define a superinterface with the methods of java.lang.Number to better capture the ConvertibleToPrimitive API.) The regression tests were augmented in several ways. One is by the introduction of an alternative implementation of the float -> binary16 conversion that uses the hardware support for float rounding to compute the proper low-order bits. This approach benchmarked as significantly slower than the existing bit-inspection approach so it is just used to double-check in testing. Before updating the PR, all 2^32 float values were converted to binary16 using both approaches and the results matched. Testing all 2^32 values all the time seems excessive, so in the PR just one exponent value is checked. For each exponent in normal range, the rounding is analagous at corresponding positions of the number line. Therefore, testing one exponent should be sufficient for testing all the different combination of bit that influence rounding. ------------- PR: https://git.openjdk.org/jdk/pull/9422
