MNT: avoid future incompatibility with numpy 1.25 (casting single element arrays to scalar types) - #25745

I ran the test suite locally with bleeding edge numpy installed + pytest -Werror and didn't find any other deprecation warnings. I think this now closes #25744

It would seem like the spirit of numpy's deprecation is more that we should also move towards not supporting passing single-element arrays here...

Should I throw a deprecation warning in for that case ?

Why would someone pass in a single element array here anyhow? Can we not just let numpys warning suffice?

for context, I'm not advocating that this is a reasonable use case. I've discovered this because it was triggered by the following line in yt :
https://github.com/yt-project/yt/blob/d73939ec7f13d9028cad8603f6d8302a5a61a8d8/yt/visualization/volume_rendering/transfer_functions.py#L690
... for which I also issued a patch: yt-project/yt#4422

If you guys are not interested in patching it in matplotlib, feel free to just close this alongside the issue I opened.

I think we are just trying to understand the issue to help decide the best way forward.

Why, in the linked code, would visible[0] return an array?

The ways forward are 1) work around this silently, 2) Deprecate on our end 3) just let the numpy Deprecation stand. I agree with @anntzer that we should do 2 or 3. I'd suggest we only do 2 if we think there is a reasonable use case where folks would have done this.

$ ipython
iPython 3.12.0a7+ (heads/main:4898415df7, Apr 20 2023, 18:22:31) [GCC 12.2.1 20230201]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.13.0.dev -- An enhanced Interactive Python. Type '?' for help.

In [1]: import numpy as np

In [2]: np.array(-1)
Out[2]: array(-1)

In [3]: float(np.array(-1))
Out[3]: -1.0

In [4]: float(np.array([-1]))
<ipython-input-4-6635e9e78cfc>:1: DeprecationWarning: Conversion of an array with ndim > 0 to a scalar is deprecated, and will error in future. Ensure you extract a single element from your array before performing this operation. (Deprecated NumPy 1.25.)
  float(np.array([-1]))
Out[4]: -1.0

In [5]: np.__version__
Out[5]: '1.25.0.dev0+1205.g17bae7c3f'

In [6]:

I am 👎🏻 on taking this patch. I think that single element arrays (as opposed to 0-d "arrays") ever worked in this context is an accident of numpy's implementation.

I agree with @jklymak that in the yt example something else is funny. From the names my guess is that the blah.y attribute is a (N, 1) array (so it broadcasts nicely with a (1, M) array for the x?). I suspect a better fix in yt is to do the squeeze so that values is indeed a (N, ) array earlier in the code.

Why, in the linked code, would visible[0] return an array?

good point. What's happening is that visible is created there https://github.com/yt-project/yt/blob/d73939ec7f13d9028cad8603f6d8302a5a61a8d8/yt/visualization/volume_rendering/transfer_functions.py#L639

and even though self.alpha.y is a 1D array, the result from np.argwhere is 2D (where the second dimension is 1). There's no question that I need to patch this in yt, but I wonder how likely it is that other libraries might be doing something similar and break unexpectedly (probably not very).

Again, no worries if you guys want to discard this as out of scope. :-)

I'm going to decline this PR. As I said above, that this ever worked was an accident and we should trust Numpy's judgement that this is a behavior change we want.

The right place for this to be fixed is in the call site passing this to us (either user code or other down-stream libraries).

Thank you for bringing this up @neutrinoceros . I normally say "we hope to hear from you again", but when we hear from you it is likely because we broke yt and I hope we do not do that ;)