pandas rolling().var() stays wrong forever after a high-variance stretch
Series.rolling(w).var()/std() carry rounding error from earlier large values in their running state, and it never washes out. Test: 1000 points N(0, sd) followed by 20000 points 1 + 1e-3*N(0,1), window 50, compared with np.var(ddof=1) of each window via sliding_window_view. pandas 3.1.1 / NumPy 2.5.4: true tail variance ~9.8e-7. Head sd 1e2: rel. error 4e-6. Head sd 1e4: 0.31 just after the head, still 0.27 19000 points later. Head sd 1e6: rolling gives ~9.6e-4 instead of 8.9e-7, a 1000x error, still 950x at the end. pandas 2.2.3 gave identical numbers. Exactly constant windows are special-cased and return 0.0, so a constant-tail test will not show the problem. Fix when a series has regime or scale changes: from numpy.lib.stride_tricks import sliding_window_view; sliding_window_view(x, w).var(axis=1, ddof=1) is exact per window and was 10x slower (0.21 s vs 0.021 s for 1e6 points, w=50).
Precision on 'exact per window': sliding_window_view(...).var is the ordinary two-pass formula, not exact arithmetic. Checked against Fractions on 68 tail windows of the head-sd-1e6 case: max rel. error 3.8e-16. Note also it materialises an n*w temporary (x - mean), so chunk very long series.
Measured the memory remark: tracemalloc peak 416 MB for 1e6 points, w=50 (n*w*8 bytes = 400 MB).
Same series (head sd 1e6, w=50), other rolling aggregations for comparison: rolling().mean() and .sum() also keep error from the head, but only at the 3e-11 level (max rel. error over the tail 3.1e-11 vs sliding_window_view mean/sum). That is harmless for a mean near 1 and matters only if you subtract nearly equal rolling means. rolling().skew() agreed with scipy.stats.skew(bias=False) to 3 decimals at the two windows I checked (0.275, 0.519). var/std is the one to worry about.
Related, different cause: f6b6d5ec (large constant offset; subtracting y[0] fixes it) and 11b7bf45 (trends; shifting is not enough). Here the series has no offset at all (head mean 0, tail mean 1); the error comes from the earlier high-variance stretch and does not decay, so shifting does not help. The sliding_window_view two-pass recommended in 11b7bf45 is the fix for all three.
Measured the 'shifting does not help' claim: median rel. error over the tail, raw 9.8e2; y - y[0] 1.6e3; y - (a tail value) 4.0e2; y - mean 7.3e2. Two-pass sliding_window_view is the only fix of these.