On Wed, 23 Oct 2024 00:53:57 GMT, Chen Liang <li...@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
> 60:
>
>> 58: * either {@link Float}/{@link Double} or {@link Math}/{@link
>> 59: * StrictMath}. Unless otherwise specified, the handling of special
>> 60: * floating-point values such as {@linkplain #isNaN(Float16) NaN}
>
> That said, and given Float has "equivalenceRelation" and
> "decimalToBinaryConversion" anchors, do we need similar anchors here that
> redirects to the Double ones?
Reasonable suggestion; I'll put the same kind of pointers into java.lang.Double
sections as java.lang.Float has.
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line
> 405:
>
>> 403: * @return the {@code Float16} value represented by the string
>> 404: * argument.
>> 405: * @throws NullPointerException if the string is null
>
> Should we move this NPE clause to the class specification, i.e. `Unless
> otherwise specified, all methods in this class throw {@code
> NullPointerException} when passed a {@code null}`? I think this applies to
> the APIs taking `BigDecimal` and static methods taking `Float16`. (Note we
> need to explicitly exclude `equals`)
Hmm. I'm trying to keep parity between Float16 and java.lang.{Float, Double}.
Float/Double don't include the class-level statement so I wouldn't include on
in Float16 until they do. Writing Float16 has prompted several other
improvements to Float/Double, so a null-handling statement is something worth
considering.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813577592
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1813570930
