BUG: accept np-coercible array-likes with array API flag set

[lucascolley]

Reference issue

Closes #19118.

What does this implement/fix?

compliance_scipy is modified to accept array-likes by coercing with np.asanyarray. Previously, they were rejected, which is unwanted for backwards compatibility reasons.

Additional information

This implementation may be suboptimal - I'm not confident that creating a new tuple and using try except is the right thing to do. But this seems to have the desired behaviour.

A follow-up may come in the future as @mdhaber has expressed a want to sometimes accept certain types of array like Masked arrays.

[lucascolley]

CI has caught that we are still testing for array-like denial. I'll remove the check now. (Maybe we want to check that they are accepted?)

[mdhaber]

Maybe we want to check that they are accepted?

Sounds good to me.

[lucascolley]

Edit: will the try except stop the correct TypeError being raised?

@mdhaber I've addressed your comments, I think this is correct?

[mdhaber]

Close, but you need to loop over the indices of the list if you want to modify it. Right now, you are just redefining the array variable, but this does not change the list.

for i in range(len(arrays)):
    array = arrays[i]
    ...
    arrays[i] = ...  # to modify list element

and technically, you don't even need to return arrays (although it's probably not a bad idea to do so to be explicit that it's modified).

You could also try:

for i, array in enumerate(arrays):
    ...
    arrays[i] = ...  # to modify list element

Although a linter or mypy might not like it.

---

The rest of the changes LGTM but you might add a test that when objects are coerced to object arrays, the new error is emitted. Nit: to save a level of indentation, you could put the object dtype check after the try-except block rather than within the try.

Also @rgommers should character arrays continue to be let through?

[lucascolley]

Close, but you need to loop over the indices of the list if you want to modify it

My most recent commit has tried to address this.

add a test that when objects are coerced to object arrays, the new error is emitted.

Can you give me an example input that would be coerced to an object array?

[rgommers]

Also @rgommers should character arrays continue to be let through?

Good question. I hadn't given that any thought before, because I can't remember a single bug report about them. However, I think there is value in defining more clearly what dtypes are accepted. I'd say it should be only boolean and numerical dtypes (signed/unsigned integer and real/complex floating-point dtypes). Would you agree with that?

[mdhaber]

Can you give me an example input that would be coerced to an object array?

Sure.

import numpy as np
from scipy import stats

x = np.asanyarray([object()])
x.dtype  # dtype('O')

y = np.asanyarray(stats)
y.dtype  # dtype('O')

Would you agree with that?

After mode stopped supporting non-numerical arrays, I can't think of functions that should support non-numerical types. So yes, I think we can restrict to subdtypes of np.number and np.bool_.

[lucascolley]

thanks Matt, hopefully that's everything now.

restrict to subdtypes of np.number and np.bool_

Unless we want to include that in here too.

[mdhaber]

Unless we want to include that in here too.

That would be nice. @rgommers are we going to be bothered by the overhead of np.issubdtype? It's probably the slowest thing in this function, and in the simplest implementation, it would be called twice per argument.

import numpy as np
x = np.asanyarray(['a'])
%timeit np.issubdtype(x.dtype, np.flexible)  # 646 ns ± 2.71 ns per loop (mean ± std. dev. of 7 runs, 1,000,000 loops each)

Or @rgommers feel free to merge as is and we can consider it in a follow-up.

[tylerjereddy]

I spent some time reading over the diff/discussion and ensuring that these produce sensible results on this branch (modulo: gh-19194 ):

• SCIPY_DEVICE=cuda python dev.py test -j 32 -b all
• python dev.py test -j 32 -b all

Seems good for my local case with GPU and associated libs locally.

I think we can postpone the refinement of acceptable type coercions to a separate PR, and indeed that would probably be easier to review separately, at least for me.

Matt ok with merging as-is with follow-up

[rgommers]

The overhead of ~650 ns is quite a bit, so we may have to optimize this later. But it's not a big worry for now - we can circle back to that once it start showing up in profiling results.