Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id AB6CC17475 for ; Mon, 12 Jan 2015 17:52:17 +0000 (UTC) Received: (qmail 37336 invoked by uid 500); 12 Jan 2015 17:52:18 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 37217 invoked by uid 500); 12 Jan 2015 17:52:18 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 37202 invoked by uid 99); 12 Jan 2015 17:52:18 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jan 2015 17:52:18 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of sebbaz@gmail.com designates 209.85.220.173 as permitted sender) Received: from [209.85.220.173] (HELO mail-vc0-f173.google.com) (209.85.220.173) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Jan 2015 17:51:52 +0000 Received: by mail-vc0-f173.google.com with SMTP id kv19so7033853vcb.4 for ; Mon, 12 Jan 2015 09:50:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eLh9k1ij6nIxL/SpbhWK9VAP9dHTM/Dg4ZEv53Po+G0=; b=0fgrTF63Tzjn4iKA6ZLrIp0cvjhqGgk6fTucgh1gW+fBzsxkT2ELPJ8MB+0YGkCsEm FnO6tajWyr44Gn1iFU0Tig+yLPae9YWQE5Wx4H1aK/ZxnulY15pMMpPX88UvrL11jgcn /UO8Owu673D1/yo9uC5fEgk6ywFS9vIIqD6us/MU96PkISiwwZeRQ7acrHXxXo+qxFwj 4+ch7Hr+ngs3esfq6PBYmCHB/gXXut1my1gboAZtlrANJEsa4qZwV4XsGuArpbbZBJnw Y8TnAfF9nISf2TYbF3y1zIBurn4gjn0AYq8i7Z04P8WqTXeYBehMWIrMWJEJ1NiGKh1e PzIA== MIME-Version: 1.0 X-Received: by 10.221.66.138 with SMTP id xq10mr18384658vcb.24.1421085020239; Mon, 12 Jan 2015 09:50:20 -0800 (PST) Received: by 10.52.36.174 with HTTP; Mon, 12 Jan 2015 09:50:20 -0800 (PST) In-Reply-To: <54B2F4DD.4040709@gmail.com> References: <54B079FD.3040407@gmail.com> <54B20ED1.80100@gmail.com> <54B2BE98.6060902@gmail.com> <54B2F4DD.4040709@gmail.com> Date: Mon, 12 Jan 2015 17:50:20 +0000 Message-ID: Subject: Re: [MATH] Jenkins unit test failure From: sebb To: Commons Developers List Content-Type: text/plain; charset=UTF-8 X-Virus-Checked: Checked by ClamAV on apache.org On 11 January 2015 at 22:10, Phil Steitz 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 wrote: >>>>> On 1/9/15 5:32 PM, sebb wrote: >>>>>> On 9 January 2015 at 23:48, sebb 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