[Numpy-discussion] Preliminary thoughts on implementing __matmul__

Eelco Hoogendoorn hoogendoorn.eelco at gmail.com
Thu Aug 7 03:40:44 EDT 2014


I don't expect stacked matrices/vectors to be used often, although there
are some areas that might make heavy use of them, so I think we could live
with the simple implementation, it's just a bit of a wart when there is
broadcasting of arrays. Just to be clear, the '@' broadcasting differs from
the dot broadcasting, agreed?

This lack of elegance and unity combined with frankly; a lack of utility,
made me plead @ is a bad idea in the first place; but I guess I lost that
debate...


On Thu, Aug 7, 2014 at 2:00 AM, Charles R Harris <charlesr.harris at gmail.com>
wrote:

>
>
>
> On Wed, Aug 6, 2014 at 5:51 PM, Nathaniel Smith <njs at pobox.com> wrote:
>
>> On 7 Aug 2014 00:41, "Charles R Harris" <charlesr.harris at gmail.com>
>> wrote:
>> >
>> > 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.
>>
>> 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...
>>
> I don't expect stacked matrices/vectors to be used often, although there
> are some areas that might make heavy use of them, so I think we could live
> with the simple implementation, it's just a bit of a wart when there is
> broadcasting of arrays. Just to be clear, the '@' broadcasting differs from
> the dot broadcasting, agreed?
>
> Chuck
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140807/51c31b6f/attachment.html>


More information about the NumPy-Discussion mailing list