BUG: Unexpected behavior change in DataFrame.min(axis=1) with numpy.array elements in pandas 2.2 vs pandas 1.1

[tanjt107]

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

df = pd.DataFrame(
    {
        "A": [
            np.array([1]),
            np.array([2]),
            np.array([3]),
            np.array([4]),
            np.array([5]),
        ],
        "B": [10, 20, 30, 40, 50],
    }
)

df = df[["A", "B"]].min(axis=1)
print(df)

Issue Description

The behavior of DataFrame.min(axis=1) when a column contains numpy.array elements has changed between pandas 2.2 and pandas 1.1. I did not find any mention of this change in the changelog, and it is unclear whether this is a regression or an intentional change.

Expected Behavior

Output on pandas 1.1

0    1
1    2
2    3
3    4
4    5
dtype: float64

Output on pandas 2.2

0    [1]
1    [2]
2    [3]
3    [4]
4    [5]
dtype: object

Installed Versions

INSTALLED VERSIONS

commit : 0691c5c
python : 3.12.4
python-bits : 64
OS : Darwin
OS-release : 24.3.0
Version : Darwin Kernel Version 24.3.0: Thu Jan 2 20:24:16 PST 2025; root:xnu-11215.81.4~3/RELEASE_ARM64_T6000
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 2.2.3
numpy : 2.2.4
pytz : 2025.2
dateutil : 2.9.0.post0
pip : 25.0.1
Cython : None
sphinx : None
IPython : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : None
blosc : None
bottleneck : None
dataframe-api-compat : None
fastparquet : None
fsspec : None
html5lib : None
hypothesis : None
gcsfs : None
jinja2 : 3.1.6
lxml.etree : None
matplotlib : None
numba : None
numexpr : None
odfpy : None
openpyxl : None
pandas_gbq : None
psycopg2 : None
pymysql : None
pyarrow : None
pyreadstat : None
pytest : None
python-calamine : None
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : None
tzdata : 2025.2
qtpy : None
pyqt5 : None

[asishm]

Haven't validated, but this might have changed with #51335

[tanjt107]

I think the current behavior is more logical. However, should a bug be raised instead to avoid confusion?

[rhshadrach]

@tanjt107

should a bug be raised instead to avoid confusion?

What does it mean to "raise a bug"?

[tanjt107]

Sorry I meant raising an error in the code itself.

[rhshadrach]

Under what conditions would you suggest raising?

[tanjt107]

When comparing different dtypes (e.g., np.ndarray vs. int/float64), an error should be raised to avoid unpredictable or inconsistent behavior.

[rhshadrach]

The dtype is not np.ndarray, it is object. As far as pandas is aware any Python object can be in such a column, including a mix of NumPy arrays, scalars, and other class instances.

I am negative on adding logic to special case a column of all NumPy arrays (we would need to inspect to see that they are indeed all NumPy arrays, which is highly inefficient) and also raising on object comparisions.

[rhshadrach]

While the change in behavior was perhaps unintentional and the new behavior is perhaps somewhat surprising, it is correct as far as pandas can tell. I say perhaps surprising because bool(np.array([1]) < 10) is True, which is used to compute the min between values. However, as far as pandas is concerned the np.array([1]) is just some Python object and it would not be maintainable to special case certain types of Python objects in an object dtype column.

Closing.