On Tue, 22 Oct 2024 23:13:26 GMT, Joe Darcy <da...@openjdk.org> wrote:
>> 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.
Pushed equals/hashCode implementations. One slightly subtle point: the bit
pattern for the "canonical" NaN is not defined. At runtime, the bit pattern of
Float16.NaN is used for that purpose. Also, the exact bits returned for hashing
is not defined, although I think it would be reasonable to add a requirement
that "all distinct Float16 values have distinct hash codes."
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1811592134
