You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sai Zhang (JIRA)" <ji...@apache.org> on 2011/04/03 10:12:05 UTC
[jira] [Created] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
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?
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
[jira] [Updated] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Sai Zhang (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015214#comment-13015214 ]
Luc Maisonobe commented on MATH-553:
------------------------------------
Yes, I think these comments are helpful.
They give an hint about what to look at. In both cases, I add to run the test in a debugger to see exactly what happened but the comment showed me exactly the variable to look at. I don't know how you generate these comments, would it be possible to have both the information about the values that make the test pass and the value that did make the test fail ? This would allow the reader to simply compare these values without having to run a debugger by himself. If this is not possible, the current comments already provide valuable information.
> 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
[jira] [Resolved] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Luc Maisonobe resolved MATH-553.
--------------------------------
Resolution: Not A Problem
Apart from Sebb comments on COLLECTIONS-374, here are a few additional comments for math.
The test is targeted at 2.2 which will probably be the last version in the 2.X series. In this series, we used a mix of Junit 3 and Junit 4 tests. The current code in the trunk for 3.0 has completely switched to Junit 4. It would be nice to have Junit 4 tests rather than Junit 3 tests.
In math, we use a lot of double primitive variables. What about replacing the java.lang.double objects to primitive doubles (and similarly for other primitives types), this would help read the tests.
The failing test for var87.equals(var87) is a false positive. This is a very specific feature of real numbers, some special numbers called NaN (which stands for Not A Number) are equals to nothing, including themselves. So var87.equals(var87) must return false for a NaN. In fact, all boolean predicates on NaN must fail, so if you have two NaNs a and b, the predicates a == b, a != b, a < b, a <= b, a > b, a >= b are ALL false!
This is very specific and I don't expect an automatic tool to be aware of this. Also having a way to configure the tool for such a rare case would really be overkill.
So this bug is in fact not a bug.
> 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
[jira] [Commented] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Sai Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086718#comment-13086718 ]
Sai Zhang commented on MATH-553:
--------------------------------
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
[jira] [Commented] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Luc Maisonobe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015206#comment-13015206 ]
Luc Maisonobe commented on MATH-553:
------------------------------------
Test1 one is another strange feature of IEEE754 arithmetic. There are two different encodings for 0: +0 and -0 (i.e. in IEEE754 standard, the sign of 0 is meaningful). Most of the time, -0 and +0 cannot be distinguished, and they evaluate as equals (this is the reason why var19.equals(var44) returns true). However, they do not correspond to the same encoding. -0.0 is encoded as 0x8000000000000000 whereas +0.0 is encoded as 0x0000000000000000 (the most significant bit is the sign bit). This implies that these values are equal but do not have the same hash code.
In your case, var19 is an array containing { 1, 0, 1 }, it was obtained by raising the same numbers to the power 100, which did not affect their sign. On the other hand, var44 is an array containing { 1, -0, 1 }, it was obtained by dividing { -1, 0, -1 } by -1, and this changed all signs, including the sign of the central 0. Hence both arrays contain equals elements, but their hash code are different due to the central element.
This behavior is also produced by the following code:
{code}
double a = Math.pow(0.0, 100.0);
double b = 0.0 / -1.0;
System.out.println(a == b);
System.out.println("0X" + Long.toHexString(Double.doubleToLongBits(a)));
System.out.println("0X" + Long.toHexString(Double.doubleToLongBits(b)));
{code}
which displays:
{code}
true
0X0
0X8000000000000000
{code}
So test1 is not a bug either.
These two cases are not the only ones to be strange in double arithmetic. There are also encodings for infinity (plus and minus infinity) and there are subnormal numbers (which are almost like standard numbers, only with decreasing accuracy as the numbers vanish towards 0).
> 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
[jira] [Commented] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Sai Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015199#comment-13015199 ]
Sai Zhang commented on MATH-553:
--------------------------------
Thanks Luc.
Seems there is a contradiction between mathematical equality and Java object
equality. OK, I understand
that is very special case.
Could you please check the other test "test1()", to see if it is a real bug?
-Sai
--
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
[jira] [Commented] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Sai Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015209#comment-13015209 ]
Sai Zhang commented on MATH-553:
--------------------------------
Thanks Luc for your detailed explanation. It makes me much clearer on these
cases.
We will carefully consider your suggestion into the design of our tool.
As I mentioned in the post, another feature of this tool is trying to infer
descriptive code
comments to explain failure, could you please kindly give us some comments
on
such generated comments? like:
//Test passes if var10 is: (double)<0
java.lang.Double var10 = new java.lang.Double(0.0d);
>From the viewpoint of developers, do you think such comment is useful for
debugging?
Particularly, if the automatically-generated test itself is long and does
not have good readability. Can such
comment be used as a good start point of diagnose? We would like to hear
developers'
voice and feedback on such code enhancement, to decide whether to improve
along
that line. (of course, you are already very familiar with the code base,
and may identify
the failure cause by simply look at the execution trace and assertions.But
intuitively,
we think such comments might be helpful for junior developers)
Thanks a lot. Really appreciate your reply!
> 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
[jira] [Updated] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Sai Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sai Zhang updated MATH-553:
---------------------------
Description:
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
was:
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?
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
> 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
[jira] [Commented] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Sai Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13086717#comment-13086717 ]
Sai Zhang commented on MATH-553:
--------------------------------
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
--
Sai Zhang
http://www.cs.washington.edu/homes/szhang/
> 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
[jira] [Commented] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Sai Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13015221#comment-13015221 ]
Sai Zhang commented on MATH-553:
--------------------------------
Thanks Luc for your comments.
I used a statistical algorithm to summarize the properties of a set of
"failure-correcting" objects. A technical report
describing the technique is on its way.
Yes, it is possible to have both an example value which make the test pass
(we have already implemented it
in our tool). For the reported test, the generated comment is: (after
appending an example value):
//Test passes if var10 is: (double)<0, for example, -1.0d
java.lang.Double var10 = new java.lang.Double(0.0d);
The value making the test fail is already shown in the test (var10 = 0.0d in
the above test).
--
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
[jira] [Updated] (MATH-553) Bug in class#
org.apache.commons.math.dfp.Dfp /
org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
Posted by "Sai Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/MATH-553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sai Zhang updated MATH-553:
---------------------------
Attachment: ApacheMath_Documented_Test.java
> 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?
> 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