BUG: dtype and NA mask not preserved when applying numpy ufuncs to an ArrowDtype Series

[tswast]

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
import numpy as np
import math

s = pd.Series(
[
      float("-inf"),
      float("inf"),
      float("nan"),
      float(-234239487.4),
      float(-1.0),
      float(-0.000000001),
      float(0),
      float(0.000000001),
      float(0.9999999999),
      float(1.0),
      float(1.0000001),
      float(math.pi / 2),
      float(math.e),
      float(math.pi),
      float(234239487.4),
      float(1.23124 * (2**70)),
      pd.NA,
],
  dtype=pd.Float64Dtype(),
)
np.sin(s)
"""
0
0	NaN
1	NaN
2	<NA>
3	-0.973067
4	-0.841471
5	-0.0
6	0.0
7	0.0
8	0.841471
9	0.841471
10	0.841471
11	1.0
12	0.410781
13	0.0
14	0.973067
15	0.948974
16	<NA>

dtype: Float64
""" 

s_pa = s.astype("float64[pyarrow]")
s_pa
"""
	0
0	-inf
1	inf
2	<NA>
3	-234239487.4
4	-1.0
5	-0.0
6	0.0
7	0.0
8	1.0
9	1.0
10	1.0
11	1.570796
12	2.718282
13	3.141593
14	234239487.4
15	1453591627092105363456.0
16	<NA>
dtype: double[pyarrow]
"""

np.sin(s_pa)
"""
0
0	NaN
1	NaN
2	NaN
3	-9.730670e-01
4	-8.414710e-01
5	-1.000000e-09
6	0.000000e+00
7	1.000000e-09
8	8.414710e-01
9	8.414710e-01
10	8.414710e-01
11	1.000000e+00
12	4.107813e-01
13	1.224647e-16
14	9.730670e-01
15	9.489736e-01
16	NaN
dtype: float64
"""

Issue Description

When I apply a numpy ufunc to a pandas Series containing ArrowDtype(pa.float64()) data, the output type ends up being a numpy float64 and the original NA mask is lost.

Expected Behavior

I would expect a ArrowDtype(pa.float64()) series to be returns and the original NA mask to be applied.

Installed Versions

INSTALLED VERSIONS

commit : 9c8bc3e
python : 3.12.12
python-bits : 64
OS : Linux
OS-release : 6.6.105+
Version : #1 SMP Thu Oct 2 10:42:05 UTC 2025
machine : x86_64
processor : x86_64
byteorder : little
LC_ALL : en_US.UTF-8
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 2.3.3
numpy : 2.3.4
pytz : 2025.2
dateutil : 2.9.0.post0
pip : 24.1.2
Cython : 3.0.12
sphinx : 8.2.3
IPython : 7.34.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.13.5
blosc : None
bottleneck : 1.4.2
dataframe-api-compat : None
fastparquet : None
fsspec : 2025.3.0
html5lib : 1.1
hypothesis : None
gcsfs : 2025.3.0
jinja2 : 3.1.6
lxml.etree : 5.4.0
matplotlib : 3.10.0
numba : None
numexpr : 2.14.1
odfpy : None
openpyxl : 3.1.5
pandas_gbq : 0.29.2
psycopg2 : 2.9.11
pymysql : None
pyarrow : 21.0.0
pyreadstat : None
pytest : 8.4.2
python-calamine : None
pyxlsb : None
s3fs : None
scipy : 1.16.2
sqlalchemy : 2.0.44
tables : 3.10.2
tabulate : 0.9.0
xarray : 2025.10.1
xlrd : 2.0.2
xlsxwriter : None
zstandard : 0.25.0
tzdata : 2025.2
qtpy : None
pyqt5 : None

[tswast]

One possible way to implement this would be to map various numpy ufuncs to their corresponding pyarrow.compute functions. For example:

import pyarrow as pa
import pyarrow.compute

pyarrow.compute.sin(pa.Array.from_pandas(s_pa))

This does preserve null values.

[jorisvandenbossche]

I am not sure how I feel about mapping to corresponding compute functions, but also I think that won't be a solution for all numpy ufuncs (there won't be an equivalent for each of them, I would assume).

In that case we would have to fix this anyway for the general case, and I think pandas should just re-apply the original mask to the result (just as we do for Float64Dtype), knowing that ufuncs should always preserve missing values and that the conversion of pyarrow to numpy converts NA to NaN, and so the original NA values will never be preserved automatically.

[jorisvandenbossche]

cc @jbrockmendel this also seems a case where the new nan_is_na behaviour on main is not yet guaranteeing to only have NAs:

>>> pd.options.mode.nan_is_na
True
>>> s = pd.Series([0.1, pd.NA], dtype="float64[pyarrow]")
>>> s
0     0.1
1    <NA>
dtype: double[pyarrow]
>>> np.sin(s)
0    0.099833
1         NaN
dtype: float64

[jbrockmendel]

this also seems a case where the new nan_is_na behaviour on main is not yet guaranteeing to only have NAs:

yep, need to update __array_ufunc__.

I am not sure how I feel about mapping to corresponding compute functions, but also I think that won't be a solution for all numpy ufuncs (there won't be an equivalent for each of them, I would assume).

For cases where there is a clear mapping, I suspect the pc versions would avoid a copy in chunked cases?