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

[Roger Kramer]

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

...and test_y_stride occasionally fails, too. What's odder than the fact
that the arrays don't really look 33% mismatched, is that on successive runs
of scipy.test(), the failure may or may not occur, and I'm changing/touching
-nothing- between the test runs. Normally, non-deterministic failures would
scream race conditions, but since these are the only test failures it seems
a stretch to implicate threading in general.

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. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20081221/9a623507/attachment.html>