# [SciPy-dev] [SciPy-user] scipy.linalg.eig() returns transposed eigenvector matrix

Pearu Peterson pearu at scipy.org
Tue Nov 15 00:41:14 CST 2005

```
On Tue, 15 Nov 2005, Robert Dick wrote:

> 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
>
>> 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
>  la.eig(m)[1][0]
> or
>  la.eig(m)[1][:, 0]
> be used?

I am not convinced that getting eigenvectors one-by-one is the most common
case of la.eig usage. Sometimes one needs to operate with the whole matrix
of eigenvectors and then the mathematically "correct" representation of
the eigenmatrix would be more convinient.

> 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.

Documentation can always be fixed. Numeric compatibility is the biggest
problem now. I have had long time in my mind the following idea:
Introduce, say, scipy.Numeric package that is fully compatible with
Numeric and having array with typecode, etc methods and
completely Numeric behaviour such that the replacement
Numeric->scipy.Numeric would be the only change that one needs to apply to
Numeric-based codes. Or even simpler, install scipy.Numeric as standalone
Numeric. But introducing scipy.Numeric may require lots of work and I am
not sure that the effort is worth it.

Pearu

```