[ https://issues.apache.org/jira/browse/NUMBERS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360647#comment-16360647 ]
Eric Barnhill commented on NUMBERS-60: -------------------------------------- I think the reason NAN is public is because Complex.ZERO and Complex.ONE are very useful constants that I have called many times to construct a new complex. Perhaps Complex.NAN is less useful to call publicly, but I can imagine uses for it. > 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)