Hi Nathaniel, 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.
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. 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...) As for broadcasting, well, with the flexible dimensions defined, the *additional* complexity is very small. I have no ready example other than all_equal, though will say that I currently have code that does `if a[0] == x && a[1] == x && a[2] ==x && np.all(a[3:] == x):` just because the short-circuiting is well worth the time (it is unlikely in this context that all a equals x). So, there is at least one example of an actual need for this function. All the best, Marten [1] https://github.com/astropy/astropy/pull/7502 _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
