On Tue, 7 Jul 2026 16:51:45 GMT, Paul Sandoz <[email protected]> wrote:
>> Currently Float16Vector.toString prints raw short values from the backing
>> storage, i.e. the IEEE 754 binary16 bit encodings. Patch uses
>> Float16.toString routine to print the lane values in more user-friendly
>> human-readable floating-point format.
>> In addition, the various bit representations of NaN are canonicalized so
>> that such lanes are simply printed as "NaN". Float16.toString API renders
>> each lane as a human-readable floating-point value and prints canonical text
>> ("NaN",
>> "Infinity", "-0.0")
>>
>> Kindly review and share your feedback.
>>
>> Best Regards,
>> Jatin
>>
>> ---------
>> - [x] I confirm that I make this contribution in accordance with the
>> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai).
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java
> line 3716:
>
>> 3714: * produces a human-readable floating-point value and canonical
>> text
>> 3715: * for special values (for example {@code "NaN"} and {@code
>> "Infinity"})
>> 3716: * regardless of the underlying bit encoding.
>
> It occurred to me there is a simpler way;
>
> * The string is produced as if by a call to {@link
> * java.util.Arrays#toString(double[]) Arrays.toString()},
> * as appropriate to the {@code double} array returned by
> * {@link #toArray this.toDoubleArray()}.
> ```
> Internally we can reuse `toFloat16Array`, but you can also use
> `toDoubleArray`, they should be equivalent. @jddarcy can you confirm this is
> the case?
@PaulSandoz Yes, the note by @jddarcy is correct, and the proposal by
@jatin-bhateja makes much more sense than using `double`s for the purpose of
this PR.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31800#discussion_r3543049343
