ENH: improve f32 sin/cos accuracy - #12
Draft
seiko2plus wants to merge 2 commits into
Draft
Conversation
- Extended path: restructure final reconstruction to follow SVML's per-precision rounding DAG (f32/f64 pair the sin/cos correction terms differently) and regenerate approx.h so sigma is a signed power of two, keeping sigma*r exact - Low path: give f64 cosine its own minimax fit matching __svml_cos_d_la and keep its fast path up to ~8388607*pi - Non-FMA f64: add SplitMul (exact head product via 26-bit split) to replace the FMA product-error idiom in the high/extended paths and reduce with a descending 4-word pi/16, restoring sub-ULP accuracy - Correct trig polynomial/scale/threshold commentsit log
Member
Author
|
it should resolves numpy/numpy#29699 |
The new improvements provide better accuracy for both non-FMA and FMA targets, so we can achieve < 2ulp for the low accuracy path and < 0.6 for the high accuracy path without affecting performance, except for a few ops on non-FMA targets, which was necessary to match FMA target precision. The improvements also include increasing the fast path ranges for FMA targets, and it has been tested against an exhaustive test covering all float32 ranges. This was achieved by refitting the f32 sin/cos polynomials as generated minimax sets (new data/polyf32.h.pol) instead of SVML hardcoded coefficients, split per op and per FMA mode. For non-FMA: - High<> gets a third pi word with 31-bit heads so n*pi_i stays - exact; FMA keeps the two-word 35+53-bit split. - Low<> recovers the pi[2] rounding error via Fast2Sum on non-FMA, the same approach applies to float64 and buys ~0.3 ulp. Also, for all targets: - Low<> cos(x) == 1 is answered for all |x| below a per-type bound, not just x_trans == pi/2, which fixes tiny tests. - kLargeF32 replaces the flat 10000 with per-path measured thresholds. - Sollya prec 512 -> 1024, which was needed for generating the float32-widening double poly.
seiko2plus
force-pushed
the
ENH/trig-float32-accuracy
branch
from
July 28, 2026 00:27
20237d9 to
25c7820
Compare
seiko2plus
marked this pull request as ready for review
July 28, 2026 00:30
seiko2plus
marked this pull request as draft
July 28, 2026 09:14
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
1 participant
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.
merge after #10
The new improvements provide better accuracy for both non-FMA and FMA
targets, so we can achieve 2ulp for the low accuracy path and 1ulp for
the high accuracy path without affecting performance, except for a few ops on
non-FMA targets, which was necessary to match FMA target precision.
The improvements also include increasing the fast path ranges for FMA targets,
and it has been tested against an exhaustive test covering all float32 ranges (#11).
This was achieved by refitting the f32 sin/cos polynomials as generated minimax sets (new
data/polyf32.h.pol) instead of SVML hardcoded coefficients, split per op and per
FMA mode. For non-FMA:
the same approach applies to float64.
Also, for all targets:
x_trans == pi/2, which fixes tiny tests.
TODO: