RFR: 8341260: Add Float16 to jdk.incubator.vector [v3]
Joe Darcy
darcy at openjdk.org
Wed Oct 23 00:25:07 UTC 2024
On Tue, 22 Oct 2024 23:13:26 GMT, Joe Darcy <darcy at 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
More information about the core-libs-dev
mailing list