Implement ITrigonometricFunctions<PreciseNumber>, plus Atan2 [minor]

[matt-edmondson]

Fixes #82

Completes the fourth of #78's interface surfaces. Its three dependencies are now merged — #79 (wide, correctly-rounded π), #80 (Sqrt), #81 (Exp/Log and the series machinery) — so this was unblocked.

What's added

PreciseNumber/PreciseNumber.Trigonometry.cs implements ITrigonometricFunctions<PreciseNumber> and the bespoke Atan2, none routing through double, every function with a (…, int significantDigits) overload matching the rest of the library:

• Sin, Cos, SinCos, Tan
• Asin, Acos, Atan, Atan2
• the half-turn family SinPi, CosPi, SinCosPi, TanPi, AsinPi, AcosPi, AtanPi
• DegreesToRadians, RadiansToDegrees

Design, following the issue

• Sin/Cos/SinCos reduce x = q·π/2 + r into r ∈ [-π/4, π/4] with an octant index q, so one kernel serves both. The kernel halves r to below 1/64, sums the sine and cosine series together, and doubles back with the double-angle identities. The reduction reads PiTo(working + argumentDigits + guard), not the capped Pi property — this is the concrete dependency on Pi carries 26 significant digits and Tau 25, fewer than MinimumDivisionPrecision, and Pi is truncated rather than rounded #79. SinCos does the reduction once, and Sin/Cos both read from it, so they agree exactly.
• Tan is sin / cos from one reduction and a single division.
• Atan applies atan x = 2·atan(x / (1 + √(1 + x²))) until the argument is small, then Taylor, scaling back by the matching power of two — so any magnitude converges (Atan(1e30) ≈ π/2). Asin/Acos build on Atan and Sqrt, with ±1 special-cased around the √(1 - x²) division by zero.
• The half-turn family reduces modulo two on the argument before multiplying by π, so the multiplication never magnifies the argument and no wide π is needed: SinPi(1e20) is 0, exactly, where Sin(1e20 · π) is undefined.
• Atan2 is a bespoke static, not an interface member — it lives on IFloatingPointIeee754<T>, which PreciseNumber deliberately does not implement, per the issue's reasoning (no NaN/infinity to give the edge cases meaning). Quadrant dispatch on atan(y/x) with the axes handled explicitly.
• DegreesToRadians/RadiansToDegrees read π as the correctly-rounded literal PiTo, never derived from another constant.

There is no NaN, so Asin/Acos outside [-1, 1] throw ArgumentOutOfRangeException, as Sqrt and Log already do; Tan/TanPi throw DivideByZeroException where the cosine is exactly zero.

Tests

PreciseNumber.Test/PreciseNumberTrigonometryTests.cs, 20 methods, all pinning published values or mathematical identities rather than this library's own output:

• Published 50-digit Sin/Cos/Tan(1), Asin(0.5) = π/6, Acos(0.5) = π/3, Atan(1) = π/4, Cos(π/6) = √3/2
• Pythagorean identity to 58 digits and Tan = sin/cos across a sweep spanning several revolutions and both signs
• SinCos agrees with separate Sin/Cos exactly (the reason the member exists)
• Inverse round trips, Atan of a large argument, Atan2 in all four quadrants and on every axis (including Atan2(0,0) and Atan2(0,-1) = π)
• SinPi(1e20) = 0, SinPi(0.5) = 1, CosPi(1) = -1, and SinPi/CosPi agreeing with the radian forms
• Degree/radian conversion, and the inverse half-turn family's exact endpoints
• Agreement with Math.Sin/Cos/Atan/Atan2 to 14 digits as a cheap regression net

The Sin(1000000) test carries a 120-digit reference. That is the test the issue calls out as tying this work to #79: I verified it fails on a deliberately narrowed 26-digit π (differs by ~1e-21), and — notably — the Pythagorean-identity test still passes under that same narrow π, which is why the wide digit-string reference is the essential guard, not the identity alone. The reference itself is cross-validated by the 150-digit Pythagorean identity, the double-angle identity sin(2e6) = 2·sin(1e6)·cos(1e6) to 50 digits, and stability across 50/55/70/100/130-digit working precision.

Also

• PreciseNumber.Benchmarks/TrigonometryBenchmarks.cs across the repo's 8/30/200 Digits axis with a double floor, mirroring the exponential and root benchmarks (including the SinCos-vs-separate-calls and large-angle cases).
• README updated: feature list, the precision-behaviour section, the limitations, and the API reference.

Verification

• dotnet build PreciseNumber.sln — clean, no warnings (this repo treats warnings as errors), all target frameworks (net10.0;net9.0;net8.0;net7.0;netstandard2.0;netstandard2.1)
• PreciseNumber.Test — 350/350 pass on net10.0 (this container has only the .NET 10 runtime; CI runs the full multi-target matrix)

No public API is changed or removed; this is purely additive, hence [minor].

🤖 Generated with Claude Code

https://claude.ai/code/session_01By7NnPN7STCZqeAftJ1BmH

---

Generated by Claude Code

[matt-edmondson]

CI status

Everything on fcb654b is green except one check: Test on ubuntu-latest, windows-latest and macos-latest all pass, as do CodeQL, both Analyze runs, Analyze & Release, and SonarCloud (quality gate passed, 0 new issues, 82.9% coverage on new code).

The one failure is github-advanced-security, GitHub's agentic code-scanning (ghas-code-scanning-agentic), and it did not fail on anything in the diff — it never read the diff:

Error creating PR review request: SessionModelError: You have exceeded your monthly quota
  errorType: 'quota', statusCode: 402

Two things put it outside this PR:

1. It is a service-side entitlement error, not a code condition. There is no change to this branch that produces or clears a 402 from the scanning backend.
2. The scanner excludes every file this PR touches anyway. Its own FileExclusionPatterns for this run lists *.cs, *.csproj and *.sln among others, so PreciseNumber.Trigonometry.cs, the tests and the benchmark were all out of scope before the error stopped it.

Correction: this is transient, not an exhausted monthly quota

An earlier version of this comment said the quota was spent and that the check would fail the same way across the org. That was wrong, and I'm correcting it rather than leaving it: the same github-advanced-security check passed on ktsu-dev/Schema#208 at 02:03 UTC, nine minutes after it failed here at 01:54. So despite the wording of the error, the condition is transient — throttling or a per-request limit — and not an account-level cap that needs topping up. No billing change is called for on the strength of this.

Why I have not cleared it

The run is not retryable through the API — both of these return 403 This workflow run cannot be retried:

POST /repos/ktsu-dev/PreciseNumber/actions/runs/35677472923/rerun-failed-jobs
POST /repos/ktsu-dev/PreciseNumber/actions/runs/35677472923/rerun

GHAS-managed runs aren't retryable that way. So the options are a maintainer re-running or dismissing it, or it simply re-evaluating on the next push to this branch. I have no code change to make here, and I won't push an empty commit to kick CI.

Given it passed elsewhere minutes later, I'd expect a re-run to succeed. Keeping the PR watched until it is green and merged.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
82.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud