commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eric Barnhill (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (NUMBERS-60) Check Javadoc with respect to NaN
Date Mon, 12 Feb 2018 12:00:00 GMT

    [ 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)

Mime
View raw message