[SciPy-dev] Non-deterministic test failures in scipy-0.7.0b1

[David Cournapeau]

On Mon, Dec 22, 2008 at 3:19 AM, Roger Kramer
<rkramer at systemsbiology.org> wrote:
> I'm still looking into this, but in case anyone has ideas that could save me
> some time...
> The following occurs non-deterministically:
>
> ======================================================================
> FAIL: test_x_stride (test_fblas.TestCgemv)
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>   File
> "/home/rk/lib/python2.5/site-packages/scipy/lib/blas/tests/test_fblas.py",
> line 345, in test_x_stride
>     assert_array_almost_equal(desired_y,y)
>   File "/home/rk/lib/python2.5/site-packages/numpy/testing/utils.py", line
> 311, in assert_array_almost_equal
>     header='Arrays are not almost equal')
>   File "/home/rk/lib/python2.5/site-packages/numpy/testing/utils.py", line
> 296, in assert_array_compare
>     raise AssertionError(msg)
> AssertionError:
> Arrays are not almost equal
>
> (mismatch 33.3333333333%)
>  x: array([ -2.91183448 +2.91183448j, -14.95274162+16.95274162j,
>          3.63382101 +0.36617899j], dtype=complex64)
>  y: array([ -2.91183448 +2.91183448j, -14.95274162+16.95274353j,
>          3.63382101 +0.36617899j], dtype=complex64)
> ------------------------------------------------------------------------
>

the test is buggy, because with complex64, you have single precision
in each dimension, with 7 significant digits, and as you can see, the
difference in the second element appear at the 8th digit

>, but since these are the only test failures it seems
> a stretch to implicate threading in general.

Yes, specially since there is almost no explicit threading in scipy.

>
> In case it's relevant, I compiled (gcc 4.3.2) Netlib CBLAS and LAPACK 3.2
> sources directly as shared libraries. Have had considerable trouble with
> LAPACK.

Yes, LAPACK is a pain, because of fortran. You are better off with the
ones packaged by your OS vendor if you can have some.

> Compiled code only passes the lapack test suite if the
> machine-dependent bits in INSTALL are compiled without optimization.
> Everything else (in LAPACK) is compiled with -O2 -march=native
> -mtune=native, and I'm on a Dell machine with an E2160 processor. Intel's
> "issues list" on this processor family is a fright.

march tells gcc to use arch specific instructions, so the results may
well depend on your CPU.

David