[Numpy-discussion] Preliminary thoughts on implementing __matmul__

[Charles R Harris]

On Wed, Aug 6, 2014 at 5:33 PM, Nathaniel Smith <njs at pobox.com> wrote:

> On Thu, Aug 7, 2014 at 12:24 AM, Charles R Harris
> <charlesr.harris at gmail.com> wrote:
> >
> > On Wed, Aug 6, 2014 at 4:57 PM, Nathaniel Smith <njs at pobox.com> wrote:
> >>
> >> On Wed, Aug 6, 2014 at 4:32 PM, Charles R Harris
> >> <charlesr.harris at gmail.com> wrote:
> >> > Should also mention that we don't have the ability to operate on
> stacked
> >> > vectors because they can't be identified by dimension info. One
> >> > workaround
> >> > is to add dummy dimensions where needed, another is to add two flags,
> >> > row
> >> > and col, and set them appropriately. Two flags are needed for backward
> >> > compatibility, i.e., both false is a traditional array.
> >>
> >> It's possible I could be convinced to like this, but it would take a
> >> substantial amount of convincing :-). It seems like a pretty big
> >> violation of orthogonality/"one obvious way"/etc. to have two totally
> >> different ways of representing row/column vectors.
> >>
> >
> > The '@' operator supports matrix stacks, so it would seem we also need to
> > support vector stacks. The new addition would only be effective with the
> '@'
> > operator. The main problem I see with flags is that adding them would
> > require an extensive audit of the C code to make sure they were
> preserved.
> > Another option, already supported to a large extent, is to have row and
> col
> > classes inheriting from ndarray that add nothing, except for a possible
> new
> > transpose type function/method. I did mock up such a class just for fun,
> and
> > also added a 'dyad' function. If we really don't care to support stacked
> > vectors we can get by without adding anything.
>
> It's possible you could convince me that this is a good idea, but I'm
> starting at like -0.95 :-). Wouldn't it be vastly simpler to just have
> np.linalg.matvec, matmat, vecvec or something (each of which are
> single-liners in terms of @), rather than deal with two different ways
> of representing row/column vectors everywhere?
>
>
Sure, but matvec and vecvec would not be supported by '@' except when vec
was 1d because there is no way to distinguish a stack of vectors from a
matrix or a stack of matrices.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140806/2fc56dbb/attachment.html>