[jira] [Comment Edited] (NUMBERS-60) Check Javadoc with respect to NaN
[
https://issues.apache.org/jira/browse/NUMBERS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16363665#comment-16363665
]
Eric Barnhill edited comment on NUMBERS-60 at 2/14/18 9:10 AM:
---
{code:java}
final double c = divisor.real;
final double d = divisor.imaginary;
if (c == 0 && d == 0) { return NAN; }
{code}
This is the first block of code, put in to conform to C99. I think it is
pretty failsafe.
was (Author: ericbarnhill):
{code:java}
if (c == 0 && d == 0) { return NAN; }
{code}
This is the first block of code, put in to conform to C99. I think it is
pretty failsafe.
> 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)
[jira] [Comment Edited] (NUMBERS-60) Check Javadoc with respect to NaN
[
https://issues.apache.org/jira/browse/NUMBERS-60?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16360583#comment-16360583
]
Eric Barnhill edited comment on NUMBERS-60 at 2/12/18 10:53 AM:
This is actually a broader issue, there are multiple references to NaN in the
javadoc that need to be altered. EDIT: actually the title of the issue reflects
this fine.
was (Author: ericbarnhill):
This is actually a broader issue, there are multiple references to NaN in the
javadoc that need to be altered.
> 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)
