[Numpy-discussion] Allowing broadcasting of code dimensions in generalized ufuncs

Marten van Kerkwijk m.h.vankerkwijk at gmail.com
Tue Jun 12 21:13:47 EDT 2018

On Tue, Jun 12, 2018 at 2:35 AM, Eric Wieser <wieser.eric+numpy at gmail.com>

> Frozen dimensions:
> I started with just making every 3-vector and 3x3-matrix structured arrays
> with the relevant single sub-array entry
> I was actually suggesting omitting the structured dtype (ie, field names)
> altogether, and just using the subarray dtypes (which exist alone, but not
> in arrays).
> Another (small?) advantage is that I can use `axis
> This is a fair argument against my proposal - at any rate, I think we’d
> need a better story for subarray dtypes before trying to add support to
> them for ufuncs
Yes, I've been wondering about the point of the sub-arrays... They seem
interesting but in arrays just disappear. Their possible use would be to
change the shape as seen by the outside world (as happens if one does
define that sub-array as a 1-part structured array).

Anyway, for another discussion!

> ------------------------------
> Broadcasting dimensions
> But perhaps a putative weighted_mean … is a decent example
> That’s fairly convincing as a non-chained ufunc case. Can you add an
> example like that to the NEP?

> Also, it has the benefit of being clear what the function can handle by
> inspection of the signature
> Is broadcasting (n),(n)->(),() less clear that (n|1),(n|1)->(),()? Can
> you come up with an example where only some dimensions make sense to
> broadcast?
Not a super-convincing one, though I guess one could think of a similar
function for 3-vectors (which somehow must care about those being
three-dimensional, because, say, it calculates the average direction of the
cross product in spherical angles...), then, in the signature
`(n,3),(n,3)->(),(),(),()` one would like to indicate that the `n` could be
broadcast, but the `3` could not.

As I now write in the NEP, part of the reason of doing it by distinct
dimension is that I already need a flag for flexible, so it is easy to add
one for broadcastable; similarly, in the actual code, there is quite a bit
of shared stuff.

-- Marten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180612/c2c3f8a1/attachment.html>

More information about the NumPy-Discussion mailing list