[
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
