[Numpy-discussion] numpy release

Bill Spotz wfspotz@sandia....
Wed Apr 23 18:08:58 CDT 2008

On Apr 23, 2008, at 3:55 PM, Christopher Barker wrote:

>> For matrix x, should x[0].A[0] == x.A[0][0]? That is, should the  
>> array
>> attribute of a Row Vector or Column Vector be 1d?
> Absolutely -- a vector is a 1-d array. The only difference here is  
> that
> we can preserve the concept of a row vs. a column vector -- key to
> linear algebra, which is the whole point of the Matrix class. I'd be
> just as happy if a RowVector an ColumnVector were a more unique object
> -- a 1-d array with the operation overloaded, rather than a (1,n) or
> (n,1) matrix, but I understand that would be more work.

The way I envisioned this was that RowVector and ColumnVector would  
inherit from Matrix, so that you would inherit all of the Matrix  
functionality.  They would just be special cases where ncol=0 or  
nrow=0, allowing single indexing.

If Matrix-Matrix multiplication is implemented properly, then the Row/ 
ColumnVector multiplication operators should automatically work.

>> Inconsistency in the indexing style for producing row vectors and
>> column vectors
> not really:

I agree with Alan here.  M[i] returns a RowVector, but there is no  
corresponding single index way to retrieve a ColumnVector (unless we  
want to use __call__() to make M(j) return a ColumnVector . . . but  
this is highly unintuitive.)

Thinking out loud: we could support

     M[i=#]   return a RowVector
     M[j=#]   return a ColumnVector
     M[#]     equivalent to M[i=#]

> The fact that there is another way to get a row vector: M[i] is a  
> bonus.

Except that the behavior of M[i] is one of the driving issues of the  

>> Loss of a standard way to extract a row or a column as a submatrix
>> (rather than a vector)

If Row/ColumnVector inherit from Matrix, then this is not strictly  
true.  There is no reason that these classes could not support [i,j]  
indexing, which means they would BE Matrices (inheritence) and they  
would BEHAVE like Matrices (except for V[i][j] . . . argh).

>> No clear gain in functionality over the simpler proposal 2.

Gains: (1) non-scalar extractions from linear algebra objects ARE and  
BEHAVE like linear algebra objects; (2) a clear path for dense and  
sparse matrices to have the same (or at least analogous) interfaces.

> Aside from the fact that someone needs to write the code -- why don't
> people like the row/column vector idea? It just feels so natural to  
> me:

Unless I'm misremembering, Alan is the only one who has expressed  
concerns and he is willing to concede to the design if others agree.

> A matrix is a 2-d array with some functionality overloaded to make it
> convenient to do linear algebra.
> A vector is a 1-d array with some functionality overloaded to make it
> convenient to do linear algebra.

Again, I would argue for Vectors inheriting from Matrix.  I would make  
the case based on code reuse and elegance, although these might be  
overridden by some other concern.

> And yes, maybe this will lead to tensors some day!

Don't see why not.

> Another couple questions: -- would there be constructors for vectors?
> np.RowVector((1,2,3,4,5))
> np.ColumnVector((1,2,3,4,5,6))

Yes.  They should be full-fledged classes, although with inheriting  
from Matrix, the implementation should be relatively small.  What about

np.Matrix(<container of RowVector>)
np.Matrix(<container of ColumnVector>)


> and would:
> A_RowVector.T == A_ColumnVector


> All the example code I've seen during this discussion have been  
> examples
> of iterating and indexing -- not one has actually been linear  
> algebra --
> perhaps we should see some of those before making any decisions.

Right.  I have generally thought about this in the context of, say, a  
Krylov-space iterative method, and what that type of interface would  
lead to the most readable code.

** Bill Spotz                                              **
** Sandia National Laboratories  Voice: (505)845-0170      **
** P.O. Box 5800                 Fax:   (505)284-0154      **
** Albuquerque, NM 87185-0370    Email: wfspotz@sandia.gov **

More information about the Numpy-discussion mailing list