# commons-issues mailing list archives

##### Site index · List index
Message view
Top
From "Phil Steitz (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-632) NaN: Method "equals" in Complex not consistent with "==" for "double" primitive type
Date Tue, 26 Jul 2011 20:14:10 GMT
```
[ https://issues.apache.org/jira/browse/MATH-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13071329#comment-13071329
]

Phil Steitz commented on MATH-632:
----------------------------------

Complex is an object, so has to have an equals implementation that is reflexive, symmetric
and transitive.  Do you have an alternative implementation in mind?  And an explanation of
why the alternative is better?

My reference to collections comes from my own use in simulating complex dynamical systems.
Like floating point equals comparisons among doubles, I don't use Complex.equals much, and
when I do it is either in test code or comparing results of divergent processes.  When processes
diverge, it is convenient to be able to compare results wrt infinities and NaNs.  In that
case, it is convenient to have equals return true for NaNs.

> NaN: Method "equals" in Complex not consistent with "==" for "double" primitive type
> ------------------------------------------------------------------------------------
>
>                 Key: MATH-632
>                 URL: https://issues.apache.org/jira/browse/MATH-632
>             Project: Commons Math
>          Issue Type: Bug
>            Reporter: Gilles
>            Priority: Minor
>             Fix For: 3.0
>
>
> The following tests show several contradictions:
> {code}
> final double a = Double.NaN;
> final double b = Double.NaN;
> Assert.assertFalse("a == b", a == b); // (1)
> Assert.assertEquals("a != b", a, b, Double.MIN_VALUE); // (2)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (3)
> Assert.assertFalse("a == b", MathUtils.equals(a, b, Double.MIN_VALUE)); // (4)
> final Double dA = Double.valueOf(a);
> final Double dB = Double.valueOf(b);
> Assert.assertFalse("dA == dB", dA.doubleValue() == dB.doubleValue()); // (5)
> Assert.assertTrue("!dA.equals(dB)", dA.equals(dB)); // (6)
> final Complex cA = new Complex(a, 0);
> final Complex cB = new Complex(b, 0);
> Assert.assertTrue("!cA.equals(cB)", cA.equals(cB));  // (7)
> {code}
> They all pass; thus:
> # "Double" does not behave as "double": (1) and (5) vs (6)
> # Two NaNs are almost equal for Junit: (2)
> # Two NaNs are never equal for MathUtils: (3) and (4)
> # Complex.NaN is consistent with Object "Double.valueOf(NaN)" (hence not with primitive
"Double.NaN"): (7)
> This is quite confusing.
> In MathUtils, we chose to follow IEEE754 (and Java for primitive "double"), i.e. it is
"correct" that assertion (1) is false. Do we want "Complex" to conform with this or with the
inconsistent behaviour of "Double"?

--
This message is automatically generated by JIRA.