On Nov 13, 2007 8:42 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > > Keith Goodman wrote: > > On Nov 12, 2007 10:51 AM, David Cournapeau <[EMAIL PROTECTED]> wrote: > > > >> On Nov 13, 2007 3:37 AM, Keith Goodman <[EMAIL PROTECTED]> wrote: > >> > >>> On Nov 12, 2007 10:10 AM, Peter Creasey <[EMAIL PROTECTED]> 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.html > >> > >> 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-py2.4.exe
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. _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
