On Mon, 8 Jun 2026 18:30:19 GMT, Paul Sandoz <[email protected]> wrote:
>>> @jatin-bhateja In that regard: the Vector API still has lots of unrelated >>> bugs, but that should not block you here. But: those JDK27 bugs have higher >>> priority for us. >>> >>> The 3 related issues: are all bugs in the fuzzer changes, of the companion >>> PR. We'll have to fix those issues there. >>> >>> But so far, I think testing has not revealed any issues with this PR here. >> >> Hi @eme64 , >> Thanks for a very thorough testing and filing the bugs. >> As discussed I will work on the feedback on fuzzer pull request seperately. >> >> May I request you to kindly approve this pull request, we may also need >> reapproval from @PaulSandoz or @xuemingshen-oracle >> >> Best Regards >> Jatin > >> @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. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4663455047
