[SciPy-dev] [SciPy-user] scipy.linalg.eig() returns transposed eigenvector matrix
dickrp at wckn.com
Tue Nov 15 00:46:19 CST 2005
Fernando Perez wrote:
>Travis Oliphant wrote:
>>Pearu Peterson wrote:
>>>This is a matter of definition. scipy.linalg.eig and
>>>scipy.basic.linalg.eig return correct results according to their
>>>documentation. Just scipy.linalg.eig assumes that eigenvectors are
>>>returned column-wise, i.e.
>>Thanks for the clarification, Pearu. I'm glad things are actually
>>working as advertised.
>If I may suggest, I think these two should be unified, though. It will be
>seriously disconcerting for new users to find that
> If the two are to be unified, I think scipy.basic should change. But,
> that leads to a problem because of compatibility with Numeric.
> So, what to do?
> We could change scipy.basic.linalg.eig and keep
> scipy.basic.linalg.eigenvectors as the old Numeric behavior.
If you need to decide which one to change, identify the common case. Is it
more common to access all dimensions of one eigenvector or access one
dimension of many eigenvectors? The common case should be the easiest to
express, i.e., if one wants the first eigenvector, should
The first convention (Numeric-style) maintains compatibility with Numeric and
conforms with the documentation in "Guide to SciPy: Core System":
The second element of the return tuple contains the eigenvectors in the
rows (x[i] is the ith eigenvector).
The second convention (current scipy.eig) is more MATLAB-like.
It might be good to change "Building New SciPy" to "Building SciPy" and change
"Building SciPy" to "Building Old Versions of SciPy" at
When I decided to try SciPy I read the first, and apparently default,
document. It indicates that Numeric is necessary for SciPy. As a
consqeuence, I wasted a lot of time rewriting significant portions of
Numeric in order to get it to build with ACML. Only after later getting SciPy
from svn did I realize that Numeric is no longer required.
The downloads page might best direct folks to the svn repository. Svn is easy
but, when trying a new package, I generally go with tarball releases under the
assumption that they are more stable. However, scipy's tarball is a year
old. I would have gone straight to svn if the page suggested it and that
would have resulted in a better first impression of SciPy.
In case this sounds too negative, I should state that SciPy has great
potential and I intend to keep using it and sending bug reports (or checking
in, after establishing history).
More information about the Scipy-dev