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`? Are ok with pushing this PR despite this, and without specific any testing for it? Who will be responsible to keep track of this, and fixing it, after the integration? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-4656315566
