On Tue, 7 Jul 2026 04:50:56 GMT, Jatin Bhateja <[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?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31800#discussion_r3538226868
