BUG: Incorrect results for pandas.Series.var

[thanhlecongg]

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
from pandas.core import nanops

a_with_nan = np.array([1+2j, 2+3j, 3+4j, np.nan + 0j], dtype=np.complex128)

s = pd.Series(a_with_nan)
var = s.var(ddof=1)
print(var) # 15.5

a_without_nan = np.array([1+2j, 2+3j, 3+4j], dtype=np.complex128)
s = pd.Series(a_without_nan)
var = s.var(ddof=1)
print(var) # 15.5

# Reference result from numpy
print(a_without_nan.var(ddof=1)) # 2.0

# My manual calculation: 2.0

Issue Description

pandas.Series.var seems to produce incorrect results for complex arrays. I did a cross-check between the output of pandas.Series.var, my own manual calculations, and the results obtained from NumPy, and found that pandas.Series.var yields different results from both my manual and numpy calculation. I have traced back to issues of pandas and found that this issue relate to issue #61645, which was fixed in PR #61646. However, the fix seems to only correct the sign of the output values to ensure that it is positive, rather than addressing the root cause. I think that the root cause lies in this line, where the computation of avg forced the value to be cast to float64. Indeed, numpy raises the following warnings:

ComplexWarning: Casting complex values to real discards the imaginary part
  return umr_sum(a, axis, dtype, out, keepdims, initial, where)

Expected Behavior

Both my manual and numpy calculation yields a same result of 2.0 but pandas.Series.var return 15.5 for [1+2j, 2+3j, 3+4j] with ddof of 1

Installed Versions

pandas: 3.0.0.dev0+2421.ge79f1565e6
numpy: 2.2.3

I also tested with pandas 2.3.2 as well

[pandeconscious]

take

[pandeconscious]

I am able to reproduce with the above examples that the results between numpy (2.3.3) and pandas (2.3.2) are inconsistent

[pandeconscious]

However on the later pandas version 3.0.0.dev0+2433.gf6fa9b6790, I notice that this issue is not present, see my run below:

>>> import pandas as pd
>>> import numpy as np
>>> from pandas.core import nanops
>>> 
>>> a_with_nan = np.array([1+2j, 2+3j, 3+4j, np.nan + 0j], dtype=np.complex128)
>>> 
>>> s = pd.Series(a_with_nan)
>>> var = s.var(ddof=1)
>>> print(var) # 15.5
2.0
>>> 
>>> a_without_nan = np.array([1+2j, 2+3j, 3+4j], dtype=np.complex128)
>>> s = pd.Series(a_without_nan)
>>> var = s.var(ddof=1)
>>> print(var) # 15.5
2.0
>>> 
>>> # Reference result from numpy
>>> print(a_without_nan.var(ddof=1)) # 2.0
2.0
>>> 
>>> # My manual calculation: 2.0
>>> s
0    1.0+2.0j
1    2.0+3.0j
2    3.0+4.0j
dtype: complex128
>>> s.var(ddof=1)
np.float64(2.0)
>>> pd.__version__
'3.0.0.dev0+2433.gf6fa9b6790'

@thanhlecongg do you see this issue in the latest version? If not, we need to close this issue I guess

[thanhlecongg]

@pandeconscious I have install pandas in the latest commit of pandas but the issue still the same. My version is 3.0.0.dev0+2434.g9100696da9. My commit hash I used is it 9100696. I believe that it is the latest commit in pandas repo.

[thanhlecongg]

It is quite weird. I have checkout your version and still found the mismatches.

[thanhlecongg]

This is my full enviroment for your reference:

INSTALLED VERSIONS

commit : f6fa9b6
python : 3.12.6
python-bits : 64
OS : Darwin
OS-release : 24.6.0
Version : Darwin Kernel Version 24.6.0: Mon Jul 14 11:30:29 PDT 2025; root:xnu-11417.140.69~1/RELEASE_ARM64_T6000
machine : arm64
processor : arm
byteorder : little
LC_ALL : None
LANG : en_US.UTF-8
LOCALE : en_US.UTF-8

pandas : 3.0.0.dev0+2433.gf6fa9b6790
numpy : 2.2.3
dateutil : 2.9.0.post0
pip : 24.2
Cython : 3.1.4
sphinx : None
IPython : None
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.13.4
bottleneck : 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
psycopg2 : None
pymysql : None
pyarrow : None
pyiceberg : None
pyreadstat : None
pytest : 8.4.1
python-calamine : None
pytz : 2025.1
pyxlsb : None
s3fs : None
scipy : None
sqlalchemy : None
tables : None
tabulate : None
xarray : None
xlrd : None
xlsxwriter : None
zstandard : 0.23.0
qtpy : None
pyqt5 : None
None

[pandeconscious]

I can't reproduce this, probably it is arm-related, so I won't be able to test it because I don't have access to arm. If someone has access to arm, probably they can try to fix it.

[shaurya5]

take