xpx.numpy brainstorming

[prady0t]

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:

  array-api-extra/src/array_api_extra/testing.py

  Line 671 in d37e011

  def _as_numpy_array( # numpydoc ignore=PR01,RT01

• 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

  array-api-extra/src/array_api_extra/_lib/_utils/_helpers.py

  Lines 146 to 151 in d37e011

  	def is_python_scalar(x: object) -> TypeIs[complex]: # numpydoc ignore=PR01,RT01
  	"""Return True if `x` is a Python scalar, False otherwise."""
  	# isinstance(x, float) returns True for np.float64
  	# isinstance(x, complex) returns True for np.complex128
  	# bool is a subclass of int
  	return isinstance(x, int | float | complex) and not is_numpy_array(x)

• 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.

Originally posted by @lucascolley in #1021

[lucascolley]

This was discussed at https://hackmd.io/zn5bvdZTQIeJmb3RW1B-8g#array_api_extranumpy-Lucas. There was a vague verdict that this indeed seems useful insofar as it will reduce the amount of custom utilities that adopting libraries need to carry around, especially when multiple of them need the same thing. There were concerns about how to determine exactly what is in or out of scope, including which other xpx.{array library} namespaces may be appropriate. Overall, it seems like we would be happy to experiment with this while being cautious to save it for things which cannot be done in an array-agnostic way.

[prady0t]

Adding a bit more to this, the discussion initially started with the addition of a @convert_to_numpy decorator to the library.

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.

A version of this decorator has already been added to GLASS, which is more suited to their needs. We need to put some effort into bringing this as a generic version inside the extra library. I'll try to open a draft PR soon for porting the decorator to the extra so that we can test it elsewhere and come up with new ideas/use cases.