stdlib: add pow and log with pinned Transcendental plans

[julia-script]

Context

The follow-up #41 split off. PR #124 shipped the exact group (abs, copysign, floor, ceil, round, trunc, min, max) plus sqrt. pow and log did not ship, and they are the only remaining functions that need pinned Transcendental plans.

Why these two are different from sqrt

sqrt was allowed to lower to the native instruction because IEEE-754 mandates a correctly-rounded square root — exactly one result is admissible, so every conforming target produces it and three-engine parity holds by the standard rather than by luck. Requirement 8 was amended to permit that single exception, with the reasoning stated in the spec.

No comparable mandate covers pow or log. Their results are implementation-defined, so the ban stands: no platform libm, no LLVM math intrinsic. Each needs its own pinned plan in Transcendental.ts, in the shape the Sin and Cos plans already use.

The blocker this issue inherits

#41's requirements 4–6 demand pinned reduction constants and polynomial coefficients which the issue never supplied. That is the unresolved part, and it is why this is needs-definition rather than ready:

• Which polynomial approximation, to what degree, over what reduction?
• The coefficients themselves, as exact bit values — derived how, and checked against what reference?

Transcendental.ts:3's existing Plan interface is the template: it fixes width, the canonicalNaN bit pattern, the reduction constants (inverseHalfPi, halfPi) and the sine/cosine coefficients as exact bigints, uses a fixed-order Cody-Waite reduction and Horner evaluation, and rounds every intermediate at the target width.

Decide before implementing: derive new coefficients (and say how they are validated), or adopt a published, citable set. Either is fine; guessing is not.

One lesson from PR #124 that applies directly

The correctly-rounded guarantee covers numeric results only. IEEE-754 leaves the sign of a NaN from an invalid operation unspecified, and the hosts genuinely disagree — x86 sqrt of a negative operand sets the sign bit, AArch64's default NaN clears it. PR #124 measured Wasm returning 0xFFF8000000000000 where the evaluator returned 0x7FF8000000000000, and resolved it by screening NaN and negative operands in Silk before the primitive runs.

pow and log have larger invalid domains than sqrt — negative bases with non-integer exponents, zero and negative arguments to log, and the various pow special cases. Enumerate the invalid domain explicitly and decide the result for each case, rather than discovering the disagreements one CI failure at a time.

Requirements

1. pow and log in f32 and f64, each with its own pinned plan.
2. Each plan fixes reduction constants and polynomial coefficients as exact bit values.
3. Each plan rounds every intermediate at the target width, in a fixed order.
4. Neither reaches the platform libm nor an LLVM math intrinsic — sqrt's exception does not extend to them.
5. Identical bits on the evaluator, LLVM and Wasm for every input.
6. The canonical NaN bit pattern for a NaN input, and a decided, tested result for every invalid-domain case.
7. Amend bootstrap-floating-point-scalars through the openspec process.

Acceptance criteria

• The coefficient question above is answered and recorded here before implementation.
• A bit-exact matrix compares all three engines for both functions.
• Every invalid-domain case has a pinned expected bit pattern.
• A check shows neither function reaches libm or an LLVM math intrinsic.
• The libm/intrinsic guard added by stdlib: add exact float math and a correctly rounded sqrt to f32 and f64 #124 is extended to cover them.

Dependencies

None hard. #41's exact group and sqrt landed in PR #124.

---

Filed by orchestrator run run-r7x1 from the #41 split.

[julia-script]

Triage review — 2026-08-13

Verdict: Correct but needs refinement
Priority: keep existing

The gap is current: packages/compiler/src/Transcendental.ts defines only Sin | Cos, and its Plan contains only their reduction constants and coefficients. The authoritative openspec/specs/bootstrap-floating-point-scalars/spec.md explicitly says pow and log must not reach an LLVM math intrinsic or platform libm, but it does not yet require those APIs.

The issue correctly identifies the unresolved design work. A deterministic implementation needs separate reductions/approximations, exact coefficient bits, fixed rounding order, and complete special-case/domain tables; the existing sine/cosine Cody–Waite plan cannot simply be relabeled for either operation.

The issue remains actionable after definition. The next action is an OpenSpec proposal that selects citable algorithms and pins domain semantics and bit patterns; implementation and three-engine vectors should follow only after that proposal is accepted.

[julia-script]

Definition decision — 2026-08-13

The transcendental work is split and pinned as follows.

• Implement natural log first, then same-width floating pow(base, exponent).
• Adopt citable fdlibm-family reductions/coefficients, transcribed as exact IEEE bits.
• Pin every intermediate operation, rounding step, and evaluation order at the target width; neither operation may reach host libm or LLVM math intrinsics.
• Require identical result bits across evaluator, LLVM, and Wasm, with an explicit finite-result error bound of at most 4 ULP.
• pow may own a private exponential kernel; that does not introduce a public exp API.

Special cases are ordered and exact:

• log: NaN and negative inputs return canonical NaN; either signed zero returns negative infinity; positive infinity returns itself; log(1.0) is positive zero.
• pow: zero exponent and base 1 return 1 even when the other operand is NaN; other NaNs canonicalize; negative finite bases require an integral exponent; signed zero and infinity preserve sign only for odd integral exponents; overflow/underflow produce the appropriately signed infinity/zero.
• The OpenSpec table must explicitly cover overlaps including pow(NaN, 0), pow(1, NaN), pow(-0, -3), and pow(-1, ±Infinity).

No issue body, state, assignment, milestone, or repository file was changed by this comment.