commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <>
Subject [jira] Commented: (MATH-370) NaN in "equals" methods
Date Sun, 23 May 2010 13:47:16 GMT


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