commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] [Commented] (NUMBERS-60) Check Javadoc with respect to NaN
Date Wed, 14 Feb 2018 10:33:02 GMT


Gilles commented on NUMBERS-60:

I've just look back into history, to figure out that I raised the same question years ago.
Could you please add a comment in the code to the effect that the inconsistency between the
math and the implementation is assumed (and the reason why it is so if you have it from the
C99 specs)?  Thanks a lot.

> Check Javadoc with respect to NaN
> ---------------------------------
>                 Key: NUMBERS-60
>                 URL:
>             Project: Commons Numbers
>          Issue Type: Task
>          Components: complex
>            Reporter: Gilles
>            Priority: Minor
>              Labels: API, javadoc
>             Fix For: 1.0
> See e.g. the doc for method {{negate}}:
> {code}
> /**
>  * Returns a {@code Complex} whose value is {@code (-this)}.
>  * Returns {@code NaN} if either real or imaginary
>  * part of this complex number is {@code Double.NaN}.
>  *
>  * @return {@code -this}.
>  */
> public Complex negate() {
>     return new Complex(-real, -imaginary);
> }
> {code}
> The "NaN" advertized in the the Javadoc seems to refer to the {{Complex.NaN}} field,
but {{negate}} is able to construct instances for which the contract of method {{equals(Object)}}
will be broken.
> As a related issue, I would make the {{NaN}} field "private" (and rename it "NAN" to
avoid the CheckStyle warning); users who need to check for (any combination of) NaN should
use the {{isNaN()}} method.

This message was sent by Atlassian JIRA

View raw message