Decorator for input output conversion array-api porting

[connoraird]

Is Your Feature Request Related to a Problem? Please Describe

Created from this discussion.

There are several functions which have proven difficult to port to the array api. When this is the case we have resorted to simply converting inputs to Numpy and outputs back to the input backend.

Describe the Solution You'd Like

It would be good to have this functionality added as a decorator which would prevent us from having to manually convert inputs and outputs.

[prady0t]

Hi,

I believe something like this could be helpful for GLASS as well as other packages with similar workarounds (like SciPy). @lucascolley Would we be willing to add something like this to array_api_extra?

[lucascolley]

I had a rough idea that things like this could belong in a new array_api_extra.numpy namespace, which would be enabled by an optional extra with a numpy dependency.

Some other things that could potentially live in such a namespace:

• _as_numpy_array: https://github.com/data-apis/array-api-extra/blob/d37e0112918f8ac6eac5c62ef93e2af48a1c0c36/src/array_api_extra/testing.py#L671
• a version of array_namespace which falls back to np.asarray for non-array input: https://github.com/scipy/scipy/blob/94070c2f3540a1a949876ca61c5f877212874e90/scipy/_lib/_array_api_override.py#L73
• is_python_scalar, a boolean check which excludes NumPy scalars https://github.com/data-apis/array-api-extra/blob/d37e0112918f8ac6eac5c62ef93e2af48a1c0c36/src/array_api_extra/_lib/_utils/_helpers.py#L146-L151
• isscalar, a boolean check for NumPy scalars OR 0-D arrays https://github.com/scipy/scipy/blob/94070c2f3540a1a949876ca61c5f877212874e90/scipy/_lib/_array_api.py#L1184-L1185
• a version of asarray with extra params like order, check_finite, subok, which are only effective for NumPy https://github.com/scipy/scipy/blob/94070c2f3540a1a949876ca61c5f877212874e90/scipy/_lib/_array_api.py#L76-L120
• sklearn has a util for retrieving the matching NumPy dtype for an array: https://github.com/scikit-learn/scikit-learn/blob/9888db252fbc4c526d9ba9632caacf958ba4753c/sklearn/utils/_array_api.py#L1433-L1441

This would be a namespace of things that are useless for new libraries which can adopt the standard from the get-go, but that are helpful for existing libraries written against NumPy that need to transition.

If people agree, then we could think about this some more, but it should definitely be discussed in one of the public array API community meetings if so.

[paddyroddy]

I like the sounds of this. But, as you say, how much use will it have? It will take a long time before every array consuming library adopts to the standard.

For our use case, a decorator (or the modified array_namespace) will be neater rather than a bunch of numpy.asarray hanging around.

[prady0t]

Some other things that could potentially live in such a namespace:

This sounds great, but we would definitely need more discussion. Happy to open a tracking issue for it in the array_api_extra repo.

For GLASS, I'm willing to work on creating a decorator for the specified use case. If we later decide to adopt it in the extra module, we would be able to use it as a reference.

[lucascolley]

how much use will it have? It will take a long time before every array consuming library adopts to the standard.

it's a gradual process indeed, but minimising the amount of custom utils that adopting libraries need to carry around will probably help speed up adoption

[paddyroddy]

For GLASS, I'm willing to work on creating a decorator for the specified use case. If we later decide to adopt it in the extra module, we would be able to use it as a reference.

No obligation! But if you'd like to play around then PRs welcome

[prady0t]

Here is a list of functions that can benefit from the decorator:

• iternorm()
• generate()
• alm2map()
• alm2map_spin()
• almxfl()
• ang2pix()
• ang2vec()
• map2alm()
• rotate_map_pixel()
• solve()