commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <>
Subject [jira] Commented: (MATH-370) NaN in "equals" methods
Date Tue, 11 May 2010 09:52:42 GMT


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

[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:
>             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.

View raw message