Conversation
|
Hi @mtsokol, thanks for extending this migration guide, it's quite helpful. Just wondering about one thing - are there any guidelines on how to handle missing components of the array API standard? For instance, in my case I would love to see #725 addressed but I know it will take time. So in the meantime, is there any suggested approach on how I should extend the API in my own project? |
|
Hi @frazane! Are you asking as an "array producer" standpoint? I believe reasonably anticipating what the API might look like once it (hopefully) lands would be the approach - nothing else comes to my mind. I see in the linked issue that for the special functions the discussion is already in an advanced state. Are you worrying that once you establish an API and the standard settles on something different then there's a churn of deprecating and communicating this to users? FWIW noting in your docstrings/API docs page which functions are array API compatible (as a |
|
Hi @mtsokol, no I am asking more from an array consumer standpoint. Very concretely, I want to be able to replace most of this with Still, the suggestion of trying to anticipate what the standard will look like is very reasonable. I suppose doing something along the lines of https://data-apis.org/array-api-extra/ also makes sense? |
|
For the special functions, I would say see how far you get calling SciPy. We delegate to PyTorch and JAX in quite a few places already, and have some fallback backend-agnostic implementations — see the ticks at https://scipy.github.io/devdocs/dev/api-dev/array_api_modules_tables/special.html#array-api-support-special-cpu. For anything else you need that isn't available in the standard or array-api-extra, feel free to open an issue on array-api-extra and we can discuss how it could be made available! |
|
And feel free to open an issue on SciPy if there is any missing coverage for |
@lucascolley review of migration guide.