[
https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866111#action_12866111
]
Gilles commented on MATH-370:
-----------------------------
OK, maybe it is not necessary to introduce a new package.
Then, let's implement the proposed name change ("equalsIncludingNaN").
> Note that the <double, double, double> and <double, double, int> versions are
> also "different" from the JDK;
> but there is no possibility for confusion of intent for them.
I do not agree. The point is there will be a confusion because the JDK treats
"Double" and "double" _differently_ wrt NaN whereas those "equals" methods
handle NaN _similarly_ to what happens with "Double".
In my (maybe naive) opinion, all this NaN business is not really important
because the equality test itself doesn't make sense when a NaN is passed as
arguments (meaning something went wrong previously).
However, there is this IEEE754 _standard_ saying that NaN is not equal to NaN.
Hence, to avoid confusion, the "equals" methods should comply with it. And,
for all of them, we can add the special-purpose variant in the longer-named
ones.
Agreed?
[If so, I'm willing to make the changes and hunt for all the occurrences of
"equals" with the current semantics and replace them with "equalsIncludingNaN".]
> 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.
