[ 
https://issues.apache.org/jira/browse/NUMBERS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360852#comment-16360852
 ] 

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 API.

> Check Javadoc with respect to NaN
> ---------------------------------
>
>                 Key: NUMBERS-60
>                 URL: https://issues.apache.org/jira/browse/NUMBERS-60
>             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
(v7.6.3#76005)

Reply via email to