[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Resolved] (NUMBERS-60) Check Javadoc with respect to NaN
From:       "Eric Barnhill (JIRA)" <jira () apache ! org>
Date:       2018-04-30 10:43:00
Message-ID: JIRA.13135756.1517573680000.14147.1525084980094 () Atlassian ! JIRA
[Download RAW message or body]


     [ https://issues.apache.org/jira/browse/NUMBERS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel \
]

Eric Barnhill resolved NUMBERS-60.
----------------------------------
    Resolution: Fixed

The NaN issue was resolved and the multiplication / division issue was moved to \
another ticket.

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


[prev in list] [next in list] [prev in thread] [next in thread]