BUG: numpy.ma.fix_invalid makes changes in-place in numpy 2.1.0 even with copy=True

[kounelisagis]

Pandas version checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pandas.

• I have confirmed this bug exists on the main branch of pandas.

Reproducible Example

>>> import pandas as pd, numpy as np
>>> pd.__version__; np.__version__
'2.2.2'
'2.1.0'
>>> my_series = pd.Series([1.0, 2.0, np.nan, 0.0, 1.0])
>>> my_series
0    1.0
1    2.0
2    NaN
3    0.0
4    1.0
dtype: float64
>>> np.ma.fix_invalid(my_series)
masked_array(data=[1.0, 2.0, --, 0.0, 1.0],
             mask=[False, False,  True, False, False],
       fill_value=1e+20)
>>> my_series
0    1.000000e+00
1    2.000000e+00
2    1.000000e+20
3    0.000000e+00
4    1.000000e+00
dtype: float64

Issue Description

Copying the description of: numpy/numpy#27253

numpy.ma.fix_invalid behaves differently between NumPy 2.1.0 and NumPy 2.0.0. Specifically, when passing a pandas Series containing a numpy.nan value, numpy.ma.fix_invalid now makes changes in-place, even if the copy argument is set to its default value of True. This issue occurs only with pandas Series, not with NumPy arrays, for example.

Expected Behavior

>>> pd.__version__; np.__version__
'2.2.2'
'2.0.0'
>>> 
>>> my_series = pd.Series([1.0, 2.0, np.nan, 0.0, 1.0])
>>> my_series
0    1.0
1    2.0
2    NaN
3    0.0
4    1.0
dtype: float64
>>> np.ma.fix_invalid(my_series)
masked_array(data=[1.0, 2.0, --, 0.0, 1.0],
             mask=[False, False,  True, False, False],
       fill_value=1e+20)
>>> my_series
0    1.0
1    2.0
2    NaN
3    0.0
4    1.0
dtype: float64

Installed Versions

INSTALLED VERSIONS

commit : d9cdd2e
python : 3.11.9.final.0
python-bits : 64
OS : Darwin
OS-release : 23.5.0
Version : Darwin Kernel Version 23.5.0: Wed May 1 20:13:18 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6030
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : None
LOCALE : None.UTF-8

pandas : 2.2.2
numpy : 2.1.0
pytz : 2024.1
dateutil : 2.9.0
setuptools : 69.5.1
pip : 24.0
Cython : None
pytest : 8.3.1
hypothesis : 6.108.4
sphinx : None
blosc : None
feather : None
xlsxwriter : None
lxml.etree : None
html5lib : None
pymysql : None
psycopg2 : None
jinja2 : 3.1.4
IPython : 8.26.0
pandas_datareader : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : 2024.6.1
gcsfs : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
pyarrow : 17.0.0
pyreadstat : None
python-calamine : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
zstandard : None
tzdata : 2024.1
qtpy : None
pyqt5 : None

[rhshadrach]

Thanks for the report - this seems to be the core of the issue.

my_series = pd.Series([1.0, 2.0, np.nan, 0.0, 1.0])
arr = np.array(my_series, copy=True)
print(np.shares_memory(my_series._values, arr))
# True

[rhshadrach]

#57172 looks related.

[jorisvandenbossche]

This might be on our side that we still have to implement the copy keyword properly? -> #57739

[kevbutler]

FWIW, I have the same issue with np.nan_to_num, which would be expected if it's a broader issue.

[simonjayhawkins]

@jorisvandenbossche @seberg

are you happy to close this (and the numpy issue) as duplicate/fixed, or are additional tests needed to close.

The two code samples in this discussion are now ok on 2.3.x and main, I assume fixed by #60046.

[jorisvandenbossche]

Yes, this is indeed fixed by #60046 and will be in the upcoming pandas 2.3.0