PreciseNumber implements INumber<T> and nothing else, so there is no sqrt, exp, log or trig

[matt-edmondson]

Tracking issue. Found while speccing an orbital-mechanics showcase (SGP4 propagation) that wants PreciseNumber as its reference arithmetic.

PreciseNumber declares : INumber<PreciseNumber> and stops there. It has none of:

• IRootFunctions<PreciseNumber> — no Sqrt, Cbrt, RootN, Hypot
• IExponentialFunctions<PreciseNumber> / ILogarithmicFunctions<PreciseNumber>
• ITrigonometricFunctions<PreciseNumber> — no Sin, Cos, Tan, Asin, …
• IPowerFunctions<PreciseNumber> — Pow exists as an instance method and falls back to double for non-integer exponents
• IHyperbolicFunctions<PreciseNumber>

Two consequences. A caller cannot write an algorithm generically over INumber<T> plus any of these constraints and have PreciseNumber satisfy it. And more sharply: taking a square root today means Math.Sqrt(x.To<double>()), so a 50-digit number that takes one root is a 15-digit number wearing a 50-digit type, silently.

What already exists and should be reused rather than re-derived

• ReduceSignificance(int significantDigits) is public and rounds half away from zero. Every series below needs it: multiplication is exact, so x^n for a 50-digit x carries 50n digits, and an un-truncated Taylor series grows quadratically in memory for no accuracy gain.
• Divide(left, right, int significantDigits) establishes the precedent for a precision-taking overload sitting next to a default one. The new functions should follow it exactly rather than invent a second convention.
• ktsu.Semantics.Quantities' internal StorageMath.Sqrt<T> already implements a type-generic Newton square root — double-seeded, scaled by powers of four for values outside double's range, throwing rather than returning an unconverged estimate. It is the algorithm the roots sub-issue wants, already tested. (Opening it up is ktsu-dev/Semantics — separate issue there.)

Design decisions that apply to all of the sub-issues

Precision contract. None of these interface members takes a precision argument, so each computes at MinimumDivisionPrecision (50), matching Divide. Alongside each, add an explicit (value, int significantDigits) overload, mirroring Divide.

Accuracy contract: faithful rounding, not correct rounding. The result is within 1 ulp at the requested precision. Correct rounding runs into the table-maker's dilemma and is not worth the cost here. Document that, and do not claim more than it.

Guard digits. Compute internally at significantDigits + 10, truncate every intermediate to that working precision with ReduceSignificance, and reduce once at the end.

Termination. Sum until a term's exponent falls more than the working precision below the accumulator's, then take one more term. Never a fixed iteration count; non-convergence is an ArithmeticException, following StorageMath's precedent.

Atan2 is not on ITrigonometricFunctions. It lives on IFloatingPointIeee754<T>, which PreciseNumber should not implement — it is not IEEE-754 and has no NaN or infinity. So Atan2 is a bespoke static, added in the trig sub-issue because SGP4 cannot be written without it.

Sub-issues, in dependency order

1. IRootFunctions<PreciseNumber> — no dependencies
2. IExponentialFunctions + ILogarithmicFunctions + IPowerFunctions — no dependencies; also fixes Pow's silent double fallback
3. ITrigonometricFunctions + Atan2 — depends on both of the above and on the constants issue

IHyperbolicFunctions is cheap once exp/log land and can follow later.

Acceptance for the set

• Each function checked against published 50-digit reference values (√2, ln 2, sin 1, cos 1, e, …)
• Identity tests at 50 digits: sin²x + cos²x = 1, Exp(Log(x)) = x, Sqrt(x)² = x, Atan2 in all four quadrants
• Agreement with the double answer to 15 digits across a sweep — the cheap regression net
• A benchmark class per function in PreciseNumber.Benchmarks, parameterised by the repo's Digits axis (8 / 30 / 200) with allocation reported, so the cost of each is on the record before it ships. Related: Investigate benchmark regressions in Max, CompareTo, ReduceSignificance, Pow, and Divide since 2.0 #76.

[matt-edmondson]

Triage

Category: Feature Request (tracking issue)
Priority: Medium
Area: PreciseNumber — System.Numerics generic math interfaces

Medium as a tracking issue. It contains one genuine bug — Pow's silent double fallback for non-integer exponents, which returns ~15 correct digits from a type that claims 50 — but that is filed and scoped in #81, so this issue itself carries no work.

The framing worth preserving is the second consequence: a caller cannot write an algorithm generically over INumber<T> plus any of these constraints and have PreciseNumber satisfy it. That is a bigger deal than any individual missing function, because it is what stops the type being usable as a drop-in reference arithmetic.

Suggested assignment: none specific.

Already in progress: sub-issue 1 (IRootFunctions) is covered by open PR #86, "Implement IRootFunctions with Sqrt, Cbrt, RootN and Hypot". Sub-issues #81 and #82 are unstarted, and #82 additionally depends on #79 and #80.

Related: ktsu-dev/Osculator#2 lists this as blocking its M3 milestone, with Osculator.Math.Precise supplying the functions locally until it lands. Also worth noting for whoever takes #86 forward: this issue points at ktsu.Semantics' internal StorageMath.Sqrt<T> as the already-tested algorithm the roots work wants, and ktsu-dev/Semantics#247 is an open PR making StorageMath public — so the "opening it up is a separate issue over there" note is now actionable rather than hypothetical.

Open PR covering this: #86, for sub-issue 1 only.

Suggested next step: the cross-cutting decisions set out here — faithful rather than correct rounding, significantDigits + 10 guard digits, termination by exponent gap rather than fixed iteration count, and the (value, int significantDigits) overload mirroring Divide — are the valuable part of this issue, and they should be settled in #86's review rather than re-litigated per sub-issue. Whatever #86 lands becomes the de facto precedent for #81 and #82 whether or not it is written down, so it is worth writing down.

---

Generated by Claude Code