CODEWITHSUNDEEP
pythonarraysnumpyshuffle
Joe
Joe

Reputation: 913

Can I make a Numpy array immutable?

This post https://stackoverflow.com/a/5541452/6394617

suggests a way to make a Numpy array immutable, using .flags.writeable = False

However, when I test this:

arr = np.arange(20).reshape((4,5))
arr.flags.writeable = False
arr

for i in range(5):
    np.random.shuffle(arr[:,i])

arr

The array is shuffled in place, without even a warning.

QUESTION: Is there a way to make the array immutable?

BACKGROUND:

For context, I'm doing machine learning, and I have feature arrays, X, which are floats, and label arrays, y, which are ints.

I'm new to Scikit-learn, but from what I've read, it seems like the fit methods shuffle the arrays in place. That said, when I created two arrays, fit a model to the data, and inspected the arrays afterwards, they were in the original order. So I'm just not familiar with how Scikit-learn shuffles, and haven't been able to find an easy explanation to that online yet.

I'm using many different models, and doing some preprocessing in between, and I'm worried that at some point my two arrays may get shuffled so that the rows no longer correspond appropriately.

It would give me piece of mind if I could make the arrays immutable. I'm sure I could switch to tuples instead of Numpy arrays, but I suspect that would be more complicated to code and slower.

Upvotes: 2

Views: 424

Answers (1)

Warren Weckesser
Warren Weckesser

Reputation: 114911

This is a bug in numpy.random.shuffle in numpy versions 1.22 and earlier. The function does not respect the writeable flag of the input array when the array is one-dimensional.

numpy.random.Generator.shuffle has the same issue, and numpy.random.Generator.permuted fails to respect the writeable flag for arrays of any dimension.

This has been fixed in the main development branch of NumPy, so NumPy versions 1.23.0 and later will not have this bug. Note that NumPy 1.22.0 has not been released yet, but is available as a release candidate. The fix occurred after the branching of 1.22, so the fix will not be in 1.22.0.

Upvotes: 1

Related Questions