commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (JIRA)" <j...@apache.org>
Subject [jira] Commented: (MATH-370) NaN in "equals" methods
Date Thu, 20 May 2010 09:58:55 GMT

    [ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12869542#action_12869542
] 

Gilles commented on MATH-370:
-----------------------------

> [...] Regarding equals(double, double), I don't see why we need that at all [...]

As I noted in the previous comment, this version of an equality test seems to make sense,
from a numerical perspective, if it's implemented by using the "equals(double,double,int)"
method (introduced according to [MATH-264|https://issues.apache.org/jira/browse/MATH-264])
where the third argument is set to 1): It means that there is no floating point number in
the range of real numbers defined by the first and second arguments.

Practically, I've now modified all the "equals" methods (so that NaN != NaN) and for each
one, I've also implemented an "equalsIncludingNaN" version (for which NaN == NaN).
In the "stat" package, wherever "equals" was used, I replaced it with "equalsIncludingNaN".
I modified the junit tests ("mutatis mutandis") and they all pass.

I don't think it's worth waiting v3.0 to introduce those changes, for the following reasons:
# The change is non-breaking wrt usage of the code in package "stat", or any other code that
was using "equals".
# No functionality is removed (i.e. the "equalsIncludingNaN" provide the same behaviour as
previously provided by the corresponding "equals" methods).
# For a direct user of "equals", the change is, in principle, breaking but only in the single
case where he relies on NaNs being equal. How likely is it that expecting such a behaviour
is *not* wrong (i.e. comparing the results of computations that produced meaningless values)?

To further alleviate the (marginal) risk of the last point, couldn't we make a poll on the
"user" ML, so that people can make a case if they really need the time to a major version
change in order to adapt to this modification?


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


Mime
View raw message