BUG: Implicit upcast to float64 for large series (more than 1000000 rows)

[stertingen]

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

a = pd.Series(np.zeros(1000000), dtype="float32") + np.float32(1)
b = pd.Series(np.zeros(1000001), dtype="float32") + np.float32(1)
print(a.dtype, b.dtype)

Issue Description

Performing binary operations on larger Series with dtype == 'float32' leads to unexpected upcasts to float64.
Above example prints float32 float64.
Using to_numpy() on the series before addition inhibits the implicit upcast.

Expected Behavior

I expect above snippet to print float32 float32.

Installed Versions

INSTALLED VERSIONS ------------------ commit : c888af6 python : 3.12.10 python-bits : 64 OS : Windows OS-release : 11 Version : 10.0.26100 machine : AMD64 processor : Intel64 Family 6 Model 165 Stepping 2, GenuineIntel byteorder : little LC_ALL : None LANG : None LOCALE : de_DE.cp1252

pandas : 2.3.1
numpy : 2.1.3
pytz : 2025.2
dateutil : 2.9.0.post0
pip : 25.1.1
Cython : 3.1.2
sphinx : None
IPython : 9.4.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.13.4
blosc : None
bottleneck : 1.5.0
dataframe-api-compat : None
fastparquet : None
fsspec : 2025.7.0
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : 3.1.6
lxml.etree : None
matplotlib : 3.10.3
numba : 0.61.2
numexpr : 2.11.0
odfpy : None
openpyxl : 3.1.5
pandas_gbq : None
psycopg2 : 2.9.10
pymysql : None
pyarrow : 20.0.0
pyreadstat : None
pytest : None
python-calamine : None
pyxlsb : None
s3fs : None
scipy : 1.16.0
sqlalchemy : 2.0.41
tables : None
tabulate : 0.9.0
xarray : None
xlrd : None
xlsxwriter : None
zstandard : 0.23.0
tzdata : 2025.2
qtpy : None
pyqt5 : None

[stertingen]

After stepping through with a debugger, I have the following insights to share:

With series larger than 1000000 items, Pandas uses NumExpr.
Also, pandas converts the numpy float32 scalar to a Python floating point number in ops.maybe_prepare_scalar_for_op.
Then, NumExpr behaves as described in https://numexpr.readthedocs.io/en/latest/user_guide.html#casting-rules, assuming a double precision floating point value.

[allecole]

Hi, I'd like to tackle this issue, I am new to the project, but I agree that the conversion to the Python float is causing this bug. A fix I could implement would be to remove the use of float() in order to preserve type [as it is being converted to a Python float].

This code inside[ _array_ops.py]

    elif isinstance(obj, np.floating):
        return float(obj)

Should return a float32 scaler instead, by removing the assertion:

    elif isinstance(obj, np.floating):
        if obj.dtype == np.float32:
            return obj
        else:
            return float(obj)

I will test this within my own fork prior to making a PR.

[allecole]

take