| name | math |
| description | Math gotchas — integer overflow boundaries, cross-runtime float parity (tan/pow ULP drift), FP modulo-wrap pitfalls |
Math — Verified Gotchas
Central Binomial Coefficient C(n, n/2) overflow
| Type | Last fits | First overflow |
|---|
| Int64 | C(66, 33) = 7,219,428,434,016,265,740 | C(67, 33) |
| UInt64 | C(67, 33) = 14,226,520,737,620,288,370 | C(68, 34) |
Models consistently underestimate this boundary (a common wrong answer is n=62; correct is n=66 for Int64).
Result vs computation: the table bounds the RESULT. Intermediate products in the usual res = res * (n-k+i) / i loop overflow earlier (the multiply happens before the divide) — the last few safe n need 128-bit intermediates or a divide-first formulation.
Cross-runtime trig: V8 Math.tan ≠ CPython math.tan by 1 ULP
When building bit-exact parity between TS/JS and Python implementations of
the same math, tan is the single biggest offender. V8 and CPython do
not share a single implementation (V8 ships its own fdlibm-derived routines;
CPython calls platform libm), and tan's range reduction produces a
different LSB from naive sin(x)/cos(x) for some angles — which layer is
responsible varies by platform.
Fix: compute tan(x) as sin(x) / cos(x) in BOTH languages. sin and
cos round-tripped bit-identically across the tested runtimes.
| Op | V8 Math.X vs CPython math.X | Use? |
|---|
sin, cos | bit-identical (observed) | yes |
sqrt | bit-identical (IEEE-754 mandates correctly-rounded) | yes |
tan | 1 ULP drift possible | avoid — use sin/cos |
** (pow) | 1-2 ULP drift possible | accept tolerance |
atan, atan2, exp, log | 1-2 ULP drift possible | accept tolerance |
Even after sin/cos swap, pow(x, y) (e.g. step_mult = floor + norm**exp)
can still produce 1-ULP-different doubles between V8 and CPython for some
inputs. If the math identity is preserved (same algorithm, same constants,
sin/cos for tan), math.isclose(rel_tol=1e-12, abs_tol=1e-9) covers ~2 ULP
at typical magnitudes and is the right tolerance for "bit-exact in spirit".
Concrete example: a projectile-apex derivation
apexAboveMidline = (range/4) * tan(angleRad). V8 emitted
tan=0.32130439756415801744; CPython emitted tan=0.32130439756415796193.
After swapping both to sin(x)/cos(x), both emitted the second value.
Remaining rare failures (9/1000 seeds) came from **1.8 in the step
multiplier — those needed the isclose tolerance.
Modulo-wrap round-trip is NOT identity for in-range floats — never gate "did it wrap?" on FP equality
wrapped = lo + (((x - lo) % span) + span) % span for x ALREADY in
[lo, hi) returns a value that differs from x by ~1 ULP(span) on a large
fraction of inputs. The % ops themselves are exact — % is
truncated-division remainder (C fmod semantics), which IEEE 754 requires
to be exact; note it is NOT the IEEE remainder() operation (round-nearest
quotient), a different op. The error comes from the surrounding x-lo,
+span, lo+m adds, each of which rounds. Measured: 41–67% of in-range
values fail wrapped === x depending on the window; with lo and x of
matching magnitude the subtraction is Sterbenz-exact and the identity HOLDS
(0/1e6 failures) — so the spurious rate silently depends on runtime state
(camera position), making it look fine in one regime and fire constantly in
another.
Failure mode: if (wrapped !== x) onWrap() as a "teleport happened"
detector fired the callback ~60 Hz for every entity instead of once per
recycle — and a simulation harness with the same window shape "validated"
the degenerate behavior convincingly.
Right: detect the wrap by RANGE, then normalize:
if (x < lo || x >= hi) { x = lo + (((x - lo) % span) + span) % span; onWrap(); }
Also skips the modulo (and its FP noise re-write) in the common in-range case.
