Repository navigation
Fix the accuracy of ERF and ERFC near zero and for large arguments - #1795
Open
marcin-kordas-hoc wants to merge 3 commits into
Open
marcin-kordas-hoc wants to merge 3 commits into
marcin-kordas-hoc wants to merge 3 commits into
Conversation
erf is computed from its series below 2 and from the continued fraction of erfc above, instead of 1 - exp(...), which lost every digit below about 1e-16. erfc uses the continued fraction from 1 upwards. Relative error against Python's math.erf and math.erfc is at most 7e-16 for erf and 2e-16 for erfc. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
hyperformula-docs | 6fc292b | Commit Preview URL Branch Preview URL |
Oct 07 2026, 06:25 AM |
Performance comparison of head (6fc292b) vs base (5abbbd9) |
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #1795 +/- ##
========================================
Coverage 97.32% 97.32%
========================================
Files 195 195
Lines 15739 15753 +14
Branches 3461 3499 +38
========================================
+ Hits 15318 15332 +14
Misses 413 413
Partials 8 8
🚀 New features to boost your workflow:
|
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
ERFandERFClost precision for arguments close to zero and for large arguments. Excel is accurate there, so the results differed from Excel's:ERF(1e-10)1.128379612e-10(relative error 3.9e-7)1.12837916709551e-10ERF(1e-300)(raw function)1.1e-161.12837916709551e-300ERFC(5)1.5374368445e-12(relative error 1.5e-5)1.53745979442803e-12The cause was
erfreturning1 - exp(...)(every digit below about 1e-16 is lost) anderfcbeing1 - erf.erfis now computed from its series below 2 (all terms positive, no cancellation) and from the continued fraction oferfcabove;erfcuses the continued fraction from 1 upwards. Relative error against Python'smath.erfandmath.erfcover 46 arguments from1e-300to 27 (negative ones included) is at most 7e-16 forerfand 3e-15 forerfc(a prototype of the same formulas, measured before they went into the repository).The change is in the vendored
jstat.ts, so the normal and log-normal distributions that callerfanderfc(NORM.DIST,NORM.INVthrougherfcinv,LOGNORM.DIST,LOGNORM.INV) are more accurate as well. The existing tests for them still pass unchanged.Behaviour check against Excel
71
ERFandERFCformulas were evaluated in Excel Online (MS Graph live session) and in HyperFormula, from1e-300to27, with negative arguments and the two-argument form ofERF: all agree within a relative 4e-11, which is the 11 significant digits HyperFormula returns by default against Excel's 15. Two of them need a note:ERF(1e-300)andERFC(27)returnNaNfrom the engine, not fromerf: with the defaultsmartRounding, any result below about1e-290becomesNaN, and so does a plain=1e-300*1. The raw functions return the right values (1.1283791670955126e-300and5.23705e-319). That is a separate defect of the number rounding and is not changed here, so the tests start at1e-100.1E-10does not parse ondevelop(it is fixed in the GESTEP pull request), so the cases use1e-10.Tests
Paired tests branch:
fix/erf-accuracy-near-zeroin the tests repository: 29 Excel-measured cases added to theERFandERFCspecs, 12 or more of which fail on the previous implementation. Full local run: 502 suites, 6262 passed, 3 skipped.🤖 Generated with Claude Code
Note
Medium Risk
Changes numeric outputs for
ERF/ERFCand dependent statistical functions across many formulas; behavior is intentional and Excel-aligned but may shift edge-case results in existing sheets.Overview
Improves numeric accuracy of
ERFandERFCso tiny and large arguments match Excel instead of losing precision from1 - exp(...)anderfc = 1 - erf.The vendored
jstat.tsimplementation is replaced with piecewise algorithms: a positive-term series for small|x|, a continued-fractionerfcfor larger values, and explicit handling for NaN, sign, and underflow (e.g.erfc→0for very largex). Normal and log-normal distribution helpers that call these primitives inherit the same accuracy. The unreleased changelog documents the fix (#1795).Reviewed by Cursor Bugbot for commit 6fc292b. Bugbot is set up for automated code reviews on this repo. Configure here.