[Numpy-discussion] Mysterious test_pareto failure on Travis
njs at pobox.com
Tue Sep 4 16:37:35 EDT 2012
On Tue, Sep 4, 2012 at 9:17 PM, Ondřej Čertík <ondrej.certik at gmail.com> wrote:
> On Tue, Sep 4, 2012 at 12:41 PM, Ondřej Čertík <ondrej.certik at gmail.com> wrote:
>> On Tue, Sep 4, 2012 at 12:31 PM, Ondřej Čertík <ondrej.certik at gmail.com> wrote:
>>> On Tue, Sep 4, 2012 at 3:15 AM, Nathaniel Smith <njs at pobox.com> wrote:
>>>> The last two Travis builds of master have failed consistently with the
>>>> same error:
>>>> It looks like a real failure -- we're getting the same error on every
>>>> build variant, some sort of problem in test_pareto. Example:
>>>> The obvious culprit would be the previous commit, which regenerated
>>>> mtrand.c with Cython 0.17:
>>>> What's weird, though, is that that commit passed just fine on Travis:
>>>> It's just the two commits since then that failed. But these commits
>>>> have been 1-line docstring changes, so I don't see how they could have
>>>> possibly created the problem.
>>>> Also, the test passes fine with python 2.7 on my laptop with current master.
>>>> Can anyone reproduce this failure? Any ideas what might be going on?
>>> I made this:
>>> It was me who updated the Cython file. It seemed to be working. I've
>>> added the issue
>>> to the release TODO.
>> Ok, here is how to reproduce the problem:
>> 1) install my numpy-vendor vagrant image (32 bit Ubuntu), as directed
>> in the README:
>> 2) run tests, you'll get:
> So the problem was actually introduced much earlier. Most probably it
> has never worked
> in 32bit Ubuntu 12.04. I tried for example this old commit:
> and it still fails:
> But in any case, this seems to be a problem with the actual 32bit
> Ubuntu 12.04 itself. So maybe something in gcc
> has changed that now triggers the problem.
To be clear, the mismatching value is:
-> np.testing.assert_array_almost_equal(actual, desired, decimal=15)
(Pdb) actual[1, 0]
(Pdb) desired[1, 0]
So they do match to 14 decimal points, and it's entirely possible that
this is just a problem of the test being too stringent in requiring 15
decimal points of match. Maybe the 32-bit GCC is spilling registers
differently, tripping the famous x86 idiosyncrasy where register
spilling triggers rounding. But I'd feel better if someone familiar
with the pareto code could confirm.
More information about the NumPy-Discussion