Vector stacks

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Vector stacks

Charles R Harris
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vector stacks

Eric Wieser

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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vector stacks

Nathaniel Smith
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vector stacks

Marten van Kerkwijk
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vector stacks

Juan Nunez-Iglesias
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vector stacks

Gael Varoquaux
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Vector stacks

Stephan Hoyer-2
In reply to this post by Juan Nunez-Iglesias
I would also prefer separate functions. These are much easier to understand that custom operator overloads.

Side note: implementing this class with __array_ufunc__ for ndarray @ cvec actually isn't possible to do currently, until we fix this bug: https://github.com/numpy/numpy/issues/9028

On Sat, Jul 1, 2017 at 5:31 PM, Juan Nunez-Iglesias <[hidden email]> 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



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Loading...