Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of phil.steitz@gmail.com
 designates 209.85.220.52 as permitted sender)
Message-ID: <54B2BE98.6060902@gmail.com>
Date: Sun, 11 Jan 2015 11:19:04 -0700
From: Phil Steitz <phil.steitz@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10;
 rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Commons Developers List <dev@commons.apache.org>
Subject: Re: [MATH] Jenkins unit test failure
References: 
 <CAOGo0VbEXifZM630yvx1C7dAKR2fhyucfWFT_FDGef7TB9fqpg@mail.gmail.com>
	<CAOGo0VZFh0A3L9mLdx-9MsSAZy1f-CX5ht4y4pbO8wCk_cyb-A@mail.gmail.com>
	<54B079FD.3040407@gmail.com>
 <CAOGo0VZaME=SYG__uty=nQ5iFmW5--gzBv9_4fi=rtdKm+crdA@mail.gmail.com>
 <54B20ED1.80100@gmail.com>
In-Reply-To: <54B20ED1.80100@gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 1/10/15 10:49 PM, Phil Steitz wrote:
> On 1/9/15 6:09 PM, sebb wrote:
>> On 10 January 2015 at 01:01, Phil Steitz <phil.steitz@gmail.com> wrote:
>>> On 1/9/15 5:32 PM, sebb wrote:
>>>> On 9 January 2015 at 23:48, sebb <sebbaz@gmail.com> wrote:
>>>>> Of the last 6 runs, only 1 had a problem with unit test failures.
>>>>>
>>>>> All the builds ran on ubuntu3, apart from the failure which ran on H10.
>>>>> This may have some bearing on the result; I don't yet know.
>>>>>
>>>>> I had a quick look at 2 tests that failed:
>>>>>
>>>>> SimpleRegressionTest.testPerfect
>>>>>
>>>>> SimpleRegressionTest.testPerfectNegative
>>>>>
>>>>> Although the test case has some instance data, these particular tests
>>>>> do not use any, so it does not look like a concurrency issue in the
>>>>> unit test itself.
>>>>>
>>>>> The SimpleRegression class has mutable instance data, but the test
>>>>> cases create their own instance.
>>>>>
>>>>> I don't know anything about the math functions involved, but it looks
>>>>> as though Infinity might result from getSignificance() if
>>>>> getSlopeStdErr() returns 0, as the latter is used as a divisor. Or if
>>>>> the field sumXX is 0 because that is also used as a divisor.
>>>>>
>>>>> Maybe the H10 host has different floating point hardware?
>>>>>
>>>>> I'll try running some more tests on H10.
>>>> the build failed again on H10; exactly the same tests failed as before:
>>>>
>>>> This test:
>>>> https://builds.apache.org/job/Commons%20Math%20H10/1/console
>>>>
>>>> Previous failure:
>>>> https://builds.apache.org/job/Commons%20Math/14/console
>>> This is actually a bug.  Thanks, sebb (and Jenkins)!
>>>
>>> Has been here since 1.x.  What is going on is that the data sets
>>> used in the test cases are set up to be perfect linear
>>> relationships, which should in fact lead to mean square error (and
>>> hence slope standard error) equal to 0.  The Jenkins box must be
>>> getting exact 0.  The funny thing is the test is there to validate
>>> correct performance for models like this.  Its success unfortunately
>>> depends on poor precision.
>>>
>>> I will open a JIRA for this.  I don't think it is a release blocker
>>> for 3.4.1, as I am sure you would get the same thing in any earlier
>>> version of [math].
>> OK good to know.
>>
>> I'll leave the H10 Jenkins job for now to make it easy to retest.
> My first guess here was wrong.  The infinities are being handled
> correctly for the JDKs I have.  Something must be going awry in the
> t distribution cumulative probability computation for +INF on the
> box that is failing.  Is there a way to find out exactly what JDK
> and OS version are being used? 

I just committed a test that tests the t distribution computations
directly.  It seems to have run clean; but the other test ran clean
too.  Is there any way to force the build to use the host that fails?

Phil
>
> Phil
>>> Phil
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org