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.
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: [EMAIL PROTECTED] **
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-discussion
