[Numpy-discussion] Problem with numpy.linalg.eig?
Keith Goodman
kwgoodman@gmail....
Wed Nov 14 08:51:48 CST 2007
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.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.
More information about the Numpy-discussion
mailing list