On Mon, May 21, 2018 at 5:42 PM Matti Picus <matti.pi...@gmail.com> wrote:
> - create a wrapper that can convince the ufunc mechanism to call > __array_ufunc__ even on functions that are not true ufuncs > I am somewhat opposed to this approach, because __array_ufunc__ is about overloading ufuncs, and as soon as we relax this guarantee the set of invariants __array_ufunc__ implementors rely on becomes much more limited. We really should have another mechanism for arbitrary function overloading in NumPy (NEP to follow shortly!). > - expand the semantics of core signatures so that a single matmul ufunc > can implement matrix-matrix, vector-matrix, matrix-vector, and > vector-vector multiplication. I was initially concerned that adding optional dimensions for gufuncs would introduce additional complexity for only the benefit of a single function (matmul), but I'm now convinced that it makes sense: 1. All other arithmetic overloads use __array_ufunc__, and it would be nice to keep @/matmul in the same place. 2. There's a common family of gufuncs for which optional dimensions like np.matmul make sense: matrix functions where 1D arrays should be treated as 2D row- or column-vectors. One example of this class of behavior would be np.linalg.solve, which could support vectors like Ax=b and matrices like Ax=B with the signature (m,m),(m,n?)->(m,n?). We couldn't immediately make np.linalg.solve a gufunc since it uses a subtly different dispatching rule, but it's the same use-case. Another example would be the "matrix transpose" function that has been occasionally proposed, to swap the last two dimensions of an array. It could have the signature (m?,n)->(n,m?), which ensure that it is still well defined (as the identity) on 1d arrays.
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
