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