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-632) NaN: Method "equals" in Complex not consistent with "==" for "double" primitive type
Date Wed, 27 Jul 2011 09:45:09 GMT

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

Gilles commented on MATH-632:
-----------------------------

{quote}
The javadoc for equals in Colt's Complex (implemented the same way we do) points out that
implementing equals this way makes Complex instances work correctly in hashtables.
{quote}

Actually they probably copied the similar comment from [here|http://download.oracle.com/javase/6/docs/api/java/lang/Double.html#equals(java.lang.Object)].
:)

I'm convinced that the ambiguity (Object/primitive) cannot be lifted, and I probably should
not worry anymore that CM is not more consistent than Java itself...

As Sebb mentions, one should not search the archive to get an explanation for such seemingly
contradictory behaviour. It suffices to say that we follow IEEE754 for "MathUtils.equals"
and that we don't for _any_ "Object" even though it would represent a (tuplet of) real numbers,
on a par with what Java does.


> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message