commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sai Zhang (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (MATH-553) Bug in class# org.apache.commons.math.dfp.Dfp / org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Date Thu, 18 Aug 2011 01:07:27 GMT

     [ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sai Zhang updated MATH-553:
---------------------------

    Comment: was deleted

(was: Hi Luc:

(sorry for the late reply. I thought my previous email was sent out, but found it 
still lies in my draft box)

I agree that  it does not make sense to compare 2 NaNs. However,  I think
two Java objects can still be compared, and the code maybe improved to
avoid violation of  the Java specification.

For the problem revealed in the test case, I suggest to fix this bug by adding a comparison
to 
*this* object itself. Doing so will avoid   "var.equals(var)" returns false. and prevent Java
containers becoming unstable, when they are containing a Dfp object.

A suggested fix is:

{code}
Class: org.apache.commons.math.dfp.Dfp

@Override
    public boolean equals(final Object other) {
          if(this == other) {
               return true;
          }
          ....// all existing code goes here
   }
{code}


For the other case, when comparing RealVector { 1, 0, 1 }  and {1, -0, 1},  it seems that
the equals method uses "numeric comparison" to conclude that  0 == -0. However,
when computing their hashcodes, the code implicitly treats "0" as an object, and use 
Arrays.hashcode to get the results (0, -0 are 2 different objects).

Therefore, I suggest to use a *consistent* way for comparison and computing hashcodes. It
is
completely feasible to fix the above problem. Here are 2 possible fixes:

1.  change the ArrayRealVector#equals, lines 1207 - 1211

{code}
for (int i = 0; i < data.length; ++i) {
        if (data[i] != rhs.getEntry(i)) {      //do not use numeric comparison, convert both
sides
          return false;                               //into Double type, and use Double.equals
to compare
        }
      }
{code}

2.  change the ways to compute hashcode in: ArrayRealVector#hashCode
    
Do not use {code}Arrays.hashCode(value);{code} to get hashcode, since it will implicitly
boxes each primitive values. Instead, use a method like below to compute hashcode numerically:

{code}
public static int hash(double[] value) {
        int retHashCode = 0;
        for(double v : value) {
             retHashCode +=  retHashCode*3 + 17*v;
        }
       return retHashCode;
    }
{code}

I think either way above will fix this problem (though it may be not that important), and
keep
the code behavior consistent!

Thanks

-Sai)

> Bug in class# org.apache.commons.math.dfp.Dfp / org.apache.commons.math.linear.RealVectorwith
reproducible JUnit test
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: MATH-553
>                 URL: https://issues.apache.org/jira/browse/MATH-553
>             Project: Commons Math
>          Issue Type: Bug
>    Affects Versions: 2.2
>         Environment: jdk 1.6
>            Reporter: Sai Zhang
>         Attachments: ApacheMath_Documented_Test.java
>
>
> Hi all:
> I am writing an automated bug finding tool, and using
> Apache Commons Math as an experimental subject
> for evaluation.
> The tool creates executable JUnit tests as well as
> explanatory code comments. I attached one bug-revealing
> test as follows. Could you please kindly check it, to
> see if it is a real bug or not?
> Also, it would be tremendous helpful if you could give
> some feedback and suggestion on the quality of generated code comments?
> From the perspective of developers who are familiar with the code,
> is the automatically-inferred comment useful in understanding
> the generated test? is the comment helpful in bug fixing from the
> perspective of developers?
> Particularly when the automatically-generated tests
> are often long.
> Your suggestion will help us improve the tool.
> Please see attachment for the failed test.
> The comment appears in the form of:
> //Tests pass if .... (it gives some small change to the test which can make the failed
test pass)
> For example:
> //Test passes if var10 is: (double)<0
> java.lang.Double var10 = new java.lang.Double(0.0d);
> means if you change var10 to a double value which is < 0 (e.g., -1d), the failed test
will pass

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message