[SciPy-Dev] one failure in scipy trunk

[josef.pktd at gmail.com]

On Fri, Jan 14, 2011 at 1:33 PM, Bruce Southey <bsouthey at gmail.com> wrote:
> On 01/14/2011 12:06 PM, josef.pktd at gmail.com wrote:
>
> On Fri, Jan 14, 2011 at 12:48 PM, Pauli Virtanen <pav at iki.fi> wrote:
>
> Fri, 14 Jan 2011 12:09:54 -0500, josef.pktd wrote:
>
> compiled against numpy 1.5.1
>
> Josef
>
> ======================================================================
> FAIL: Test singular pair
> ----------------------------------------------------------------------
>
> [clip]
>
>   "...\scipy\linalg\tests\test_decomp.py", line 189, in _check_gen_eig
>     err_msg=msg)
>
> This is actually a bit strange. The test does this:
>
>    w, vr = eig(A,B)
>    wt = eigvals(A,B)
>    # ... some stuff that does not touch w and wt
>    # The failing assertion:
>    assert_array_almost_equal(sort(w[isfinite(w)]), sort(wt[isfinite(wt)]),
>                              err_msg=msg)
>
> The code paths in `eig` and `eigvals` are identical as far as
> the computation of `w` and `wt` is concerned.
>
> So perhaps this is another manifestation of the no-determinism of linear
> algebra which I recall occurred on your computer? It seems this particular
> is supposed to be ill-conditioned and susceptible to rounding error...
>
>    ***
>
> It would be nice to find out what exactly is causing the non-determinism,
> since it seems you are not the only one seeing it (other machines where this
> occurs were reported on the Numpy ML).
>
>    http://permalink.gmane.org/gmane.comp.python.numeric.general/42082
>
> Are you able to reproduce it using only the `dot` function? What happens if
> you then use the non-BLAS `numpy.core.multiarray.dot` instead?
>
> I can try a bit later, I'm trying to figure out a stats bug and don't
> want to mess with my scipy since it takes me more than an hour to
> build.
>
> Looking at the test and try the non atlas dot should be fine.
>
> Josef
>
> --
> Pauli Virtanen
>
> _______________________________________________
> SciPy-Dev mailing list
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
> Presumably this previously passed under numpy 1.3 (I think) then the change
> in versions reflects the change in numpy/scipy release managers. So does
> this occur with Christoph's releases on your system?
> http://www.lfd.uci.edu/~gohlke/pythonlibs/
>
> If so, then there is something missing in the binary generation.
>
> In anycase, we also need more information on the OS (I do presume windows
> but not version etc), and how numpy and scipy were installed including
> specific version of the installers if used.

The failure didn't show up yesterday, when I tested, the official
0.9b1 installer.

Either it's a recent change in trunk, or it is because my ATLAS,
lapack, blas, is an older version.

If I'm the only one seeing it, then I will look at my setup and the
details later.

Josef


>
>
> Bruce
>
>
>
>
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>
>