Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Sun, 3 Apr 2011 20:28:05 +0000 (UTC)
From: "Luc Maisonobe (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: 
 <119340857.31453.1301862485930.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <660979382.31009.1301818325758.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (MATH-553) Bug in class#
 org.apache.commons.math.dfp.Dfp /
 org.apache.commons.math.linear.RealVectorwith reproducible JUnit test
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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