array-api-compat (and maybe the array API itself) isn't quite ready for this. We'll re-asses after the next array-api-compat release.

How come this is closed?

This PR had to add some shims for things which have only recently been added to the standard like diff, moveaxis and take_along_axis. Once array-api-compat supports those features we won't need the shims here so the PR will be cleaner.

In theory we could merge this with the shims, but I suppose it was judged better to prioritise other things from a developer-churn perspective.

Thanks for the explanation. I see why the PR isn't going to be included (or specifically, isn't efficient to include given the bigger architectural picture).

I guess I'm looking for the issue to keep track of the stats.rankdata request, as a couple of few other stats functions are waiting for that (#20544).

If you keep watching this PR, we'll try to make some noise here when work is resumed on rankdata (in this PR or elsewhere).

I think this is possible to revive now that the standard has take_along_axis and diff. We can use put_along_axis with NumPy and do a second argsort for other backends.

I think this is possible to revive now that the standard has take_along_axis and diff. We can use put_along_axis with NumPy and do a second argsort for other backends.

Thanks @mdhaber !

Looking forward to mannwhitneyu 😛

I'm guessing it will be ready in 1.17 if all goes well.

Failures are unrelated.

Thanks @j-bowhay. Would you test locally and see if you're getting an error with JAX (when you remove it from the list of incompatible backends)? I haven't seen that one before.

@j-bowhay Looks like I needed to set jax_jit=False; test is passing with JAX now!

Thanks @j-bowhay @lucascolley for the reviews!

That just emphasizes the need for this function; it's not entirely trivial to get 100% right.

I somewhat agree, although it really depends on how widespread use of np.swapaxes with identical and/or negative axes is. We surely can't introduce helpers into xpx for every single quirk of NumPy. If we hit it again (or better, some other project does), that is probably a strong reason to go ahead with the implementation.

for every single quirk of NumPy

Sure. Just thought I'd note that the failure with identical axes in moveaxis is for all backends and required by the standard. Also repeated axes will be common for arrays that happen to be 1D or wherever you're swapping axes to simplify implementation and axis happens to already be there.