BUG: Fix segfault in random.permutation(x) when x is a string.

[maxwell-aladago]

Reference #14238

I made the assumption that anyone who passes a string x to the function np.random.permutation(x) most likely intend to shuffle the string in question. I suggest that if this isn't the desired behaviour, then I can flag an error instead of the segfault.

[seberg]

To be honest, I do not think I like to special case strings like that. This also does not fix the undrelying segmentation fault, since the same error will still happen for example for floating point input.

The underlying issue is the cython boundscheck=False directive, which also applies to tuples. Either, we have to mark this (and possibly some other places) expliciteley using:

with cython.boundscheck(True):
    ...

or the other way around (could probably also mark the whole function).

Maybe the best option here specifically is to just raise a new ValueError("permutation of a 0 dimensional array is not defined.") or something nicer.

[rkern]

The old behavior is to raise an IndexError. We should probably do just that for RandomState.permutation(). We can think about what we want for Generator.permutation('some_string'), but we should have the IndexError as a backstop for Generator.permutation(1.5), etc.

[~]
|1> np.random.permutation('abc')
---------------------------------------------------------------------------
IndexError                                Traceback (most recent call last)
<ipython-input-1-eab1612dcd44> in <module>()
----> 1 np.random.permutation('abc')

mtrand.pyx in mtrand.RandomState.permutation()

IndexError: tuple index out of range

[seberg]

Hmm, right, at least for the legacy API its probably better to err on the save side. Another option, which works for both is to use np.AxisError (since effectively there is an axis=0 going on, even if the user cannot set it). That error subclasses from IndexError and ValueError for exactly that backward compatibility concern.

[maxwell-aladago]

Thanks for the feedback. The issue about floating point numbers is true. Will you consider a PR for an np.AxisError or you'll prefer an explicit cython bounds check? @seberg

[seberg]

Raising an error explicitly is good, I do not mind much either way, but I feel AxisError may be nicer than IndexError.
If you have time, we may want to check the file for similar issues (e.g. bad Axis input that used to raise an IndexError automatically, and now will segfault).

[maxwell-aladago]

Raising an error explicitly is good, I do not mind much either way, but I feel AxisError may be nicer than IndexError.
If you have time, we may want to check the file for similar issues (e.g. bad Axis input that used to raise an IndexError automatically, and now will segfault).

I do have some time. Will look at the bad Axis input too.

[eric-wieser]

My claim would be that AxisError is only correct if you can trigger it via a sane call to normalize_axis_index

[maxwell-aladago]

My claim would be that AxisError is only correct if you can trigger it via a sane call to normalize_axis_index

A check like

'.normalize_axis_index(0, arr.ndim)` will trigger an AxisError! And I think it's sane enough since intuitively, we expect all permutable inputs to be either ints or have at least 1 axis

[mattip]

Please revert the whitespace additions

[seberg]

The spurious space is still there.

[WarrenWeckesser]

Still there. @maxwell-aladago, the space added at the end of this line should not be there.

[anntzer]

fwiw I think this should raise an error: this would be consistent with np.random.choice("abcd") which currently raises an error -- in fact, this would even be consistent with np.asarray("abcd") returning a scalar array of dtype <U4 rather than a shape-(4,) array.

[maxwell-aladago]

fwiw I think this should raise an error: this would be consistent with np.random.choice("abcd") which currently raises an error -- in fact, this would even be consistent with np.asarray("abcd") returning a scalar array of dtype <U4 rather than a shape-(4,) array.

np.random.choice("abc") currently gives a ValueError whereas
np.random.permutation("abc") results in a segfault. The current patch ensures it throws a sensible np.AxisError. To be consistent with np.random.choice("abc"), we'll have to update the patch to throw a ValueError instead.

[WarrenWeckesser]

Wouldn't a TypeError or ValueError be more appropriate? The argument for raising AxisError is not very strong, whereas the text added to the exception message, "x must be an integer or an array_like object.", suggests that the exception should be a TypeError or a ValueError.

[maxwell-aladago]

Wouldn't a TypeError or ValueError be more appropriate? The argument for raising AxisError is not very strong, whereas the text added to the exception message, "x must be an integer or an array_like object.", suggests that the exception should be a TypeError or a ValueError.

Changed it to ValueError

[eric-wieser]

ValueError is fine. If we added an explicit axis argument, then we can switch to AxisError then, especially since issubclass(AxisError, ValueError).

[rkern]

The appropriate comparison is not np.random.choice() but the 1.16 behavior of np.random.permutation(), which, as noted above, raises an IndexError.

[seberg]

I think the last case we could just stick with raising an error, but either will work. While we do generally allow 0D arrays instead of scalars, the function is overloaded in a way that I think it would be fair to assume it is unintentional when it happens. Plus 0D arrays are exceedingly rare in any case.

[maxwell-aladago]

Another question about fixing this issue. To what extent do we expect a scalar array (i.e. a zero-dimensional array) to act like an instance of its underlying dtype? Currently, the seg. fault occurs when a zero-dimensional array is passed to permutation:

In [2]: import numpy as np                                                                                                         

In [3]: rng = np.random.Generator(np.random.PCG64())                                                                               

In [4]: rng.permutation(5)                                                                                                         
Out[4]: array([0, 3, 4, 1, 2])

In [5]: rng.permutation(np.int64(5))                                                                                               
Out[5]: array([2, 1, 4, 3, 0])

In [6]: rng.permutation(np.array(5))                                                                                               
Segmentation fault: 11

Should that last case act the same as the previous two, and return a permutation of range(5)?

my patch actually fixed the case for 'np.random.permutation(np.array(5))

[eric-wieser]

I don't think we should use IndexError for the new Generator objects on a compatibility argument - part of the point of the new API was to allow us to break compatibility. ValueError was in my opinion more appropriate.

[maxwell-aladago]

I don't think we should use IndexError for the new Generator objects - part of the point of the new API was to allow us to break compatibility. ValueError was in my opinion more appropriate.

So, you want me to roll it back to ValueError? @eric-wieser. ValueError looks right to me too because it really isn't an indexing problem.

[rkern]

Ah, per the PR title, I thought we were talking about np.random.permutation() which is RandomState.permutation(). Do what you like with Generator.permutation(). AxisError would be the best exception there (and Generator.choice() to match) in the cases that you don't want to handle specially.

But it seems like this PR does not fix RandomState.permutation(), so np.random.permutation() remains unfixed as well. That still segfaults. The proper fix there is to raise an IndexError to match 1.16 behavior.

[maxwell-aladago]

Ah, per the PR title, I thought we were talking about np.random.permutation() which is RandomState.permutation(). Do what you like with Generator.permutation(). AxisError would be the best exception there (and Generator.choice() to match) in the cases that you don't want to handle specially.

But it seems like this PR does not fix RandomState.permutation(), so np.random.permutation() remains unfixed as well. That still segfaults. The proper fix there is to raise an IndexError to match 1.16 behavior.

Fixes both RandomState.permutation() and Generator.permutation() now. Let me know whether this is a good fix @rkern so I can change change the Generator.choice() to match too.

[WarrenWeckesser]

@rkern wrote

Do what you like with Generator.permutation(). AxisError would be the best exception there (and Generator.choice() to match) in the cases that you don't want to handle specially.

What is the rationale for raising an AxisError instead of a ValueError? For an input such as x=1.5, is it something like "The argument must be int or array_like. If the argument is not, in fact, an int, then it must be array_like, and when we try to use the first axis of the scalar 1.5 we get an AxisError"?

[seberg]

The spurious space is still there.

[seberg]

Not sure an error example helps too much here, but maybe if someone thinks they can shuffle strings or similar objects.

[rkern]

What is the rationale for raising an AxisError instead of a ValueError?

Broadly speaking, we are expecting to be indexing along the first of >=1 axes, in the usual case. The integer semantic branch complicates that, and the message should incorporate information about that, but I think that AxisError is the most reasonable (as it is both a ValueError and an IndexError).

[charris]

The refguide check is failing.

[charris]

Everyone good with this?

[charris]

@maxwell-aladago Could you make another PR against 1.16.x that only makes the fixes/tests for RandomState?

[rkern]

I don't think there's a segfault in 1.16. It was introduced in 1.17.

[charris]

I don't think there's a segfault in 1.16. It was introduced in 1.17.

Ah, just checked and you are right.

[seberg]

Did anyone check for other similar errors, or should I go through it?