On 11 January 2015 at 18:19, Phil Steitz <[email protected]> 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 <[email protected]> wrote: >>>> On 1/9/15 5:32 PM, sebb wrote: >>>>> On 9 January 2015 at 23:48, sebb <[email protected]> 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?
There are two build jobs: https://builds.apache.org/job/Commons%20Math/ https://builds.apache.org/view/All/job/Commons%20Math%20H10/ The former runs on any Unbuntu node, including H10 It emails failures to [email protected] The latter only runs on H10, and does not email. > Phil >> >> Phil >>>> Phil >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
