# Vector stacks

7 messages
Open this post in threaded view
|
Report Content as Inappropriate

## Vector stacks

 Hi All,The  '@' operator works well with stacks of matrices, but not with stacks of vectors. Given the recent addition of '__array_ufunc__',  and the intent to make `__matmul__` use a ufunc, I've been wondering is it would make sense to add ndarray subclasses 'rvec' and 'cvec' that would override that operator so as to behave like stacks of row/column vectors. Any other ideas for the solution to stacked vectors are welcome.Thoughts?Chuck _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Vector stacks

 What would these classes offer over these simple functions: def rvec(x): return x[...,np.newaxis,:] def cvec(x): return x[...,:,np.newaxis] That also makes rvec(x) + cvec(y) behave in the least surprising way, with no extra work Eric ​On Sat, 1 Jul 2017 at 23:32 Charles R Harris <[hidden email]> wrote:Hi All,The  '@' operator works well with stacks of matrices, but not with stacks of vectors. Given the recent addition of '__array_ufunc__',  and the intent to make `__matmul__` use a ufunc, I've been wondering is it would make sense to add ndarray subclasses 'rvec' and 'cvec' that would override that operator so as to behave like stacks of row/column vectors. Any other ideas for the solution to stacked vectors are welcome.Thoughts?Chuck _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Vector stacks

 In reply to this post by Charles R Harris On Sat, Jul 1, 2017 at 3:31 PM, Charles R Harris <[hidden email]> wrote: > Hi All, > > The  '@' operator works well with stacks of matrices, but not with stacks of > vectors. Given the recent addition of '__array_ufunc__',  and the intent to > make `__matmul__` use a ufunc, I've been wondering is it would make sense to > add ndarray subclasses 'rvec' and 'cvec' that would override that operator > so as to behave like stacks of row/column vectors. Any other ideas for the > solution to stacked vectors are welcome. I feel like the lesson of np.matrix is that subclassing ndarray to change the meaning of basic operators creates more problems than it solves? Some alternatives include: - if you specifically want a stack of row vectors or column vectors, insert a new axis at position -1 or -2 - if you want a stack of 1d vectors that automatically act as rows on the left of @ and columns on the right, then we could have vecvec, matvec, vecmat gufuncs that do that -- which isn't quite as terse as @, but not everything can be and at least it'd be explicit what was going on. -n -- Nathaniel J. Smith -- https://vorpus.org_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Vector stacks

 I'm not sure there is *that* much against a class that basically just passes through views of itself inside `__matmul__` and `__rmatmul__` or calls new gufuncs, but I think the lower hurdle is to first get those gufuncs implemented. -- Marten _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Vector stacks

 I’m with Nathaniel on this one. Subclasses make code harder to read and reason about because you now have to be sure of the exact type of things that users are passing you — which are array-like but subtly different. On 2 Jul 2017, 9:46 AM +1000, Marten van Kerkwijk <[hidden email]>, wrote: I'm not sure there is *that* much against a class that basically just passes through views of itself inside `__matmul__` and `__rmatmul__` or calls new gufuncs, but I think the lower hurdle is to first get those gufuncs implemented. -- Marten _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion
Open this post in threaded view
|
Report Content as Inappropriate

## Re: Vector stacks

 My thoughts exactly. Gaël On Sun, Jul 02, 2017 at 10:31:33AM +1000, Juan Nunez-Iglesias wrote: > I’m with Nathaniel on this one. Subclasses make code harder to read and reason > about because you now have to be sure of the exact type of things that users > are passing you — which are array-like but subtly different. > On 2 Jul 2017, 9:46 AM +1000, Marten van Kerkwijk <[hidden email]>, > wrote: >     I'm not sure there is *that* much against a class that basically just >     passes through views of itself inside `__matmul__` and `__rmatmul__` >     or calls new gufuncs, but I think the lower hurdle is to first get >     those gufuncs implemented. >     -- Marten >     _______________________________________________ >     NumPy-Discussion mailing list >     [hidden email] >     https://mail.python.org/mailman/listinfo/numpy-discussion> _______________________________________________ > NumPy-Discussion mailing list > [hidden email] > https://mail.python.org/mailman/listinfo/numpy-discussion--     Gael Varoquaux     Researcher, INRIA Parietal     NeuroSpin/CEA Saclay , Bat 145, 91191 Gif-sur-Yvette France     Phone:  ++ 33-1-69-08-79-68     http://gael-varoquaux.info            http://twitter.com/GaelVaroquaux_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion