commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [MATH] Jenkins unit test failure
Date Sun, 11 Jan 2015 05:49:05 GMT
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? 

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


Mime
View raw message