[SciPy-dev] Comments on API for Matlab's eigs equivalent (computing a few eigenvalues only)

Charles R Harris charlesr.harris@gmail....
Thu Feb 4 20:54:21 CST 2010


On Thu, Feb 4, 2010 at 7:24 PM, <josef.pktd@gmail.com> wrote:

> On Thu, Feb 4, 2010 at 8:27 PM, David Cournapeau <cournape@gmail.com>
> wrote:
> > On Fri, Feb 5, 2010 at 9:43 AM, Warren Weckesser
> > <warren.weckesser@enthought.com> wrote:
> >
> >> David C,
> >>
> >> You said this was for symmetric matrices, but do you envision later
> >> allowing nonsymmetric matrices?
> >
> > Yes. I have only implemented symmetric/Hermitian because that's the
> > only solver that handles getting only a few eigenvalues in LAPACK.
> > Matlab own eigs function uses ARPACK for both symmetric/unsymmetric
> > cases, which is not good according to one of the Lapack developer
> > (http://mail.scipy.org/pipermail/scipy-dev/2007-March/006778.html).
> > But we could use ARPACK for the general case in eigs.
> >
> >>
> >> If not, then perhaps the name of the function should be 'eigsh',
> >> following the precedent set by numpy.linalg and scipy.linalg.
> >
> > I wonder whether those eigh functions are a good idea: I fear that
> > most people will always use eig - maybe one could use the underlying
> > eig*h solver in eig* if the matrix is detected as being symmetric ? I
> > am not really knowledgeable about those issues, though. For example, I
> > don't know whether the symmetric aspect should be checked exactly, or
> > if it is better to use a symmetric solver  even if there are very
> > small errors in say A'-A.
> >
> >>
> >> In particular, the choice of ordering by magnitude or by real part is
> >> convenient.
> >
> > It seems that one would need to implement the non-symmetric
> > capabilities to sort this out. I fear that those options are solver
> > specific, though - maybe the solution is to have two levels of API,
> > one low-level and one high level.
> >
> > cheers,
> >
> > David
> > _______________________________________________
> > SciPy-Dev mailing list
> > SciPy-Dev@scipy.org
> > http://mail.scipy.org/mailman/listinfo/scipy-dev
> >
>
> the current version of scipy.linalg.eigh sorts from smallest to largest
>
> >>> scipy.linalg.eigh(x)[0]
> array([  4.04457427e-03,   1.84073286e-01,   6.74875960e-01,
>         3.23328824e+00,   4.00741304e+00,   6.98333680e+00,
>         1.45314842e+01,   1.49260377e+01,   2.47166702e+01,
>         2.98955755e+01])
> >>> scipy.linalg.eigh(x, eigvals=(0,3))[0]
> array([ 0.00404457,  0.18407329,  0.67487596,  3.23328824])
> >>> scipy.linalg.eigh(x, eigvals=(len(x)-3, len(x)-1))[0]
> array([ 14.92603769,  24.71667021,  29.89557547])
>
>
> >>> x = np.random.randn(10, 10) + 1j*np.random.randn(10, 10)
> >>> x = np.dot(x.T, x)
> >>> scipy.linalg.eigh(x, eigvals=(0,3))[0]
> array([-36.82039662, -18.20362967, -12.21716065,  -9.79752274])
> >>> scipy.linalg.eigh(x, eigvals=(len(x)-3, len(x)-1))[0]
> array([ 14.44815917,  28.8394026 ,  42.45471058])
>
>
Yeah. It's my fault ;) It didn't use to sort at all.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20100204/eddc9873/attachment-0001.html 


More information about the SciPy-Dev mailing list