On Tue, 22 Oct 2024 20:01:45 GMT, Paul Sandoz <psan...@openjdk.org> wrote:
>> Joe Darcy has updated the pull request with a new target base due to a merge
>> or a rebase. The incremental webrev excludes the unrelated changes brought
>> in by the merge/rebase. The pull request contains seven additional commits
>> since the last revision:
>>
>> - Add @since tag, respond to review feedback.
>> - Merge branch 'master' into JDK-8341260
>> - Remove comments for intrinsics per review feedback.
>> - Update with changes from lworld+fp16 Float16.
>> - Merge branch 'master' into JDK-8341260
>> - Add support for BigDecimal -> Float16 conversion.
>> - JDK-8341260: Add Float16 to jdk.incubator.vector
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line
> 690:
>
>> 688: // public int hashCode()
>> 689: // public static int hashCode(Float16 value)
>> 690: // public boolean equals(Object obj)
>
> I think we should add these methods in a subsequent PR. e.g., (although i may
> be ignorant of some details)
>
> @Override
> public int hashCode() {
> return Float16.hashCode(value);
> }
>
> public static int hashCode(float value) {
> return float16ToShortBits(value);
> }
>
> public static int float16ToShortBits(float value) {
> if (!isNaN(value)) {
> return float16ToRawShortBits(value);
> }
> return Float16.NaN;
> }
>
> public boolean equals(Object obj) {
> return (obj instanceof Float16)
> && (float16ToShortBits(((Float16)obj).value) ==
> float16ToShortBits(value));
> }
Hmm. Yes, adding at least explicit hashCode/equals methods from Object is
reasonable. Back when the type was in the Valhalla repo, I wasn't sure what the
recommended practice regarding Object methods vis a vis JEP 401/402.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811550800
