[
https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12867900#action_12867900
]
Phil Steitz commented on MATH-370:
----------------------------------
Looking carefully at the uses inside [math] and reviewing my own uses, I agree
now that the original definitions of equals(double, double) and equals(double,
double, double) were incorrect, or I guess I should say "unfortunate."
Regarding equals(double, double), I don't see why we need that at all - just
deprecate and replace by "equalsN" or somesuch or remove it altogether in 3.0.
The uses of equals(double, double, double) in the linear package should NOT
identify NaNs, so these would benefit from changing behavior. The uses in the
stats package of the array version are OK, I think - i.e., I think it is a
legitimate definition of equals for a stats reporting object to identify stats
that report NaNs in the same places.
So the question is what to do. I don't think we can change the contracts or
delete methods in point releases, so the reasonable thing to do is to
1) deprecate equals(double, double)
2) Make a note in the javadoc for equals(double[], double[]) and equals(double,
double, double) indicating that in version 3.0 these methods will handle NaNs
differently.
3) Fix equals(double, double, int). This method does not use equals(double,
double) and does not specify how NaNs are handled in its javadoc, so it can be
fixed.
> NaN in "equals" methods
> -----------------------
>
> Key: MATH-370
> URL: https://issues.apache.org/jira/browse/MATH-370
> Project: Commons Math
> Issue Type: Bug
> Reporter: Gilles
> Priority: Minor
>
> In "MathUtils", some "equals" methods will return true if both argument are
> NaN.
> Unless I'm mistaken, this contradicts the IEEE standard.
> If nobody objects, I'm going to make the changes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
