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.har...@gmail.com> wrote: > > > > On Wed, Aug 6, 2014 at 5:51 PM, Nathaniel Smith <n...@pobox.com> wrote: > >> On 7 Aug 2014 00:41, "Charles R Harris" <charlesr.har...@gmail.com> >> wrote: >> > >> > On Wed, Aug 6, 2014 at 5:33 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> >> >> On Thu, Aug 7, 2014 at 12:24 AM, Charles R Harris >> >> <charlesr.har...@gmail.com> wrote: >> >> > >> >> > On Wed, Aug 6, 2014 at 4:57 PM, Nathaniel Smith <n...@pobox.com> >> wrote: >> >> >> >> >> >> On Wed, Aug 6, 2014 at 4:32 PM, Charles R Harris >> >> >> <charlesr.har...@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@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
