[lworld+fp16] RFR: 8329817: Augment prototype Float16 class [v5]

[Joe Darcy]

On Wed, 12 Jun 2024 04:41:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A few comments on the proposed revised API of Float16:
>> 
>> The Float16 class was generally brought up to static field and method level parity with java.lang.{Float, Double}. Additionally, a number of low-level floating-point handling methods from Math/StrictMath were added to, such as getExponent. These methods are usually an operation or recommended function from IEEE 754. Methods for arithmetic operators {+, -, *, /} and square root were also added. The value(short) method was changed from a bit-level conversion to a value-based one; bit-level conversion is provided by a new shortBitsToFloat16 method.
>> 
>> The current API favors static methods over instances one. Methods to extend the Number abstract class and implement Comparable are of necessity instance methods.
>> 
>> Some more work is needed on the decimal <-> binary conversion methods.
>
>> A few comments on the proposed revised API of Float16:
>> 
>> The Float16 class was generally brought up to static field and method level parity with java.lang.{Float, Double}. Additionally, a number of low-level floating-point handling methods from Math/StrictMath were added to, such as getExponent. These methods are usually an operation or recommended function from IEEE 754. Methods for arithmetic operators {+, -, *, /} and square root were also added. The value(short) method was changed from a bit-level conversion to a value-based one; bit-level conversion is provided by a new shortBitsToFloat16 method.
>> 
>> The current API favors static methods over instances one. Methods to extend the Number abstract class and implement Comparable are of necessity instance methods.
>> 
>> Some more work is needed on the decimal <-> binary conversion methods.
> 
> PS As a design note on the implementation, as many of the methods are expected to be intrinsified on common production platforms, I was looking to favor conciseness and code reuse, say by relying on float and double operations, rather than absolute performance for a native software-based implementation of Float16.

> Hi @jddarcy , Apart from few minor comments, patch looks good to me, there is a build error due to malformed javadoc comment.
> 
> Kindly fix and integrate.

Oops; sorry for the build breakage -- no change is no small that you shouldn't build before pushing ;-)

-------------

PR Comment: https://git.openjdk.org/valhalla/pull/1117#issuecomment-2163865948