<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 5:51 PM, Nathaniel Smith <span dir="ltr"><<a href="mailto:njs@pobox.com" target="_blank">njs@pobox.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><p dir="ltr">On 7 Aug 2014 00:41, "Charles R Harris" <<a href="mailto:charlesr.harris@gmail.com" target="_blank">charlesr.harris@gmail.com</a>> wrote:<br>

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