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.ste...@gmail.com> wrote:
>>>> On 1/9/15 5:32 PM, sebb wrote:
>>>>> On 9 January 2015 at 23:48, sebb <seb...@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.
Phil
>
> Phil
>> Phil
>>>> Phil
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
