Re: [Numpy-discussion] Preliminary thoughts on implementing __matmul__

On 7 Aug 2014 00:41, "Charles R Harris" wrote:

On Wed, Aug 6, 2014 at 5:33 PM, Nathaniel Smith wrote:

...

On Thu, Aug 7, 2014 at 12:24 AM, Charles R Harris wrote:

...

On Wed, Aug 6, 2014 at 4:57 PM, Nathaniel Smith wrote:

...

On Wed, Aug 6, 2014 at 4:32 PM, Charles R Harris wrote:

...

Should also mention that we don't have the ability to operate on

...

...

...

...

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

...

...

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

...

...

Another option, already supported to a large extent, is to have row and col classes inheriting from ndarray that add nothing, except for a

stacked the '@' preserved. 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.

Yes. But @ can never be magic - either people will have to write something extra to flip these flags on their array objects, or they'll have to write something extra to describe which operation they want. @ was never intended to cover every case, just the simple-but-super-common ones that dot covers, plus a few more (simple broadcasting). We have np.add even though + exists too... -n