commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [MATH] Jenkins unit test failure
Date Mon, 12 Jan 2015 17:50:20 GMT
On 11 January 2015 at 22:10, Phil Steitz <phil.steitz@gmail.com> wrote:
> On 1/11/15 11:19 AM, Phil Steitz wrote:
>> 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?
>
> I can't make any sense of what is going on with the Jenkins builds.
> Clean runs and then lots of errors.  This one explains the
> SimpleRegression "problem" (which is not a problem with that class
> at least)
>
> testCumulativeProbablilityExtremes(org.apache.commons.math3.distribution.TDistributionTest)
 Time elapsed: 0.001 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<1.0> but was:<-Infinity>
>         at org.junit.Assert.fail(Assert.java:88)
>         at org.junit.Assert.failNotEquals(Assert.java:743)
>         at org.junit.Assert.assertEquals(Assert.java:494)
>         at org.junit.Assert.assertEquals(Assert.java:592)
>         at org.apache.commons.math3.distribution.TDistributionTest.testCumulativeProbablilityExtremes(TDistributionTest.java:109)
>
> Earlier runs this ran clean. There is nothing non-deterministic about this test (or quite
a few of the others that randomly seem to fail).
>
> I wonder if we have a bad cpu or something somewhere.

AFAICS all the failed builds ran on H10.

IMO it is consistent; the apparent randomness comes from the fact the
there are several Ubuntu hosts, including H10.

> Phil
>
>
>>
>> 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
>

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


Mime
View raw message