| 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.
