noun: math.hoon transcendental jets (@rd/@rs/@rh/@rq)#1044
Open
sigilante wants to merge 2 commits into
Open
Conversation
431ac0c to
6edd366
Compare
Collaborator
Author
|
CI failure: near is a reserved identifier/macro on the CI toolchain (it compiles on macOS clang but not Linux gcc — near is a legacy reserved word). That hits the @rh inverse-trig code in math.c and affects both vere PRs. |
Register the math.hoon transcendental library (numerics /lib/math) in the userspace %non chapter, so the four IEEE precision doors run native SoftFloat instead of interpreted Hoon. - 15 transcendentals x 4 doors -- exp log sin cos tan atan atan2 asin acos sqt cbt pow pow-n log-2 log-10 -- for @rd (f64), @rs (f32), @rh (f16, native), @rq (f128), as non -> math -> <door> -> arm in the 135 tree. - Jet bodies in jets/i/math.c (chub-based I/O, word-size-agnostic), the u3qi_*/u3wi_* decls in q.h/w.h, and the build.zig source entry. Bit-exact to the Hoon door (same reduction, coefficients, Horner order); -test %/tests/lib is 247/247 green, jet identical to interpreted Hoon arm-by-arm. All four doors run ~1 us/call (rq f128 ~1.8 us) vs ~250 us interpreted. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
6edd366 to
1fa8cce
Compare
Collaborator
Author
Two accuracy bugs found while writing up this jet work for publication, both now fixed to match the corrected math.hoon (numerics repo): - _rh_sin/_rh_cos: the native-f16 quarter-turn reduction broke down past |x|~500 (q=round(|x|*2/pi) exceeds f16's 2048 exact-integer ceiling, amplifying rounding error by pi/2's leading term) -- catastrophic errors up to 10 orders of magnitude past 1 ULP, well within f16's ordinary range. Fixed by widening to f32 (f16_to_f32, exact) around the already-correct _rs_sin/_rs_cos, narrowing back via f32_to_f16 (correctly rounded RNE) -- both primitives already linked via SoftFloat. - _rs_tan: was (div (sin x) (cos x)), the same composed ratio used at @rh/@rq (~1.2 ULP). Given a genuine dedicated kernel, mirroring @rd's own __kernel_tan structure (Chebyshev-fit Q(z)=(tan(r)/r-1)/z, 7 coefficients, -cot path via reciprocal for odd reduction quadrants), reaching ~0.94 ULP -- beating the ratio outright. The key structural detail: the dominant linear term must be added last (w2=x+r), not multiplied through the polynomial, matching fdlibm's own convention. Verified on a freshly booted ship with jets enabled: the full tests/lib/math-rh.hoon and math-tan.hoon suites (numerics repo) pass, every case running in tens of microseconds (jetted, not falling back to interpretation). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
sigilante
added a commit
to urbit/numerics
that referenced
this pull request
Jul 4, 2026
…n kernel @rh's native q*pi/2 reduction corrupts qf once q=round(|x|*2/pi) exceeds @rh's 2048 exact-integer ceiling (|x|~500), producing errors up to ~21.6 billion ULP (tan) well within @rh's normal domain. Fixed by widening to @rs (exact via +widen-hs), computing sin/cos there, and narrowing back with a single correctly-rounded round (+narrow-sh). Same fix ported to the C jets (libmath/vere, libmath/vere64) via SoftFloat's f16_to_f32/ f32_to_f16, closing a real Hoon/jet mismatch (the old jets still implemented the buggy native-@rh kernel). @rs +tan gains a dedicated fdlibm-style kernel (~0.94 ULP, replacing the ~1.2 ULP sin/cos ratio and beating an earlier abandoned draft that scored 9.68 ULP due to multiplying its dominant term through the polynomial instead of adding it last). @rh and @rq deliberately stay on the ratio: @rh's 11-bit mantissa can't support a kernel that beats it, and @rq's tangent series needs 45+ growing-magnitude terms that destabilize native chained rounding. Verified bit-exact against libmath/tools/cheb_check.py and on-ship (math-rh, math-tan, math-trig, math-derived, math-atan, math-ainv suites all ok=%.y, jetted). Companion fixes applied to urbit/vere#1044/#1045 and urbit/urbit#7372. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
Registers the
math.hoontranscendental library jets (from the numericsproject's
/lib/math) in the userspace%nonchapter, so the four IEEEprecision doors run native SoftFloat instead of interpreted Hoon.
What
exp log sin cos tan atan atan2 asin acos sqt cbt pow pow-n log-2 log-10for@rd(f64),@rs(f32),@rh(f16,native),
@rq(f128) — registered asnon → math → <door> → armin the135, 136 and 137 trees.
jets/i/math.c(chub-based I/O, word-size-agnostic), theu3qi_*/u3wi_*decls inq.h/w.h, and thebuild.zigsource entry.Verification
On a fresh hoon-135 fakezod: all four doors fire (
exp:rd/rs/rh:math~1 µs/call,
exp:rq~1.8 µs, vs ~250 µs interpreted) and-test %/tests/libis 247/247 green, bit-exact to the Hoon door (same reduction, coefficients,
Horner order). Jet ≡ interpreted Hoon confirmed arm-by-arm.
🤖 Generated with Claude Code