BUG: `Rolling.skew` and `Rolling.kurt` return NaN for low-variance windows

[Alvaro-Kothe]

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 scipy.stats as st

sigma = 1e-8
mu = 0e0

window_size = 5
n = 10

rng = np.random.default_rng(505)
arr = rng.normal(loc=mu, scale=sigma, size=n)
ser = pd.Series(arr)

rolling_fns = ["skew", "kurt"]
scipy_fns = ["skew", "kurtosis"]

window = ser.rolling(window=window_size)

for method, st_method in zip(rolling_fns, scipy_fns, strict=True):
    print(method)
    pd_result = getattr(window, method)()
    scipy_fn = lambda x: getattr(st, st_method)(x, bias=False)
    scipy_result = window.apply(scipy_fn)
    df = pd.DataFrame({"Pandas": pd_result, "Scipy": scipy_result})
    print(df)
    print("=" * 80)

Issue Description

This issue is similar to #57972, where an absolute threshold in the kurtosis and skewness calculation leads to incorrect results for low-variance data, forcing the results to NaN.

SciPy's equivalent functions handle these cases correctly by computing the values without an arbitrary absolute cutoff.

The output of the example above is

skew
   Pandas     Scipy
0     NaN       NaN
1     NaN       NaN
2     NaN       NaN
3     NaN       NaN
4     NaN  0.197621
5     NaN -0.254492
6     NaN -1.230099
7     NaN -0.425309
8     NaN  0.177343
9     NaN  0.081693
================================================================================
kurt
   Pandas     Scipy
0     NaN       NaN
1     NaN       NaN
2     NaN       NaN
3     NaN       NaN
4     NaN -1.610228
5     NaN -1.808220
6     NaN  1.749034
7     NaN  1.221267
8     NaN -2.435851
9     NaN -2.686508

The first 4 rows are NaN in both due to insufficient window size, which is expected. But the remaining values in pandas should be similar to Scipy.

Expected Behavior

Pandas results should match SciPy's for indices 4-9, computing the skew and kurtosis without forcing NaN due to low variance.

Installed Versions

INSTALLED VERSIONS

commit : ea75dd7
python : 3.13.9
python-bits : 64
OS : Linux
OS-release : 6.17.5-200.fc42.x86_64
Version : #1 SMP PREEMPT_DYNAMIC Fri Oct 24 14:10:01 UTC 2025
machine : x86_64
processor :
byteorder : little
LC_ALL : None
LANG : pt_BR.UTF-8
LOCALE : pt_BR.UTF-8

pandas : 3.0.0.dev0+2592.gea75dd7b3b
numpy : 2.3.4
dateutil : 2.9.0.post0
pip : 25.2
Cython : 3.2.0b1
sphinx : 8.2.3
IPython : 9.6.0
adbc-driver-postgresql: None
adbc-driver-sqlite : None
bs4 : 4.14.2
bottleneck : 1.6.0
fastparquet : 2024.11.0
fsspec : 2025.9.0
html5lib : 1.1
hypothesis : 6.142.3
gcsfs : 2025.9.0
jinja2 : 3.1.6
lxml.etree : 6.0.2
matplotlib : 3.10.7
numba : 0.62.1
numexpr : 2.14.1
odfpy : None
openpyxl : 3.1.5
psycopg2 : 2.9.11
pymysql : 1.4.6
pyarrow : 21.0.0
pyiceberg : 0.10.0
pyreadstat : 1.3.1
pytest : 8.4.2
python-calamine : None
pytz : 2025.2
pyxlsb : 1.0.10
s3fs : 2025.9.0
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 : 3.2.9
zstandard : 0.25.0
qtpy : None
pyqt5 : None

[SoulofAkuma]

I'll give this a shot

[SoulofAkuma]

take

[SebastianGoldmann]

It looks like the results are intentionally set to NaN here.

This behavior seems to be consistent with the discussion in #18044, where it was decided that NaN is chosen to be returned due to numerically small numbers.

It might be worth revisiting whether the NaN assignment is still correct given the current logic or API expectations.

[Alvaro-Kothe]

The discussion on #18044 showed an issue with degenerate distributions, which currently is also giving wrong results, and I already raised an issue for it in #62864.

The problem in the code is that it's using absolute tolerance instead of relative tolerance. The variance scales quadratically with scaling factors. If I multiply all my data with a small number, the skewness and kurtosis shouldn't be affected, but due to this absolute tolerance I am getting NaN.

[SoulofAkuma]

I don't really understand why there are two implementations of calculating kurt and skew, which appear to use different methods. One is in _libs/window/aggregations.pyx and the other one is core/nanops.py which #62405 modified.

[Alvaro-Kothe]

@SoulofAkuma _libs/window/aggregations.pyx computes moments in a window, so you are constantly adding and removing observations and recomputing the central moments. core/nanops.py computes for the whole sample.

[SoulofAkuma]

Thanks @Alvaro-Kothe , so I guess this is for computational efficiency then. Because _libs/window/aggregations.pyx has methods called calc_kurt and calc_skew, which appear to be trying to achieve much of the same as the nanops calculation is.

[SoulofAkuma]

It appears the _libs/window/aggregations.pyx implementation has so far only cut off the second moment, but not the third for skewness and the same goes for kurtness. Also, the notation is a little confusing as the letters A to D have been chosen for the moments 1 to 4. For instance the B in skew and in kurt appears to stand for the second moment and has so far been cut off through a constant as well.

To perform the cutoff relatively and performant, like in the core/nanops.py implementation, I will have to keep track of the max value during the window calculations. I will implement this solution next week.

[SoulofAkuma]

To clarify the requirements a little. @Alvaro-Kothe do you think it'd make sense to cut off the third moment for skewness and fourth moment for kurtosis the same way that it is implemented in core/nanops.py?

[Alvaro-Kothe]

To perform the cutoff relatively and performant, like in the core/nanops.py implementation, I will have to keep track of the max value during the window calculations. I will implement this solution next week.

I was thinking of using the mean, as it's done in SciPy. The mean is available in A.

do you think it'd make sense to cut off the third moment for skewness and fourth moment for kurtosis

Not really. For me, it shouldn't even be done in core/nanops.py. You can identify degenerate distributions through the variance.