On Wed, 23 Oct 2024 12:53:20 GMT, Raffaello Giulietti <rgiulie...@openjdk.org>
wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add equals/hashCode implementation; tests to follow.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line
> 708:
>
>> 706: public static int hashCode(Float16 value) {
>> 707: Float16 f16 = isNaN(value) ? Float16.NaN : value;
>> 708: return (int)float16ToRawShortBits(f16);
>
> What about randomizing the returned value? IIUC, JEP 401 does not speak
> against.
> The purpose would not be to conceal anything, but to ensure that clients
> cannot rely on specific values.
>
>
> private static final int HASH_MASK =
> RandomGenerator.getDefault().nextInt();
>
> /**
> * Returns a hash code for a {@code Float16} value; compatible with
> * {@code Float16.hashCode()}.
> *
> * @param value the value to hash
> * @return a hash code value for a {@code Float16} value.
> */
> public static int hashCode(Float16 value) {
> Float16 f16 = isNaN(value) ? Float16.NaN : value;
> int bits = float16ToRawShortBits(f16);
> return (bits << 16 | bits & 0xFFFF) ^ HASH_MASK;
> }
Hmm. Certainly at this point, I don't think hash randomization is necessary;
although it might be helpful at a later point. Set.of() uses randomized
iteration order as a precedent in that direction.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813063677
