Repository navigation
fix(marginal): keep Gauss-Hermite weights finite for q >= 371 (#2110) - #2354
seonghobae wants to merge 1 commit into
Conversation
numpy hermegauss overflows its weight formula from q = 371, so marginal._gh returned NaN weights for study-setting node counts. Return the normalized hermegauss rule unchanged where it is finite and fall back to the Golub-Welsch Jacobi eigen-rule the Rust core uses otherwise. No node-count cap (#1929).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configuration
📒 Files selected for processing (3)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe change adds a shared probabilists’ Gauss–Hermite helper with a Golub–Welsch fallback. The marginal estimator delegates node and weight generation to the helper. New tests cover high node counts, numerical properties, lower-count equivalence, and invalid counts. ChangesGauss–Hermite quadrature
Priority: ➖ Normal Estimated code review effort: 3 (Moderate) | ~20 minutes Change: Bug fix Merge Risk: ⚪ Minimal · up to No actionable issue remains before merge, subject to normal test and lint checks. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches 💡 2📝 Generate docstrings 💡
🛠️ Fix failing CI checks 💡
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Fixes the
marginal._ghpart of #2110.Problem
numpy.polynomial.hermite_e.hermegaussoverflows its weight formula from q = 371 (numpy 2.5.3). The weights then sum to 0 or NaN, somarginal._ghreturned NaN weights._ghfeeds the NumPy marginal estimators,fitstatsandlinking, so any of them evaluated at a study-setting node count of 371 or more got NaN quadrature.Change
fast_mlsirm/_gauss_hermite.py::probabilists_gauss_hermite(q).hermegaussrule is finite, it returns that rule unchanged, so results for q <= 370 stay bit-identical.quadrature.rs::gauss_hermite_probabilists(alpha_k = 0, beta_k = k, symmetrized, unit-sum weights).quadrature.rs.marginal._ghcalls the helper. The incorrect comment that hermegauss handles any q is removed. There is still no node-count cap (fix(quadrature): remove unsourced numeric defaults for quadrature node counts in monotonicity/bifactor APIs #1929).Not in this PR
estimators/mmle.py::gauss_hermite_nodesvalidatesn_nodes <= MAX_GAUSS_HERMITE_NODES = 100, so it cannot reach q >= 371 today. That cap itself conflicts with the fix(quadrature): remove unsourced numeric defaults for quadrature node counts in monotonicity/bifactor APIs #1929 maintainer rule. Removing it changes a public validation contract, so it should be a separate decision.polytomous.pystays out of scope; it belongs to fix(polytomous): finite Gauss-Hermite rule for high q in monotonicity checks #2109.Verification (local, Python 3.12, numpy 2.5.3, macOS arm64)
tests/test_gauss_hermite_high_q.pygave 6 failed / 9 passed. Every q >= 371 case failed with non-finite weights.hermegauss.Summary by CodeRabbit