ENH: add pad

[ev-br]

closes gh-69

Add an np.pad replacement, as discussed at https://github.com/scipy/scipy/pull/22122/files#r1895558533

[lucascolley]

Could you just add the array-agnostic path first in this PR? If we want to start adding dispatching to more efficient implementations for some libraries, we can consider adding that in a follow-up. I think I would rather dispatching code lived in a separate file to avoid cluttering the implementations.

There shouldn't be any need to use is_array_api_strict_namespace anywhere in this library.

[ev-br]

• np.pad is a thing
• jax.numpy.pad is a thing
• torch.nn.functional.pad is a thing
• array_api_strict.pad is not
• "generic" implementation needs mutable arrays, so is not going to work on jax.numpy

I don't understnd the request, and I though we covered this in the scipy issue.

[lucascolley]

"generic" implementation needs mutable arrays, so is not going to work on jax.numpy

Ah, okay. In which case, I think we should still just add the "generic" implementation here, then look at dispatching immediately after that. This is just one of the tricky situations we have to work with when array-api-strict is not strict enough to give us generic.

[lucascolley]

By the way, if you notice any improvements that we should make to https://data-apis.org/array-api-extra/contributing.html, would be great to hear.

[ev-br]

I think we should still just add the "generic" implementation here, then look at dispatching immediately after that.

I still don't follow. This PR is I believe what scipy needs. What is wrong with the PR, what is the request exactly?

[lucascolley]

What is wrong with the PR, what is the request exactly?

I'll push changes to show you what I mean. Currently, the other functions in this library do not use any delegation to specific array libraries. Since we want to add that in order to use this in SciPy, this PR is doing 2 things which can be quite cleanly split:

1. add a pad which is similar to all of the other existing functions - array-agnostic, tested against array-api-strict.
2. add delegation to existing libraries on top, perhaps also test with those libraries

My request was just to do (1) first here before we think about how delegation should work in array-api-extra.

[ev-br]

Ah, so the request is to rewrite the history into two commits: one for the "generic" implementation and the other with branching on namespace? This I can do easily. Or, like you said, feel free to rewrite the history here to your liking.

[lucascolley]

Not exactly - I think there is potential to be smarter about how we do delegation, similar to what you and Matt have implemented in SciPy, if we are going to open up to the possibility of delegating for all functions in this library.

[ev-br]

By the way, if you notice any improvements that we should make to https://data-apis.org/array-api-extra/contributing.html, would be great to hear.

It's great actually, thanks for the pointer.
This PR as is misses the "add to api_reference.md"; will add unless you beat me to it given #71 (comment)

[ev-br]

I think there is potential to be smarter about how we do delegation, similar to what you and Matt have implemented in SciPy, if we are going to open up to the possibility of delegating for all functions in this library.

Okay.... I'd expect something like that is an overkill for a handful of if-elif-else branches in pure python code, but this is well in the "tastes differ" territory. Am rather curious to see what you have in mind.

[lucascolley]

this LGTM now if you're happy with it! We can look at adding delegation on top next.

[ev-br]

LGTM as an intermediate step, given that it's not usable on jax and suboptimal on other backends.
If we're adding more immediately after, updating the docs can be done in that immediately after.