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

[stertingen]

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.

A few thoughts from my side as a user, not a library maintainer:

Well, you could just remove the conversion in case of all numpy objects in that case, not just float32.

However, I think this piece of code exists for a reason.
It was introduced in #55739, referring to https://numpy.org/neps/nep-0050-scalar-promotion.html.
It looks like scalars are converted to Python scalars in order to invoke Numpy's introspective casting behavior (inspecting the values and determining the best Numpy value for the result), as documented in NEP 50.
However, Numexpr does not have this introspective casting behavior and casts the result to float64.

So IMHO the fix would be to only cast to Python scalar when using Numpy, not when using Numexpr.

[rhshadrach]

Agreed this is a bug. I haven't looked into the details on the proposed fixes so can't give any feedback there, but PRs to fix would be welcome!