[Numpy-discussion] Changes to generalized ufunc core dimension checking

Stephan Hoyer shoyer at gmail.com
Fri Mar 18 13:21:14 EDT 2016

On Thu, Mar 17, 2016 at 3:28 PM, Jaime Fernández del Río <
jaime.frio at gmail.com> wrote:

> Would the logic for such a thing be consistent? E.g. how do you decide if
> the user is requesting (k),(k)->(), or (k),()->() with broadcasting over a
> non-core dimension of size k in the second argument? What if your
> signatures are (m, k),(k)->(m) and (k),(n,k)->(n) and your two inputs are
> (m,k) and (n,k), how do you decide which one to call? Or alternatively, how
> do you detect and forbid such ambiguous designs? Figuring out the dispatch
> rules for the general case seems like a non-trivial problem to me.

I would require a priority order for the core signatures when the gufunc is
created and only allow one implementation per argument dimension in the
core signature (i.e., disallow multiple implementations like (k),(k)->()
and (k),(m)->()).

The rule would be to dispatch to the implementation with the first core
signature with the right number of axes. The later constraint ensures that
(m,n) @ (k,n) errors if k != n, rather than attempting vectorized
matrix-vector multiplication. For matmul/@, the priority order is pretty
1. (m,n),(n,k)->(n,k)
2. (m,n),(n)->(m)
3. (m),(m,n)->(n)
4. (m),(m)->()

(2 and 3 could be safely interchanged.)

For scenarios like "(k),(k)->(), or (k),()->()", the only reasonable choice
would be to put (k),(k)->() first -- otherwise it never gets called. For
the other ambiguous case, "(m, k),(k)->(m) and (k),(n,k)->(n)", the
implementer would also need to pick an order.

Most of the tricky cases for multiple dispatch arise from extensible
systems (e.g., Matthew Rocklin's multipledispatch library), where you
allow/encourage third party libraries to add their own implementations and
need to be sure the combined result is still consistent. I wouldn't suggest
such a system for NumPy -- I think it's fine to require every gufunc to
have a single owner. There are other solutions for allowing extensibility
to duck array types (namely, __numpy_ufunc__).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20160318/42a2ad68/attachment.html>

More information about the NumPy-Discussion mailing list