[Numpy-discussion] Changes to generalized ufunc core dimension checking
shoyer at gmail.com
Thu Mar 17 17:41:51 EDT 2016
On Thu, Mar 17, 2016 at 1:04 AM, Travis Oliphant <travis at continuum.io>
> I think that is a good idea. Let the user decide if scalar broadcasting
> is acceptable for their function.
> Here is a simple concrete example where scalar broadcasting makes sense:
> A 1-d dot product (the core of np.inner) (k), (k) -> ()
> A user would assume they could call this function with a scalar in either
> argument and have it broadcast to a 1-d array. Of course, if both
> arguments are scalars, then it doesn't make sense.
> Having a way for the user to allow scalar broadcasting seems sensible and
> a nice compromise.
To generalize a little bit, consider the entire family of weighted
statistical function (mean, std, median, etc.). For example, the gufunc
version of np.average is basically equivalent to np.inner with a bit of
Arguably, it *could* make sense to broadcast weights when given a scalar:
np.average(values, weights=1.0 / len(values)) is pretty unambiguous.
That said, adding an explicit "scalar broadcasting OK flag" seems like a
hack that will need even more special logic (e.g., so we can error if both
arguments to np.inner are scalars).
Multiple dispatch for gufunc core signatures seems like the cleaner
solution. If you want np.inner to handle scalars, you need to supply core
signatures (k),()->() and (),(k)->() along with (k),(k)->(). This is the
similar to vision of three core signatures for np.matmul: (i),(i,j)->(j),
(i,j),(j)->(i) and (i,j),(j,k)->(i,k).
Maybe someone will even eventually get around to adding an axis/axes
argument so we can specify these core dimensions explicitly. Writing
np.inner(a, b, axes=((-1,), ())) could trigger the (k),()->() signature
even if the second argument is not a scalar (it should be broadcast against
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion