# [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
conversation.

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

Yes.

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

Krylov-space iterative method, and what that type of interface would

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

```