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

[Stephan Hoyer]

On Thu, May 31, 2018 at 4:21 AM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

> I think the case for frozen dimensions is much more solid that just
> `cross1d` - there are many operations that work on size-3 vectors.
> Indeed, as I noted in the PR, I have just been wrapping a
> Standards-of-Astronomy library in gufuncs, and many of its functions
> require size-3 vectors or 3x3 matrices [1]. Of course, I can put
> checks on the sizes, and I've now done that in a custom type resolver
> (which I needed anyway since, as you say, user dtypes is currently not
> easy), but there is a real problem for functions that take scalars and
> produce vectors: with a signature like `(),()->(n)`, I am forced to
> pass in an output with size 3, which is very inconvenient (especially
> if I then also want to override with `__array_ufunc__` - now my
> Quantity implementation also has to start changing an output already
> put in. So, having frozen dimensions is definitely helpful for
> developers of new gufuncs.
>

I agree that the use-cases for frozen dimensions are well motivated. It's
not as common as writing code that supports arbitrary dimensions, but given
that the real world is three dimensional it comes up with some regularity.
Certainly for these use-cases it would add significant values (not
requiring pre-allocation of output arrays).

Furthermore, with frozen dimensions, the signature is not just
> immediately clear, `(),()->(3)` for the example above, it is also
> better in telling users about what a function does.
>

Yes, frozen dimensions really do feel like a natural fit. There is no
ambiguity about what an integer means in a gufunc signature, so the
complexity of the gufunc model (for users and __array_ufunc__ implementors)
would remain roughly fixed.

In contrast, broadcasting would certainly increase the complexity of the
model, as evidenced by the new syntax we would need. This may or may not be
justified. Currently I am at -0.5 along with Nathaniel here.


> Indeed, I think this addition has much more justification than the `?`
> which is much more complex than the fixed size, yet neither
> particularly clear nor useful beyond the single purpose of matmul. (It
> is just that that single purpose has fairly high weight...)


Agreed, though at least in principle there is the slightly broader use of
case of handling arguments that are either matrices or column/row vectors.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20180531/d39c57db/attachment.html>