You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Gilles (JIRA)" <ji...@apache.org> on 2010/05/07 13:33:48 UTC
[jira] Created: (MATH-370) NaN in "equals" methods
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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865724#action_12865724 ]
Phil Steitz commented on MATH-370:
----------------------------------
I use the equals method and the array version in some of my code that uses [math] (pretty much the same basic use case as above) and I suspect it is possible that other users do as well, so I would prefer to keep a renamed version of it available publicly, if consensus is we need to rename it. The fact that it is defined at all should be a flag to users that there is something different going on, at least in the <double, double> case. 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.
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865171#action_12865171 ]
Luc Maisonobe commented on MATH-370:
------------------------------------
I really think this is intentional and the fact that NaN != Nan was known to the people who did that.
For example, the javadoc for Complex.equals ([http://commons.apache.org/math/apidocs/org/apache/commons/math/complex/Complex.html#equals%28java.lang.Object%29]) explicitly warns about behavior for NaN.
So on the one one changing this would break compatibility with respect to a documented behavior and on the other hand it would bring compatibility with IEEE arithmetic.
I'm sure there is a good reason for the current status, but I don't know it.
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866129#action_12866129 ]
Gilles commented on MATH-370:
-----------------------------
> I see no reason to change the names or modify the behavior of any of the other equals methods in MathUtils.
Maybe because the other "equals" methods also consider that NaN == NaN which contradicts IEEE !
Where people need to treat all NaN values as equal, they will use one of the "equalsIncludingNaN", otherwise they will use one of the "equals" methods (and get an IEEE754-compliant result wrt to NaN values).
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865443#action_12865443 ]
Gilles commented on MATH-370:
-----------------------------
But _why_?
By this I mean, how to explain to someone that CM does not comply with IEEE?
Also, please point me to the internal things likely to break, so that I have a chance to understand the usefulness of the behaviour.
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866120#action_12866120 ]
Phil Steitz commented on MATH-370:
----------------------------------
I am fine with deprecating and changing the name of MathUtils.equals(double, double) to "equalsIncludingNaN" or "equalsN". I see no reason to change the names or modify the behavior of any of the other equals methods in MathUtils.
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12877041#action_12877041 ]
Gilles commented on MATH-370:
-----------------------------
Changes partially implemented in r952949. [Hopefully not breaking compatibility.]
Methods "equalsIncludingNaN" have been added and used internally (in the classes of the "stat.descriptive" package) instead of the now deprecated "equals" methods. Those should change semantics in release 3.0.
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866321#action_12866321 ]
Gilles commented on MATH-370:
-----------------------------
Actually, I think that the first of the above "equals" should be replaced by:
{code}
public static boolean equals(double x, double y) {
return equals(x, y, 1);
}
{code}
I.e. calling the fourth form (when it is replaced by the IEEE-compliant version).
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865468#action_12865468 ]
Phil Steitz commented on MATH-370:
----------------------------------
The method Mathutils.equals(double, double) was implemented for the reason that in some cases, users may wish to treat doubles with NaN values as equal. The internal classes that use it are the equals methods for statistics and statistical aggregates. When these classes were defined, we decided that we would treat two statistics or statistical aggregates as equal iff they had the same values, including NaNs. So for example, two StatisticalSummaryValues instances are equal iff they report the same values for all statistics, with NaNs treated as "the same value." The MathUtils.equals(double, double) method was introduced as a convenience method to do this kind of comparison. I guess we could (deprecate and) change the name if it makes it look like all of our computations are defining equals that way, which is certainly not the case. In general, we do try to follow IEEE754. We agreed early on that we would carefully document how NaNs are treated throughout Commons Math. We have slipped a little over the years, but in the case of this method and the classes that use it, the documentation is clear.
Sorry I misunderstood the point of the issue here. I now get your point that naming the method "equals" makes it look like we are re-defining equals for primitive doubles, which is not our intent. So maybe we deprecate the equals method and rename something like "equalsIncludingNaN" or something simpler?
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865236#action_12865236 ]
Gilles commented on MATH-370:
-----------------------------
The Javadocs for "Float" and "Double" also indicate the special behaviour for NaN in a number object. Nevertheless, the _primitive_ types are compliant with IEEE. Hence, there is an inconsistency between the "equals" methods in "MathUtils" and the behaviour of the JVM.
> 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.
[jira] Resolved: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gilles resolved MATH-370.
-------------------------
Assignee: Gilles
Fix Version/s: 3.0
Resolution: Fixed
Revision 991535.
> NaN in "equals" methods
> -----------------------
>
> Key: MATH-370
> URL: https://issues.apache.org/jira/browse/MATH-370
> Project: Commons Math
> Issue Type: Bug
> Reporter: Gilles
> Assignee: Gilles
> Priority: Minor
> Fix For: 3.0
>
>
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865376#action_12865376 ]
Phil Steitz commented on MATH-370:
----------------------------------
-1 for the change. It will break some internal things and likely some user applications that depend on the documented behavior. The reason that these methods exist is to be able to handle NaNs and treat them as equal.
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12870395#action_12870395 ]
Phil Steitz commented on MATH-370:
----------------------------------
Regarding equals(double, double), it looks like what you are proposing is yet another version of equals that is not exactly what is defined in the spec. Do I have that right? In that case, like the current version, it should have a different name. Or does the spec imply that equals should behave this way and the JDK not quite deliver it?
I sympathize with the desire to change the definitions of the other methods now; but while we did not quite live up to this in 2.1, .x versions are supposed to be drop-in replacements, so we should not be changing behavior of methods unless they are not meeting their documented contracts and in this case, what we are seeing as "bugged" are the contracts, so I think we need to deprecate equals(double, double) and fix the others in 3.0, with the exception of equals(double, double, int), which does not specify NaN behavior. We can introduce the new "equalsN" versions now and note the changed behavior in the javadoc for the "equals" versions. We can also introduce the new version of equals(double, double) that you are describing with a new name.
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866296#action_12866296 ]
Gilles commented on MATH-370:
-----------------------------
{code}
public static boolean equals(double x, double y) {
return (Double.isNaN(x) && Double.isNaN(y)) || x == y;
}
{code}
{code}
public static boolean equals(double x, double y, double eps) {
return equals(x, y) || (Math.abs(y - x) <= eps);
}
{code}
{code}
public static boolean equals(double[] x, double[] y) {
if ((x == null) || (y == null)) {
return !((x == null) ^ (y == null));
}
if (x.length != y.length) {
return false;
}
for (int i = 0; i < x.length; ++i) {
if (!equals(x[i], y[i])) {
return false;
}
}
return true;
}
{code}
{code}
public static boolean equals(double x, double y, int maxUlps) {
// Check that "maxUlps" is non-negative and small enough so that the
// default NAN won't compare as equal to anything.
assert maxUlps > 0 && maxUlps < NAN_GAP;
long xInt = Double.doubleToLongBits(x);
long yInt = Double.doubleToLongBits(y);
// Make lexicographically ordered as a two's-complement integer.
if (xInt < 0) {
xInt = SGN_MASK - xInt;
}
if (yInt < 0) {
yInt = SGN_MASK - yInt;
}
return Math.abs(xInt - yInt) <= maxUlps;
}
{code}
The first assumes that NaN == NaN; the next two use the first; the last one also returns {{true}} when both arguments are NaN.
I propose that these "equals" will return {{false}} when one or the other argument is NaN (or contains a NaN for the array variant), and to create for each one an "equalsIncludingNaN" variant that will behave as the current code of "equals".
All occurrences of "equals" currently in CM will be replaced by "equalsIncludingNaN" so that no semantics change will happen.
CM will stay consistent and be compliant.
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12866253#action_12866253 ]
Phil Steitz commented on MATH-370:
----------------------------------
Which methods exactly are you talking about?
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865720#action_12865720 ]
Gilles commented on MATH-370:
-----------------------------
Well, the first impression I got from looking at those methods in "MathUtils" was indeed that they provide the "right" way to compare primitive doubles. Now, the right way for most users dealing with numerical codes should arguably be IEEE754-compliant. So, unless we can explain that the way CM handles NaN is somehow more useful than what the IEEE standard defines, CM should at least provide "equals" utility methods that stick to the standard.
I understand the usefulness of the current implementation in the examples which you gave, but as a matter of principle this usage is second in priority (from a user perspective): it is mainly internal to CM.
Maybe, we should create a "util.internal" package where (CM) developer-utilities methods would live, whereas "util" would contain the functions which users are most likely looking for. I think that it would be clearer (e.g. it would avoid dealing with long names such as "equalsIncludingNaN"). What do you think?
> 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (MATH-370) NaN in "equals" methods
Posted by "Gilles (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12865729#action_12865729 ]
Gilles commented on MATH-370:
-----------------------------
I did not say that there should be private methods, unavailable to users of CM. Just that different packages would make it clear that some methods intend to implement common/standard functions while others are more special-purpose or could deviate from standard definitions.
> 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.