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 Mon, 12 Feb 2018 15:12:00 GMT


Gilles commented on NUMBERS-60:

I agree {{Complex.ONE}} and {{Complex.ZERO}} but I worry that {{Complex.NAN}} gives the impression
that an equality test with it can be performed.
The instance is used in unit tests but what other uses do you see?
I'd prefer to make it {{private}} until a use-case shows that it is really needed.
Sparing one object instantiation in the unit test class is not enough to justify an ad-hoc

> 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