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,
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 b
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 ,
wrote:
> I'm not sure ther
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-Di
On Sat, Jul 1, 2017 at 3:31 PM, Charles R Harris
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 sen
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
wrote:
> Hi
