Uploaded image for project: 'Commons Math'
  1. Commons Math
  2. MATH-632

NaN: Method "equals" in Complex not consistent with "==" for "double" primitive type

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Minor
    • Resolution: Not A Problem
    • None
    • 3.0
    • None
    • None

    Description

      The following tests show several contradictions:

      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)
      

      They all pass; thus:

      1. "Double" does not behave as "double": (1) and (5) vs (6)
      2. Two NaNs are almost equal for Junit: (2)
      3. Two NaNs are never equal for MathUtils: (3) and (4)
      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"?

      Attachments

        Activity

          People

            Unassigned Unassigned
            erans Gilles Sadowski
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: