Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 25 Jul 2011 02:45:09 +0000 (UTC)
From: "Phil Steitz (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <707576672.2693.1311561909507.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1322382830.2432.1311543501723.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (MATH-632) NaN: Method "equals" in
 Complex not consistent with "==" for "double" primitive type
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Phil Steitz edited comment on MATH-632 at 7/25/11 2:44 AM:
-----------------------------------------------------------

Can anyone present a practical argument for changing the current documented behavior of Complex.equals?  There is no perfect solution here, given the way equals is defined for doubles in Java.  The current behavior is simple, well-documented and has been defined this way since version 1.0.  Changing it may break some code that depends on it, so we need to have good practical reasons to change. 

>From my perspective, the current implementation of Complex equals, which is consistent with what we also do for ArrayRealVectors, is natural and convenient.  I don't see the examples as particularly relevant, since a Complex instance is not a pair of doubles, but an object that has two double-valued attributes. Once a Complex number has a NaN part, it is for all practical purposes NaN, so it makes sense to lump all instances with NaN parts into one equivalence class modulo equals.  IIRC, this was the rationale used to define the current implementation of Complex equals.   

      was (Author: psteitz):
    Can anyone present a practical argument for changing the current documented behavior of Complex.equals?  There is no perfect solution here, given the way equals is defined for doubles in Java.  The current behavior is simple, well-documented and has been defined this way since version 1.0.  Changing it may break some code that depends on it, so we need to have good practical reasons to change. 
  
> 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