Splitting np.cross into np.cross and np.cross2d? #13718
Comments
|
Related: #13233 |
|
This Separately, I think there's a bigger thing to learn here. This is probably one of quite a few pain points for Numba. Numba has a hard job keeping up with new NumPy releases (I've been seeing a few complaints/concerns about NumPy 1.22.x not yet being supported), and it's in the interest of both projects to make it easier for Numba to implement support for NumPy functionality. We could for example make a roadmap item to prioritize and work on pain points in NumPy for Numba. The array API standard work helps a bit here (given a design principle is that everything should be JIT-compilable), however that only covers ~140 or so functions, which is ~10% of NumPy's API surface. @seibert do you happen to have a wish list? Or is this scattered over many Numba and NumPy issues plus hacks in your code base? |
xref numba/numba#8008 for a detailed write-up from the Numba team. Also see the related mailing list message I just sent to make the next step here: https://mail.python.org/archives/list/numpy-discussion@python.org/thread/QL6BTNYZC3UXBUAWMCMO7KZJTDWBBPCO/ |
This PR stems from the community meeting on Jun 5, 2024. This implements a new function cross2d that accepts (a stack of) 2-element vectors, in the same manner that cross currently does. Both np.cross2d and np.linalg.cross2d are added. The np.linalg.cross2d is API compatible. This PR closes numpy#13718 and closes numpy#26620. Units tests for cross2d are included. A new test_ValueError is added for cross. Updated doc links for both funtions. Added examples for cross2d. Cleaned up whitespace on both functions.
This PR stems from the community meeting on Jun 5, 2024. This implements a new function cross2d that accepts (a stack of) 2-element vectors, in the same manner that cross currently does. Both np.cross2d and np.linalg.cross2d are added. The function np.linalg.cross2d is Array API compatible. This PR closes numpy#13718 and closes numpy#26620. Units tests for cross2d are included. A new test_ValueError is added for cross. Updated doc links for both funtions and linked to .rst. Added examples for cross2d. Cleaned up whitespace on both functions. Adjusted examples in cross to show how to avoid deprecation warning. Adds an example to compare cross2d with (floating point) det. Includes a release note.
|
I noticed that the #26640 was closed despite having a complete implementation, because there is a one-line equivalent. But I think this is a sufficiently common functionality to still warrant it's own function. The biggest benefit of a standalone function is that it's much easier to remember than the expansion (I can remember the right hand rule but I can never remember the order of the terms). There's also the matter of custom axes which is a simple keyword argument in the function without requiring complex indexing. |
|
In fact, there is no good one-line equivalent. The proposed one-line equivalent only works if you have actual variables. If the inputs are expressions, then the proposed one-liner would need to compute the inputs twice, which is unacceptable. I know, in modern python you could spell that one-liner as cross2d = (arr1 := EXPR1)[..., 0] * (arr2 := EXPR2)[..., 1] - arr1[..., 1] * arr2[..., 0]but I'm sure that this wouldn't pass most code-guidelines. And this hasn't even started tackling the |
A Numba contributor has been working on adding support for
np.crossto Numba (numba/numba#4128), and this raised the issue thatnp.crosshas an unusual type signature. It feels like two related, but distinct functions have been glued together:A gufunc-like function that returns 3D vector cross products of 3D vector inputs, with the convenience feature to assume a zero z-component if the final dimension of (only) one of the input arrays has length 2. The number of dimensions of the output is equal to the number of dimensions on the inputs.
A different gufunc-like function that returns the z component of the 3D vector cross product of 2D vector inputs. This is only selected if both inputs have length two in their last dimension. The number of dimensions on the output is one less than the number of dimensions of the inputs.
Aside from making the documentation of this function confusing (it took me several tries to understand these two modes, assuming I'm not still confused), it also makes it not possible to write a Numba type signature for this function because the number of returned dimensions depends on the exact length of the last dimension on each input. (Numba considers ndim, layout, and dtype part of the array type for purposes of code generation, but not the actual contents of shape.)
One could argue this is a Numba problem rather than a NumPy problem, but we suspect that attempts to construct a typing hinting system (like https://github.com/numpy/numpy-stubs) for NumPy functions that describes the relationship between input and output dimensions will also trip over
np.cross. Our workaround in Numba will be only support mode #1 above, and create a separatenumba.cross2dfunction that does mode #2, and raise compilations to direct users to the right one.For similar reasons, adding a
np.cross2dto NumPy might be a useful way to evolve toward an easier to understandnp.crossand also make type hinting possible, although backward compatibility would require supporting both modes innp.crossfor some time.It is also totally fair to mark this as WONTFIX because this ship has already sailed. :)
The text was updated successfully, but these errors were encountered: