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