On Nov 13, 2007 8:42 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Keith Goodman wrote:
On Nov 12, 2007 10:51 AM, David Cournapeau <cournape@gmail.com> wrote:
On Nov 13, 2007 3:37 AM, Keith Goodman <kwgoodman@gmail.com> wrote:
On Nov 12, 2007 10:10 AM, Peter Creasey <p.e.creasey.00@googlemail.com> wrote:
The following code calling numpy v1.0.4 fails to terminate on my machine, which was not the case with v1.0.3.1
from numpy import arange, float64 from numpy.linalg import eig a = arange(13*13, dtype = float64) a.shape = (13,13) a = a%17 eig(a)
It sounds like the same problem that was reported in this thread:
http://thread.gmane.org/gmane.comp.python.numeric.general/17456/focus=17465
A friend of mine says the windows binary of 1.0.4 also hangs on eigh and lstsq (so linalg in general). I don't have that problem on 1.0.5 compiled on GNU/Linux.
Could you friend try the binaries there:
http://projects.scipy.org/pipermail/numpy-discussion/2007-November/029811.ht...
This may be a problem related to the blas/lapack used for the binaries. The binaries posted above use non optimized BLAS/LAPACK (I can update to 1.0.4 if this is a problem).
He tried. But he is using python 2.4. (He said your binary was for 2.5).
Here we are:
http://www.ar.media.kyoto-u.ac.jp/members/david/archives/numpy-1.0.4.win32-p...
Thank you. He said it worked. He didn't even notice a slow down without ATLAS. On some calculations the results were different (between 1.0.2 and 1.0.4) in the last three decimal places. But that's to be expected, right? ATLAS must give different results than the non optimized alternative.