Stabilize sliding-window smoother weights

[FlorianPfaff]

Summary

• validate smoothing window weights are finite before use
• scale finite nonnegative weights by their largest entry during construction
• preserve relative weights when a direct floating-point sum would overflow
• add a backend-aware regression through the public sliding-window smoother API

Root cause

SlidingWindowManifoldMeanSmoother stored raw window_weights and summed them directly both during construction and for each active edge window. Individually finite weights can still have an infinite sum. For example, [finfo.max, finfo.max / 2] has the well-defined ratio 2:1, but direct normalization produces [0, 0]. The subsequent Dirac distribution then rejects the zero-mass weights instead of returning the weighted manifold mean.

Fix

After shape, finiteness, nonnegativity, and positive-mass validation, scale the complete weight vector by its largest entry. The stored values are bounded by one and preserve the original ratios, so all later truncated-window sums remain finite and can be normalized safely.

Validation

• reproduced the pre-fix overflow: maximum finite weights sum to inf and direct normalization collapses to zero
• verified scale-first normalization preserves the expected 2/3, 1/3 ratio
• added a trailing-window regression where states [0, 3] smooth to 1 under extreme 2:1 weights
• compared the branch with main: two commits ahead, zero behind; only the smoother implementation and its existing test module changed

The full backend and lint matrix is delegated to GitHub Actions.

[github-actions]

✅MegaLinter analysis: Success

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ COPYPASTE	jscpd	yes		no	no	22.44s
✅ JSON	prettier	7	0	0	0	1.3s
✅ JSON	v8r	7		0	0	4.31s
✅ MARKDOWN	markdownlint	68	0	0	0	1.65s
✅ MARKDOWN	markdown-table-formatter	68	0	0	0	0.69s
✅ PYTHON	black	1489	182	0	0	86.87s
✅ PYTHON	isort	1489	328	0	0	2.52s
✅ REPOSITORY	betterleaks	yes		no	no	2.53s
✅ REPOSITORY	checkov	yes		no	no	53.0s
✅ REPOSITORY	gitleaks	yes		no	no	13.46s
✅ REPOSITORY	git_diff	yes		no	no	0.22s
✅ REPOSITORY	secretlint	yes		no	no	60.0s
✅ REPOSITORY	syft	yes		no	no	6.13s
✅ REPOSITORY	trivy-sbom	yes		no	no	6.5s
✅ REPOSITORY	trufflehog	yes		no	no	32.11s
✅ YAML	prettier	11	0	0	0	0.65s
✅ YAML	v8r	11		0	0	10.73s
✅ YAML	yamllint	11		0	0	0.51s

Notices

📣 MegaLinter 9.5.0 is out! Discover the new features and security recommendations in the release announcement. (Skip this info by defining SECURITY_SUGGESTIONS: false)

See detailed reports in MegaLinter artifacts

Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining FLAVOR_SUGGESTIONS: false)

• Documentation: Custom Flavors
• Command: npx mega-linter-runner@9.6.0 --custom-flavor-setup --custom-flavor-linters PYTHON_BLACK,PYTHON_ISORT,COPYPASTE_JSCPD,JSON_V8R,JSON_PRETTIER,MARKDOWN_MARKDOWNLINT,MARKDOWN_MARKDOWN_TABLE_FORMATTER,REPOSITORY_CHECKOV,REPOSITORY_GIT_DIFF,REPOSITORY_GITLEAKS,REPOSITORY_BETTERLEAKS,REPOSITORY_SECRETLINT,REPOSITORY_SYFT,REPOSITORY_TRIVY_SBOM,REPOSITORY_TRUFFLEHOG,YAML_PRETTIER,YAML_YAMLLINT,YAML_V8R

Show us your support by starring ⭐ the repository

[FlorianPfaff]

Current main already contains a stronger implementation of this fix: window weights are validated as finite/non-negative and every active edge-window slice is scale-normalized through two square-root-sized divisions before summation. That covers the extreme finite-weight overflow addressed here while preserving truncated-window behavior. Closing this now-conflicted branch as superseded rather than reintroducing the older construction-time scaling approach.