rseng-numerical-accuracy
SolidCovers floating-point correctness in research code: why 0.1 + 0.2 != 0.3, choosing absolute vs relative tolerances in tests, accumulation error and safe summation, precision choices (float32 vs float64), catastrophic cancellation, NaN and infinity handling, and cross-platform or cross-library result drift. Use PROACTIVELY when floating-point comparisons fail mysteriously, when writing numerical tests or choosing tolerances, when results differ across machines, compilers, BLAS builds or library versions, or when precision or numerical stability questions arise in analysis or simulation code.
Install
Quality Score: 83/100
Skill Content
Details
- Author
- fdiblen
- Repository
- fdiblen/rseng-agent-skills
- Created
- 4 days ago
- Last Updated
- 4 days ago
- Language
- Python
- License
- MIT
Similar Skills
Semantically similar based on skill content — not just same category
rseng-defensive-coding
Covers defenses against silently wrong research results: validating data at boundaries (schemas, assertions, sanity checks), explicit physical units and quantities in code (pint/astropy-style), disciplined randomness (explicit seeded generators, parallel streams), and fail-loud handling of NaN and missing data. Use PROACTIVELY when code ingests external or instrument data, when values carry physical units, when randomness enters simulations or sampling, or when NaN or missing-data handling is implicit; also when the user mentions data validation, unit errors, seeds or silent bugs, or reviews analysis code whose failure would be invisible. For floating-point behavior and tolerances see rseng-numerical-accuracy; for diagnosing an existing bug see rseng-debugging.
integer-issues
Detect integer over/underflow in `unchecked` blocks, downcasting losses, fixed-point precision errors, division-before-multiplication, signed/unsigned mixing. Activate on any arithmetic in `unchecked { }`, `SafeCast`, `uintN(uintM(x))` casts, division and modulo, percentage/basis-points math, AMM share/asset math.
state-the-noise-floor
Before you put a NUMBER in front of a maintainer — "N tickets affected", "X% of cases", "this run is 13% slower" — establish what that same number would be if nothing were wrong, and report the ratio. Build the floor by comparing against something that SHOULD be identical: repeat the measurement (N≥5), or shuffle the one variable your claim depends on and keep everything else fixed. If the signal is under ~2x the floor, say so yourself before the reviewer does. Use when you are about to quote a count, a percentage, or a performance delta in an issue, PR description or mailing-list post. Trigger terms: benchmark, regression, faster, slower, N tickets, X percent, how many, count, delta, improvement, is this significant, noise, variance, baseline.