On Tue, 9 Jun 2026 19:50:00 GMT, Paul Sandoz <[email protected]> wrote:
>>> @jatin-bhateja @PaulSandoz I suppose it is consistent: `toString`, >>> `toArray` etc all produce `short[]` style results. It's not very nice to >>> read when you see it first, but I suppose one can always do the conversion >>> to float manually. >> >> Yes, when the lane elements are exposed they are done so as `short` values >> that hold float 16 binary values. >> >> I propose we revisit `toString` after this PR, arguably it should be more >> friendly and print out the lane elements as floating point numbers. Also >> after this PR we need revisit `hashCode`, since there is the edge case of >> dealing with `NaN` values and we need to canonicalize them e.g., as in >> `Float16.float16ToShortBits(Float16.shortBitsToFloat16(s))` > >> @PaulSandoz Right. So `toString` and `hashCode` would currently behave >> non-deterministically, given NaN encoding. That does not seem ok, right? How >> does it behave with `equals`? > > Equals should be fine, since the implementation defers to > `VectorOperators.EQ`, but we could also add a non-smoke test for that using > non-canonical signaling NaNs. > >> Are you ok with pushing this PR despite this, and without specific any >> testing for it? > > Yes, as long as we follow up in 28 after integration of this PR. I think it > better not to further perturb this PR for these edge case issues. > >> Who will be responsible to keep track of this, and fixing it, after the >> integration? > > Jatin has assigned himself to https://bugs.openjdk.org/browse/JDK-8370691. I > updated the issue and targeted it to 28. We need another issue to track > `toString`, which will require a small CSR update due to the specification. Thanks @PaulSandoz , @XiaohongGong , @eme64 , @xuemingshen-oracle for review and approvals. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4676784748
