[Numpy-discussion] numpy release
Wed Apr 23 18:08:58 CDT 2008
On Apr 23, 2008, at 3:55 PM, Christopher Barker wrote:
>> For matrix x, should x.A == x.A? That is, should the
>> attribute of a Row Vector or Column Vector be 1d?
> Absolutely -- a vector is a 1-d array. The only difference here is
> 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
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
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?
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
> 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: firstname.lastname@example.org **
More information about the Numpy-discussion