[Numpy-discussion] Problem with numpy.linalg.eig?

[Keith Goodman]

On Nov 13, 2007 8:42 PM, David Cournapeau <david at ar.media.kyoto-u.ac.jp> wrote:
>
> Keith Goodman wrote:
> > On Nov 12, 2007 10:51 AM, David Cournapeau <cournape at gmail.com> wrote:
> >
> >> On Nov 13, 2007 3:37 AM, Keith Goodman <kwgoodman at gmail.com> wrote:
> >>
> >>> On Nov 12, 2007 10:10 AM, Peter Creasey <p.e.creasey.00 at 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.