@woosh/meep-engine 3.0.2 → 3.2.0

package/src/REVIEW_2026_08_06/core-math.md

@@ -1,221 +1,221 @@
-# Correctness review — `meep/src/core/math/`
-
-Scope: 203 non-spec source files under `H:/git/moh/app/src/mir-engine/meep/src/core/math/`.
-All findings below were reproduced by executing the actual modules under node 24 (ESM).
-
----
-
-### MATH-1 Simplex noise truncates instead of floors the lattice cell index
-- **Severity**: CRITICAL
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/noise/sdnoise.js:199`, `:278-279`, `:429-431`, `:686-689`
-- **Defect**: All four simplex-noise variants derive the integer lattice cell with `x | 0` / `xs | 0`, which truncates **toward zero**. The reference implementation (Gustavson/McEwan `sdnoise1234.c`) uses `FASTFLOOR`. For any coordinate whose skewed value is negative and non-integral the wrong cell is selected, the corner offsets `x0/x1/...` leave their valid range, and the field becomes discontinuous (1D: unbounded). The sibling module `noise/create_simplex_noise_2d.js:88` already carries a comment explaining exactly this hazard and uses `Math.floor`; `sdnoise.js` was never fixed.
-- **Failure scenario**:
-  - `sdnoise1(d, -0.9)` → **-22.0446** (`d[0] = 139.88`). Documented/reference range is `[-1, 1]`. In 1D the reference explicitly does *not* clamp `t1` because `|x1| <= 1` "always" — with truncation `x1 = -1.9`, `t1 = 1 - 3.61 = -2.61`, `t41 = 46.4`, and the corner contribution explodes. Sampling `x ∈ [-5, 5]` at 1e5 points gives a range of **[-323.81, +242.86]**; the same sweep over `[0, 5]` gives `[-0.173, 0.401]`.
-  - `sdnoise3(d, x, 0.3, 0.7)` swept over `x ∈ [-3, 3]` at 2e5 points has a maximum step between adjacent samples of **0.2335** (at x ≈ -1.75); the identical sweep over `x ∈ [1, 7]` has max step **0.00154**. Simplex noise is C¹-continuous, so a 150× jump is a discontinuity, not sampling resolution. Same for `sdnoise2` (0.355 vs 7.5e-5) and `sdnoise4` (0.722 vs 0.00106).
-  - Real caller: `engine/graphics/particles/particular/engine/simulator/SimulationStepCurlNoiseAcceleration.js:59` → `core/math/noise/curl_noise_3d.js:18` samples `sdnoise3` at `x - 231.141, ..., z - 54.4341`, i.e. permanently in the broken negative region for typical world coordinates.
-- **Fix**: Replace every `x | 0` / `xs | 0` cell computation in `sdnoise.js` with `Math.floor(...)` (the existing `& 0xff` / `& 255` wraps already handle negative indices correctly). Note the pinned regression values in `sdnoise.spec.js:111,124,160,173` were captured from the buggy field and must be re-derived after the fix.
-- **Confidence**: Confirmed
-
----
-
-### MATH-2 `hammersley_sequence` seeds the radical-inverse iteration with `i/count`, producing duplicates
-- **Severity**: CRITICAL
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/statistics/hammersley_sequence.js:10`
-- **Defect**: The loop body is the correct incremental Halton "next value" step (Wikipedia *Halton sequence*, fast method: `x = d-n; y = d/b; while x<=y: y/=b; n = (b+1)y - x`), which requires the iteration to start from `t = 0` and be applied `i` times to yield the `i`-th radical inverse. The code instead initialises `t = i / count`, which is not a valid state of that recurrence, so the returned values are not a radical inverse and the set is not low-discrepancy — it contains repeats.
-- **Failure scenario**: `hammersley_sequence(i, 2, 8)` for `i = 0..7` produces
-  `[0, 0.625, 0.125, 0.5625, 0.625, 0.3125, 0.5625, 0.4375]` — only **6 distinct values out of 8** (0.625 and 0.5625 each appear twice). The van der Corput / base-2 Halton sequence (what the sibling `halton_sequence(2, i)` correctly returns) is `[0, 0.5, 0.25, 0.75, 0.125, 0.625, 0.375, 0.875]`. Base 3 is equally wrong: produced `[0, 0.4583, 0.9167, 0.4861, 0.9444, 0.2176, 0.9722, 0.1466]` vs correct `[0, 1/3, 2/3, 1/9, 4/9, 7/9, 2/9, 5/9]`.
-  Two samples landing on the same value defeats the entire purpose of a low-discrepancy sequence (the doc line 2 says "Low discrepancy sequence").
-- **Fix**: `let t = 0;` (the `count` parameter then becomes unused for this coordinate — the `i/count` term is the *first* Hammersley coordinate, which belongs in the caller alongside this radical inverse, exactly as `hammersley_sequence_2d.js:15-16` already does). Alternatively delegate to `halton_sequence(R, i)`, which is both correct and O(log i) rather than O(i).
-- **Confidence**: Confirmed
-
----
-
-### MATH-3 `computeStatisticalPercentile` selects the order statistic one rank too high
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/statistics/computeStatisticalPercentile.js:23-24`
-- **Defect**: `start = floor(n * low)` is a half-open lower bound while `end = ceil(n * high)` is used as an **inclusive** upper index. Both are one greater than the correct 0-based rank; only clamping to `n-1` hides it at `high = 1`. For a point query (`low === high === p`) the returned element is the one at index `floor(p*n)` instead of the `p`-th order statistic.
-- **Failure scenario**: With `values = [1,2,3,4,5,6,7,8,9,10]`:
-  - `computeStatisticalPercentile(values, 0.9, 0.9)` → **10**. 10 is the *maximum* (100th percentile). Nearest-rank definition (Hyndman & Fan type 1): index `ceil(0.9*10) - 1 = 8` → **9**.
-  - `computeStatisticalPercentile(values, 0.5, 0.5)` → **6**, while `computeStatisticalMedian(values)` on the same data returns **5**. The library disagrees with itself about the 50th percentile.
-  - `computeStatisticalPercentile(values, 0, 0.4)` → **3**; the bottom 40 % of the data is `[1,2,3,4]`, whose (lower) median is **2** — the range wrongly includes index 4 (value 5, the 50th-percentile element).
-- **Fix**: Use `ceil(n·p) - 1` for both bounds:
-  `const start = clamp(Math.ceil(n * percentile_low) - 1, 0, n - 1);`
-  `const end = clamp(Math.ceil(n * percentile_high) - 1, 0, n - 1);`
-  Verified this keeps both existing spec cases green (`(0, 0.5) → 2`, `(0.5, 1) → 7`) while fixing `(0.5, 0.5) → 5` and `(0.9, 0.9) → 9`.
-- **Confidence**: Confirmed
-
----
-
-### MATH-4 `roundFair` never rounds a negative number up
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/random/roundFair.js:9`
-- **Defect**: `number % 1` in JavaScript keeps the sign of the dividend, so for a negative input `mantissa` is negative. `random()` returns a value in `[0, 1)`, so `roll > mantissa` is unconditionally true and the function always takes the `Math.floor` branch. The documented contract — "a fraction is rounded up or down with probability equal to the fraction", i.e. an unbiased stochastic rounding with `E[roundFair(x)] === x` — is violated.
-- **Failure scenario**: `roundFair(-2.3, Math.random)` returns **-3** for every draw (verified: `()=>0.9 → -3`, `()=>0.1 → -3`; mean over 10 000 `Math.random` draws = **-3.0**). Expected: -3 with probability 0.3 and -2 with probability 0.7, mean **-2.3**. Positive control `roundFair(2.3, Math.random)` gives mean 2.2967, so the positive path is correct.
-- **Fix**: Use the Euclidean fraction: `const mantissa = number - Math.floor(number);` (or `euclidean_modulo(number, 1)`, which already exists in this package). With `-2.3` that gives `0.7`, and `roll > 0.7` (probability 0.3) → `floor = -3`, else → `ceil = -2`, mean -2.3.
-- **Confidence**: Confirmed
-
----
-
-### MATH-5 `fract` truncates toward zero and wraps at 2³¹
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/fract.js:9`
-- **Defect**: `const whole = v >> 0;` performs `ToInt32`, which (a) truncates toward zero rather than flooring and (b) wraps modulo 2³². The JSDoc explicitly cites the GLSL `fract` reference page and states the result "is calculated as x - floor(x)".
-- **Failure scenario**:
-  - `fract(-0.1)` → **-0.1**; GLSL/documented `x - floor(x)` → **0.9**. `fract(-0.25)` → -0.25 vs 0.75.
-  - `fract(1e10)` → **8589934592**; expected **0**. (`1e10 >> 0 === 1410065408`.)
-  - `fract(2147483648.5)` → **4294967296.5**; expected **0.5**.
-  The 2³¹ wrap is wrong under *any* reading of the contract — the result is not even in `(-1, 1)`.
-- **Fix**: `return v - Math.floor(v);`. Note `fract.spec.js:7-9` currently pins the truncating behaviour (`fract(-0.1) === -0.1`, `fract(-1.1) === -0.1`) and must be updated with the fix, not used as justification for the current code.
-- **Confidence**: Confirmed
-
----
-
-### MATH-6 `squirrel3` does not use 32-bit wrapping multiplication, so it is not the cited hash and collides
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/hash/squirrel3.js:13`, `:18` (also `:15`, `:19`)
-- **Defect**: The cited Squirrel3 (Eiserloh, GDC 2017) is defined over `unsigned int` with wrapping multiplies and *logical* right shifts. Here `value * BIT_NOISE1` and `hash *= BIT_NOISE3` are IEEE-754 double multiplies: an int32 operand times a ~2³² constant produces up to ~2⁶⁰, far beyond the 53-bit mantissa, so the low bits are **rounded away** before `ToInt32` takes them. Additionally `hash >> 8` (lines 15, 19) is an arithmetic shift where the reference uses a logical shift, so for negative intermediates different bits are mixed in.
-- **Failure scenario**: `squirrel3(0)` → **436901382**; a faithful 32-bit implementation (`Math.imul` + `>>>`) gives **436901570**. `squirrel3(1)` → 1910996822 vs reference 725778245. More consequentially, the reference is a bijection on 32 bits: over the 200 000 consecutive inputs `0..199999` it produces **200 000 distinct outputs**, whereas `squirrel3` produces only **199 763** — 237 collisions purely from the lost mantissa bits. (This is almost certainly the cause of the "low entropy" note in the file's own header comment.)
-- **Fix**: `let hash = Math.imul(value | 0, BIT_NOISE1);` … `hash = Math.imul(hash, BIT_NOISE3);`, and change both `>> 8` to `>>> 8`. Any callers persisting these hashes must be re-keyed.
-- **Confidence**: Confirmed
-
----
-
-### MATH-7 `m2_svd` / `m2_polar_decomp` emit factors in the opposite storage convention to their input
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/linalg/m2/m2_svd.js:7-19`, `H:/git/moh/app/src/mir-engine/meep/src/core/math/linalg/m2/m2_polar_decomp.js:8`, `H:/git/moh/app/src/mir-engine/meep/src/core/math/linalg/m2/m2_polar_decomp_noS.js:5`
-- **Defect**: The input `m` is read as transposed storage (`m2_polar_decomp_noS.js:20` computes `y = m[2] - m[1]`, i.e. `A01 - A10`, the negation of taichi's `A[1,0] - A[0,1]`), but `U`, `V` and `R` are written in plain row-major. Consequently the documented reconstruction identities do not hold when evaluated with this package's own `m2_multiply`/`m2_transpose`. The two polar docs already contradict each other (`m = S * R` vs `m = R * S`) and neither is the relation that actually holds.
-- **Failure scenario**:
-  - `m = [1, -2, 5, 3]`. After `m2_svd(U, S, V, sig, m)`, computing `U·Σ·Vᵀ` exactly as `m2_svd.spec.js:16-20` does yields **`[1, 5, -2, 3]`** — the transpose of `m`, not `m`. The doc (`m2_svd.js:7`) asserts `m = U * Σ * V^T`. The existing spec only checks reconstruction for symmetric inputs (`[1,0,0,1]`, `[2,0,0,3]`, `[2,1e-7,1e-7,3]`), where a transpose is invisible; the one asymmetric case `[1,-2,5,3]` checks only singular-value ordering.
-  - `m = [1, 2, 3, 4]`. `m2_polar_decomp(R, S, m)` gives `R = [0.98058, 0.19612, -0.19612, 0.98058]`, `S = [0.58835, 2.15728, 2.15728, 4.51067]`. `m2_multiply(x, S, R)` (the documented `m = S * R`) yields **`[0.15385, 2.23077, 1.23077, 4.84615]`** — neither `m` nor `mᵀ`. The relation that actually holds is `m2_multiply(x, R, S) = [1, 3, 2, 4] = mᵀ`.
-  - Downstream consequence (outside this package but caused by it): `engine/physics/mls-mpm/MLS_MPM.js:373-374` stores `F` in transposed layout (`m2_multiply(F, p.F, m2_temp0)` is only correct under that convention) and then writes back `m2_multiply(m2_temp0, svd_u, sig); m2_multiply_transposed(p.F, m2_temp0, svd_v)`, which stores the untransposed `U Σ Vᵀ` into a transposed slot — i.e. the plastically-clamped deformation gradient is transposed on every substep whenever `F` is non-symmetric (any shear).
-- **Fix**: Pick one convention and make it total. Cheapest correct change that preserves the taichi port: transpose the emitted rotations so all five arrays share the input's storage — write `R = [c, -s, s, c]` in `m2_polar_decomp_noS`, mirror it in the two `V` branches of `m2_svd.js:79-91`, and swap the operand order of `m2_multiply(U, U, V)` at `m2_svd.js:95`. Then add an asymmetric-input reconstruction case to `m2_svd.spec.js` (e.g. `[1,-2,5,3]`) so the invariant is pinned, and reconcile the three JSDoc blocks.
-- **Confidence**: Confirmed
-
----
-
-### MATH-8 `ParameterLookupTable.toBinaryBuffer` picks an item-count width one bit too small at exact powers of two
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/lookup/ParameterLookupTable.js:110-122`
-- **Defect**: The width is chosen from `Math.log2(itemCount)`, but the number of bits needed to store `itemCount` is `floor(log2(itemCount)) + 1`. At an exact power of two the test is off by one and too narrow a field is selected; `DataView.setUint8`/`setUint16` then silently truncate modulo the field.
-- **Failure scenario**: A table with exactly **256** entries: `log2(256) = 8`, so `itemCountByteSize = 1` and `buffer.writeUint8(256)` writes **0**. `fromBinaryBuffer` then reads `itemCount = 0` and reconstructs an **empty** table — total silent data loss on round-trip. Same at 65 536 entries (`writeUint16(65536) → 0`). 255 and 257 entries round-trip correctly, so the failure is exactly at the boundaries.
-- **Fix**: Compare against the value, not the log: `if (itemCount <= 0xFF) ... else if (itemCount <= 0xFFFF) ... else if (itemCount <= 0xFFFFFFFF) ...`.
-- **Confidence**: Confirmed
-
----
-
-### MATH-9 `copysign` flips the sign when the sign source is `+0`
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/copysign.js:9-14`
-- **Defect**: The sign is decided by `(x > 0 && y > 0) || (x < 0 && y < 0)`. When `y` is `+0` (or `NaN`) neither disjunct holds, so the `else` branch negates `x`. C99 `copysign` takes the *sign bit* of `y`; the sign bit of `+0` is clear, so the result must be `+|x|`.
-- **Failure scenario**: `copysign(3, 0)` → **-3**; C99/`tgmath.h` (which the JSDoc cites as the source) gives **+3**. `copysign(-3, 0)` → **+3** (correct by accident). `copysign(3, NaN)` → -3, where C gives +3. `copysign(3, -0)` → -3 (correct). The existing spec never passes `0` as `y`.
-- **Fix**: `return (y < 0 || Object.is(y, -0)) ? -Math.abs(x) : Math.abs(x);`
-- **Confidence**: Confirmed
-
----
-
-### MATH-10 `softmax` overflows to `NaN` for large inputs
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/statistics/softmax.js:12`, `:19`
-- **Defect**: `Math.exp` is applied to the raw components. `Math.exp(z) === Infinity` for `z > 709.78`, and `Infinity / Infinity === NaN`. The standard formulation (and every reference implementation, cf. the linked Wikipedia article's "numerical stability" note) subtracts `max(z)` first — mathematically identical because `softmax(z) === softmax(z - c)` for any constant `c`.
-- **Failure scenario**: `softmax([1000, 1], 0, 2)` → **NaN**; the correct value is **1** (to within double precision). `softmax([800, 801], 1, 2)` → **NaN**; correct value **0.7311**.
-- **Fix**: Compute `let max = -Infinity; for (j…) max = Math.max(max, z[j]);` then use `Math.exp(z[i] - max)` and `sum += Math.exp(z[j] - max)`.
-- **Confidence**: Confirmed
-
----
-
-## Checked and found correct (recorded so they are not re-reviewed)
-
-- `linalg/lu_factor_linear_system.js` / `lu_solve_linear_system.js` — faithful port of VTK `LUFactorLinearSystem`/`LUSolveLinearSystem`; the column-major index map `A[j*size+i] ≡ A[i][j]` is applied consistently in every loop, including the row interchange and the `scale[maxI] = scale[j]` step.
-- `idct_1d.js` / `idct_2d.js` — element-for-element match with the ffmpeg AAN `idct_1d`. `idct_2d` deliberately omits ffmpeg-exr's extra `*0.5`: the only caller is the JPEG decoder (`engine/asset/loaders/image/jpeg/idct8x8_float.js`), and the JPEG convention is exactly `1/2` per dimension. Verified DC round-trip: `F(0,0) = 8` → `f(x,y) = 1`.
-- `linalg/solve_linear_system_GEPP_2x2.js` — exhaustively walked every zero-pattern branch (single, double, singular); column-swap/row-swap bookkeeping and the final un-swap of `x` are correct in all cases.
-- `linalg/eigen/matrix_symmetric_3x3_eigen.js` — Numerical Recipes cyclic Jacobi; rotation formulas, third-index update, eigenvector accumulation and ascending sort all correct; `r = 3 - p - q` is valid for all three plane pairs.
-- `linalg/givens/givens_rotation_coefficients.js` — both branches satisfy `-s·a + c·b = 0` and `c² + s² = 1`.
-- `noise/create_simplex_noise_2d.js` — correct Fisher–Yates (`r = i + ~~(random()*(256-i))`, range `[i, 255]`), correct `Math.floor`, all `perm[]` indices bounded by 511.
-- `spline/computeCatmullRomSpline.js`, `computeCatmullRomSplineUniformDistance.js`, `computeNonuniformCatmullRomSplineSample.js` — Wikipedia centripetal Catmull–Rom barycentric form; endpoint interpolation exact at `f = 0` and `f = 1`.
-- `spline/interpolate_bicubic.js` — algebraically identical to the standard `p1 + 0.5t(p2-p0 + t(2p0-5p1+4p2-p3 + t(3(p1-p2)+p3-p0)))`.
-- `solveCubic.js` — the trigonometric branch's `acos(3q/(pm))` argument is provably in `[-1,1]` whenever `ratio < 0`, so no clamp is needed.
-- `physics/kinematics/computeInterceptPoint.js` — `(V·V - s²)t² + 2(V·D)t + D·D = 0` and the smallest-non-negative-root selection are both correct.
-- `compute_legendre_polynomial.js` — exact match with Green's *Spherical Harmonic Lighting* reference.
-- `modified_bessel_i0.js` — term recurrence `T_k = T_{k-1}·y/k²` matches `Σ (x²/4)^k/(k!)²`.
-- `random/randomIntegerBetween.js`, `random/random_pick_weighted_index.js`, `random/seededRandom_Mulberry32.js`, `random/seededRandom_MersenneTwister.js` — inclusive/uniform bucketing, cumulative-weight search bounds, and both generator kernels verified. (Mulberry32's unbounded `_seed` accumulator was measured: after seeding at 2⁶⁰ the distinct-output count over 100 000 draws is 99 996 vs 99 999 at seed 0 — not a reportable degradation.)
-- `statistics/computeStatisticalVariance.js` (population divisor `n`) and `statistics/computeStatisticalMedian.js` (lower median on even counts) are both **intentional**, pinned by their specs — not defects.
-- `physics/brdf/*`, `physics/pdf/*`, `physics/irradiance/*` — `D_GGX` matches Filament's listing, `pdf_GGX` is self-consistent with it on the α parameterisation, `cone_cosine_from_roughness` is the exact inverse of `reflection_sample_weight`'s spherical gaussian, `pdf_normal` is the correct `N(0,σ)` density, and `ior_to_reflectivity`/`reflectivity_to_ior` are exact mutual inverses.
-- `physics/mie/ri_*.js` — lookup positions are supplied in nanometres, so `ParameterLookupTable.sample(wavelength_nm, …)` interpolates on the right axis.
-
----
-
-## Unspecced files
-
-67 source files under `core/math/` have no adjacent `*.spec.js`:
-
-```
-DEG_TO_RAD.js
-EPSILON.js
-FLT_EPSILON_16.js
-FLT_EPSILON_32.js
-FLT_EPSILON_64.js
-GOLDEN_RATIO.js
-NumericType.js
-PI.js
-PI2.js
-PI_HALF.js
-PI_RECIPROCAL.js
-RAD_TO_DEG.js
-build_gaussian_kernel_2d.js
-euclidean_modulo.js
-fabsf.js
-hash/lowbias32.js
-idct_1d.js
-idct_2d.js
-interval/intersects1D.js
-interval/separation1D.js
-linalg/lu_factor_linear_system.js
-linalg/m2/m2_polar_decomp.js
-linalg/m2/m2_polar_decomp_noS.js
-linalg/sparse/spm_matvec.js
-linalg/sparse/spm_matvec_transpose.js
-lookup/ParameterLookupTable.js
-lookup/ParameterLookupTableFlags.js
-mix.js
-modified_bessel_i0.js
-noise/curl_noise_3d.js
-noise/curl_noise_3dt.js
-physics/brdf/diffuse_GGX.js
-physics/brdf/fresnel_Schlick.js
-physics/brdf/fresnel_Schlick_optimized.js
-physics/brdf/fresnel_Schlick_original.js
-physics/bsdf/bsdf_schlick.js
-physics/ior_to_reflectivity.js
-physics/mie/MIE_PARTICLES_STANDARD.js
-physics/mie/MIE_PARTICLES_STANDARD_PRECOMPUTED.js
-physics/mie/lorenz_mie_coefs.js
-physics/mie/ri_air.js
-physics/mie/ri_ammonium_sulfate.js
-physics/mie/ri_brine.js
-physics/mie/ri_dust.js
-physics/mie/ri_pollen.js
-physics/mie/ri_smoke.js
-physics/mie/ri_soot.js
-physics/mie/ri_water.js
-physics/pdf/pdf_normal.js
-physics/reflectivity_to_ior.js
-random/generate_halton_jitter.js
-random/randomBytes.js
-random/random_pick_weighted_index.js
-random/seededRandom.js
-spline/catmull_rom_compute_T.js
-spline/computeNonuniformCaltmullRomSplineDerivative.js
-spline/computeNonuniformCatmullRomSplineSample.js
-spline/interpolate_bicubic.js
-spline/spline3_hermite_intersection_spline3_hermite_2d.js
-spline/spline3_hermite_intersects_spline3_hermite.js
-spline/v3_computeCatmullRomSplineUniformDistance.js
-sqr.js
-statistics/computeStatisticalMedian.js
-statistics/computeStatisticalStandardDeviation.js
-statistics/generate_hammersley_jitter.js
-statistics/hammersley_sequence.js
-statistics/hammersley_sequence_2d.js
-```
-
-Of the 10 findings, 4 land in unspecced files (`hammersley_sequence.js`, `ParameterLookupTable.js`, `m2_polar_decomp*.js`); the other 6 land in files whose specs exist but only exercise the working half of the input domain (`sdnoise.spec.js` never samples negative coordinates for 1/3/4D, `fract.spec.js` pins the bug, `copysign.spec.js` never passes `y = 0`, `m2_svd.spec.js` reconstructs only symmetric inputs, `roundFair.spec.js` never passes a negative, `computeStatisticalPercentile.spec.js` never makes a point query).
+# Correctness review — `meep/src/core/math/`
+
+Scope: 203 non-spec source files under `H:/git/moh/app/src/mir-engine/meep/src/core/math/`.
+All findings below were reproduced by executing the actual modules under node 24 (ESM).
+
+---
+
+### MATH-1 Simplex noise truncates instead of floors the lattice cell index
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/noise/sdnoise.js:199`, `:278-279`, `:429-431`, `:686-689`
+- **Defect**: All four simplex-noise variants derive the integer lattice cell with `x | 0` / `xs | 0`, which truncates **toward zero**. The reference implementation (Gustavson/McEwan `sdnoise1234.c`) uses `FASTFLOOR`. For any coordinate whose skewed value is negative and non-integral the wrong cell is selected, the corner offsets `x0/x1/...` leave their valid range, and the field becomes discontinuous (1D: unbounded). The sibling module `noise/create_simplex_noise_2d.js:88` already carries a comment explaining exactly this hazard and uses `Math.floor`; `sdnoise.js` was never fixed.
+- **Failure scenario**:
+  - `sdnoise1(d, -0.9)` → **-22.0446** (`d[0] = 139.88`). Documented/reference range is `[-1, 1]`. In 1D the reference explicitly does *not* clamp `t1` because `|x1| <= 1` "always" — with truncation `x1 = -1.9`, `t1 = 1 - 3.61 = -2.61`, `t41 = 46.4`, and the corner contribution explodes. Sampling `x ∈ [-5, 5]` at 1e5 points gives a range of **[-323.81, +242.86]**; the same sweep over `[0, 5]` gives `[-0.173, 0.401]`.
+  - `sdnoise3(d, x, 0.3, 0.7)` swept over `x ∈ [-3, 3]` at 2e5 points has a maximum step between adjacent samples of **0.2335** (at x ≈ -1.75); the identical sweep over `x ∈ [1, 7]` has max step **0.00154**. Simplex noise is C¹-continuous, so a 150× jump is a discontinuity, not sampling resolution. Same for `sdnoise2` (0.355 vs 7.5e-5) and `sdnoise4` (0.722 vs 0.00106).
+  - Real caller: `engine/graphics/particles/particular/engine/simulator/SimulationStepCurlNoiseAcceleration.js:59` → `core/math/noise/curl_noise_3d.js:18` samples `sdnoise3` at `x - 231.141, ..., z - 54.4341`, i.e. permanently in the broken negative region for typical world coordinates.
+- **Fix**: Replace every `x | 0` / `xs | 0` cell computation in `sdnoise.js` with `Math.floor(...)` (the existing `& 0xff` / `& 255` wraps already handle negative indices correctly). Note the pinned regression values in `sdnoise.spec.js:111,124,160,173` were captured from the buggy field and must be re-derived after the fix.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-2 `hammersley_sequence` seeds the radical-inverse iteration with `i/count`, producing duplicates
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/statistics/hammersley_sequence.js:10`
+- **Defect**: The loop body is the correct incremental Halton "next value" step (Wikipedia *Halton sequence*, fast method: `x = d-n; y = d/b; while x<=y: y/=b; n = (b+1)y - x`), which requires the iteration to start from `t = 0` and be applied `i` times to yield the `i`-th radical inverse. The code instead initialises `t = i / count`, which is not a valid state of that recurrence, so the returned values are not a radical inverse and the set is not low-discrepancy — it contains repeats.
+- **Failure scenario**: `hammersley_sequence(i, 2, 8)` for `i = 0..7` produces
+  `[0, 0.625, 0.125, 0.5625, 0.625, 0.3125, 0.5625, 0.4375]` — only **6 distinct values out of 8** (0.625 and 0.5625 each appear twice). The van der Corput / base-2 Halton sequence (what the sibling `halton_sequence(2, i)` correctly returns) is `[0, 0.5, 0.25, 0.75, 0.125, 0.625, 0.375, 0.875]`. Base 3 is equally wrong: produced `[0, 0.4583, 0.9167, 0.4861, 0.9444, 0.2176, 0.9722, 0.1466]` vs correct `[0, 1/3, 2/3, 1/9, 4/9, 7/9, 2/9, 5/9]`.
+  Two samples landing on the same value defeats the entire purpose of a low-discrepancy sequence (the doc line 2 says "Low discrepancy sequence").
+- **Fix**: `let t = 0;` (the `count` parameter then becomes unused for this coordinate — the `i/count` term is the *first* Hammersley coordinate, which belongs in the caller alongside this radical inverse, exactly as `hammersley_sequence_2d.js:15-16` already does). Alternatively delegate to `halton_sequence(R, i)`, which is both correct and O(log i) rather than O(i).
+- **Confidence**: Confirmed
+
+---
+
+### MATH-3 `computeStatisticalPercentile` selects the order statistic one rank too high
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/statistics/computeStatisticalPercentile.js:23-24`
+- **Defect**: `start = floor(n * low)` is a half-open lower bound while `end = ceil(n * high)` is used as an **inclusive** upper index. Both are one greater than the correct 0-based rank; only clamping to `n-1` hides it at `high = 1`. For a point query (`low === high === p`) the returned element is the one at index `floor(p*n)` instead of the `p`-th order statistic.
+- **Failure scenario**: With `values = [1,2,3,4,5,6,7,8,9,10]`:
+  - `computeStatisticalPercentile(values, 0.9, 0.9)` → **10**. 10 is the *maximum* (100th percentile). Nearest-rank definition (Hyndman & Fan type 1): index `ceil(0.9*10) - 1 = 8` → **9**.
+  - `computeStatisticalPercentile(values, 0.5, 0.5)` → **6**, while `computeStatisticalMedian(values)` on the same data returns **5**. The library disagrees with itself about the 50th percentile.
+  - `computeStatisticalPercentile(values, 0, 0.4)` → **3**; the bottom 40 % of the data is `[1,2,3,4]`, whose (lower) median is **2** — the range wrongly includes index 4 (value 5, the 50th-percentile element).
+- **Fix**: Use `ceil(n·p) - 1` for both bounds:
+  `const start = clamp(Math.ceil(n * percentile_low) - 1, 0, n - 1);`
+  `const end = clamp(Math.ceil(n * percentile_high) - 1, 0, n - 1);`
+  Verified this keeps both existing spec cases green (`(0, 0.5) → 2`, `(0.5, 1) → 7`) while fixing `(0.5, 0.5) → 5` and `(0.9, 0.9) → 9`.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-4 `roundFair` never rounds a negative number up
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/random/roundFair.js:9`
+- **Defect**: `number % 1` in JavaScript keeps the sign of the dividend, so for a negative input `mantissa` is negative. `random()` returns a value in `[0, 1)`, so `roll > mantissa` is unconditionally true and the function always takes the `Math.floor` branch. The documented contract — "a fraction is rounded up or down with probability equal to the fraction", i.e. an unbiased stochastic rounding with `E[roundFair(x)] === x` — is violated.
+- **Failure scenario**: `roundFair(-2.3, Math.random)` returns **-3** for every draw (verified: `()=>0.9 → -3`, `()=>0.1 → -3`; mean over 10 000 `Math.random` draws = **-3.0**). Expected: -3 with probability 0.3 and -2 with probability 0.7, mean **-2.3**. Positive control `roundFair(2.3, Math.random)` gives mean 2.2967, so the positive path is correct.
+- **Fix**: Use the Euclidean fraction: `const mantissa = number - Math.floor(number);` (or `euclidean_modulo(number, 1)`, which already exists in this package). With `-2.3` that gives `0.7`, and `roll > 0.7` (probability 0.3) → `floor = -3`, else → `ceil = -2`, mean -2.3.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-5 `fract` truncates toward zero and wraps at 2³¹
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/fract.js:9`
+- **Defect**: `const whole = v >> 0;` performs `ToInt32`, which (a) truncates toward zero rather than flooring and (b) wraps modulo 2³². The JSDoc explicitly cites the GLSL `fract` reference page and states the result "is calculated as x - floor(x)".
+- **Failure scenario**:
+  - `fract(-0.1)` → **-0.1**; GLSL/documented `x - floor(x)` → **0.9**. `fract(-0.25)` → -0.25 vs 0.75.
+  - `fract(1e10)` → **8589934592**; expected **0**. (`1e10 >> 0 === 1410065408`.)
+  - `fract(2147483648.5)` → **4294967296.5**; expected **0.5**.
+  The 2³¹ wrap is wrong under *any* reading of the contract — the result is not even in `(-1, 1)`.
+- **Fix**: `return v - Math.floor(v);`. Note `fract.spec.js:7-9` currently pins the truncating behaviour (`fract(-0.1) === -0.1`, `fract(-1.1) === -0.1`) and must be updated with the fix, not used as justification for the current code.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-6 `squirrel3` does not use 32-bit wrapping multiplication, so it is not the cited hash and collides
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/hash/squirrel3.js:13`, `:18` (also `:15`, `:19`)
+- **Defect**: The cited Squirrel3 (Eiserloh, GDC 2017) is defined over `unsigned int` with wrapping multiplies and *logical* right shifts. Here `value * BIT_NOISE1` and `hash *= BIT_NOISE3` are IEEE-754 double multiplies: an int32 operand times a ~2³² constant produces up to ~2⁶⁰, far beyond the 53-bit mantissa, so the low bits are **rounded away** before `ToInt32` takes them. Additionally `hash >> 8` (lines 15, 19) is an arithmetic shift where the reference uses a logical shift, so for negative intermediates different bits are mixed in.
+- **Failure scenario**: `squirrel3(0)` → **436901382**; a faithful 32-bit implementation (`Math.imul` + `>>>`) gives **436901570**. `squirrel3(1)` → 1910996822 vs reference 725778245. More consequentially, the reference is a bijection on 32 bits: over the 200 000 consecutive inputs `0..199999` it produces **200 000 distinct outputs**, whereas `squirrel3` produces only **199 763** — 237 collisions purely from the lost mantissa bits. (This is almost certainly the cause of the "low entropy" note in the file's own header comment.)
+- **Fix**: `let hash = Math.imul(value | 0, BIT_NOISE1);` … `hash = Math.imul(hash, BIT_NOISE3);`, and change both `>> 8` to `>>> 8`. Any callers persisting these hashes must be re-keyed.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-7 `m2_svd` / `m2_polar_decomp` emit factors in the opposite storage convention to their input
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/linalg/m2/m2_svd.js:7-19`, `H:/git/moh/app/src/mir-engine/meep/src/core/math/linalg/m2/m2_polar_decomp.js:8`, `H:/git/moh/app/src/mir-engine/meep/src/core/math/linalg/m2/m2_polar_decomp_noS.js:5`
+- **Defect**: The input `m` is read as transposed storage (`m2_polar_decomp_noS.js:20` computes `y = m[2] - m[1]`, i.e. `A01 - A10`, the negation of taichi's `A[1,0] - A[0,1]`), but `U`, `V` and `R` are written in plain row-major. Consequently the documented reconstruction identities do not hold when evaluated with this package's own `m2_multiply`/`m2_transpose`. The two polar docs already contradict each other (`m = S * R` vs `m = R * S`) and neither is the relation that actually holds.
+- **Failure scenario**:
+  - `m = [1, -2, 5, 3]`. After `m2_svd(U, S, V, sig, m)`, computing `U·Σ·Vᵀ` exactly as `m2_svd.spec.js:16-20` does yields **`[1, 5, -2, 3]`** — the transpose of `m`, not `m`. The doc (`m2_svd.js:7`) asserts `m = U * Σ * V^T`. The existing spec only checks reconstruction for symmetric inputs (`[1,0,0,1]`, `[2,0,0,3]`, `[2,1e-7,1e-7,3]`), where a transpose is invisible; the one asymmetric case `[1,-2,5,3]` checks only singular-value ordering.
+  - `m = [1, 2, 3, 4]`. `m2_polar_decomp(R, S, m)` gives `R = [0.98058, 0.19612, -0.19612, 0.98058]`, `S = [0.58835, 2.15728, 2.15728, 4.51067]`. `m2_multiply(x, S, R)` (the documented `m = S * R`) yields **`[0.15385, 2.23077, 1.23077, 4.84615]`** — neither `m` nor `mᵀ`. The relation that actually holds is `m2_multiply(x, R, S) = [1, 3, 2, 4] = mᵀ`.
+  - Downstream consequence (outside this package but caused by it): `engine/physics/mls-mpm/MLS_MPM.js:373-374` stores `F` in transposed layout (`m2_multiply(F, p.F, m2_temp0)` is only correct under that convention) and then writes back `m2_multiply(m2_temp0, svd_u, sig); m2_multiply_transposed(p.F, m2_temp0, svd_v)`, which stores the untransposed `U Σ Vᵀ` into a transposed slot — i.e. the plastically-clamped deformation gradient is transposed on every substep whenever `F` is non-symmetric (any shear).
+- **Fix**: Pick one convention and make it total. Cheapest correct change that preserves the taichi port: transpose the emitted rotations so all five arrays share the input's storage — write `R = [c, -s, s, c]` in `m2_polar_decomp_noS`, mirror it in the two `V` branches of `m2_svd.js:79-91`, and swap the operand order of `m2_multiply(U, U, V)` at `m2_svd.js:95`. Then add an asymmetric-input reconstruction case to `m2_svd.spec.js` (e.g. `[1,-2,5,3]`) so the invariant is pinned, and reconcile the three JSDoc blocks.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-8 `ParameterLookupTable.toBinaryBuffer` picks an item-count width one bit too small at exact powers of two
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/lookup/ParameterLookupTable.js:110-122`
+- **Defect**: The width is chosen from `Math.log2(itemCount)`, but the number of bits needed to store `itemCount` is `floor(log2(itemCount)) + 1`. At an exact power of two the test is off by one and too narrow a field is selected; `DataView.setUint8`/`setUint16` then silently truncate modulo the field.
+- **Failure scenario**: A table with exactly **256** entries: `log2(256) = 8`, so `itemCountByteSize = 1` and `buffer.writeUint8(256)` writes **0**. `fromBinaryBuffer` then reads `itemCount = 0` and reconstructs an **empty** table — total silent data loss on round-trip. Same at 65 536 entries (`writeUint16(65536) → 0`). 255 and 257 entries round-trip correctly, so the failure is exactly at the boundaries.
+- **Fix**: Compare against the value, not the log: `if (itemCount <= 0xFF) ... else if (itemCount <= 0xFFFF) ... else if (itemCount <= 0xFFFFFFFF) ...`.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-9 `copysign` flips the sign when the sign source is `+0`
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/copysign.js:9-14`
+- **Defect**: The sign is decided by `(x > 0 && y > 0) || (x < 0 && y < 0)`. When `y` is `+0` (or `NaN`) neither disjunct holds, so the `else` branch negates `x`. C99 `copysign` takes the *sign bit* of `y`; the sign bit of `+0` is clear, so the result must be `+|x|`.
+- **Failure scenario**: `copysign(3, 0)` → **-3**; C99/`tgmath.h` (which the JSDoc cites as the source) gives **+3**. `copysign(-3, 0)` → **+3** (correct by accident). `copysign(3, NaN)` → -3, where C gives +3. `copysign(3, -0)` → -3 (correct). The existing spec never passes `0` as `y`.
+- **Fix**: `return (y < 0 || Object.is(y, -0)) ? -Math.abs(x) : Math.abs(x);`
+- **Confidence**: Confirmed
+
+---
+
+### MATH-10 `softmax` overflows to `NaN` for large inputs
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/statistics/softmax.js:12`, `:19`
+- **Defect**: `Math.exp` is applied to the raw components. `Math.exp(z) === Infinity` for `z > 709.78`, and `Infinity / Infinity === NaN`. The standard formulation (and every reference implementation, cf. the linked Wikipedia article's "numerical stability" note) subtracts `max(z)` first — mathematically identical because `softmax(z) === softmax(z - c)` for any constant `c`.
+- **Failure scenario**: `softmax([1000, 1], 0, 2)` → **NaN**; the correct value is **1** (to within double precision). `softmax([800, 801], 1, 2)` → **NaN**; correct value **0.7311**.
+- **Fix**: Compute `let max = -Infinity; for (j…) max = Math.max(max, z[j]);` then use `Math.exp(z[i] - max)` and `sum += Math.exp(z[j] - max)`.
+- **Confidence**: Confirmed
+
+---
+
+## Checked and found correct (recorded so they are not re-reviewed)
+
+- `linalg/lu_factor_linear_system.js` / `lu_solve_linear_system.js` — faithful port of VTK `LUFactorLinearSystem`/`LUSolveLinearSystem`; the column-major index map `A[j*size+i] ≡ A[i][j]` is applied consistently in every loop, including the row interchange and the `scale[maxI] = scale[j]` step.
+- `idct_1d.js` / `idct_2d.js` — element-for-element match with the ffmpeg AAN `idct_1d`. `idct_2d` deliberately omits ffmpeg-exr's extra `*0.5`: the only caller is the JPEG decoder (`engine/asset/loaders/image/jpeg/idct8x8_float.js`), and the JPEG convention is exactly `1/2` per dimension. Verified DC round-trip: `F(0,0) = 8` → `f(x,y) = 1`.
+- `linalg/solve_linear_system_GEPP_2x2.js` — exhaustively walked every zero-pattern branch (single, double, singular); column-swap/row-swap bookkeeping and the final un-swap of `x` are correct in all cases.
+- `linalg/eigen/matrix_symmetric_3x3_eigen.js` — Numerical Recipes cyclic Jacobi; rotation formulas, third-index update, eigenvector accumulation and ascending sort all correct; `r = 3 - p - q` is valid for all three plane pairs.
+- `linalg/givens/givens_rotation_coefficients.js` — both branches satisfy `-s·a + c·b = 0` and `c² + s² = 1`.
+- `noise/create_simplex_noise_2d.js` — correct Fisher–Yates (`r = i + ~~(random()*(256-i))`, range `[i, 255]`), correct `Math.floor`, all `perm[]` indices bounded by 511.
+- `spline/computeCatmullRomSpline.js`, `computeCatmullRomSplineUniformDistance.js`, `computeNonuniformCatmullRomSplineSample.js` — Wikipedia centripetal Catmull–Rom barycentric form; endpoint interpolation exact at `f = 0` and `f = 1`.
+- `spline/interpolate_bicubic.js` — algebraically identical to the standard `p1 + 0.5t(p2-p0 + t(2p0-5p1+4p2-p3 + t(3(p1-p2)+p3-p0)))`.
+- `solveCubic.js` — the trigonometric branch's `acos(3q/(pm))` argument is provably in `[-1,1]` whenever `ratio < 0`, so no clamp is needed.
+- `physics/kinematics/computeInterceptPoint.js` — `(V·V - s²)t² + 2(V·D)t + D·D = 0` and the smallest-non-negative-root selection are both correct.
+- `compute_legendre_polynomial.js` — exact match with Green's *Spherical Harmonic Lighting* reference.
+- `modified_bessel_i0.js` — term recurrence `T_k = T_{k-1}·y/k²` matches `Σ (x²/4)^k/(k!)²`.
+- `random/randomIntegerBetween.js`, `random/random_pick_weighted_index.js`, `random/seededRandom_Mulberry32.js`, `random/seededRandom_MersenneTwister.js` — inclusive/uniform bucketing, cumulative-weight search bounds, and both generator kernels verified. (Mulberry32's unbounded `_seed` accumulator was measured: after seeding at 2⁶⁰ the distinct-output count over 100 000 draws is 99 996 vs 99 999 at seed 0 — not a reportable degradation.)
+- `statistics/computeStatisticalVariance.js` (population divisor `n`) and `statistics/computeStatisticalMedian.js` (lower median on even counts) are both **intentional**, pinned by their specs — not defects.
+- `physics/brdf/*`, `physics/pdf/*`, `physics/irradiance/*` — `D_GGX` matches Filament's listing, `pdf_GGX` is self-consistent with it on the α parameterisation, `cone_cosine_from_roughness` is the exact inverse of `reflection_sample_weight`'s spherical gaussian, `pdf_normal` is the correct `N(0,σ)` density, and `ior_to_reflectivity`/`reflectivity_to_ior` are exact mutual inverses.
+- `physics/mie/ri_*.js` — lookup positions are supplied in nanometres, so `ParameterLookupTable.sample(wavelength_nm, …)` interpolates on the right axis.
+
+---
+
+## Unspecced files
+
+67 source files under `core/math/` have no adjacent `*.spec.js`:
+
+```
+DEG_TO_RAD.js
+EPSILON.js
+FLT_EPSILON_16.js
+FLT_EPSILON_32.js
+FLT_EPSILON_64.js
+GOLDEN_RATIO.js
+NumericType.js
+PI.js
+PI2.js
+PI_HALF.js
+PI_RECIPROCAL.js
+RAD_TO_DEG.js
+build_gaussian_kernel_2d.js
+euclidean_modulo.js
+fabsf.js
+hash/lowbias32.js
+idct_1d.js
+idct_2d.js
+interval/intersects1D.js
+interval/separation1D.js
+linalg/lu_factor_linear_system.js
+linalg/m2/m2_polar_decomp.js
+linalg/m2/m2_polar_decomp_noS.js
+linalg/sparse/spm_matvec.js
+linalg/sparse/spm_matvec_transpose.js
+lookup/ParameterLookupTable.js
+lookup/ParameterLookupTableFlags.js
+mix.js
+modified_bessel_i0.js
+noise/curl_noise_3d.js
+noise/curl_noise_3dt.js
+physics/brdf/diffuse_GGX.js
+physics/brdf/fresnel_Schlick.js
+physics/brdf/fresnel_Schlick_optimized.js
+physics/brdf/fresnel_Schlick_original.js
+physics/bsdf/bsdf_schlick.js
+physics/ior_to_reflectivity.js
+physics/mie/MIE_PARTICLES_STANDARD.js
+physics/mie/MIE_PARTICLES_STANDARD_PRECOMPUTED.js
+physics/mie/lorenz_mie_coefs.js
+physics/mie/ri_air.js
+physics/mie/ri_ammonium_sulfate.js
+physics/mie/ri_brine.js
+physics/mie/ri_dust.js
+physics/mie/ri_pollen.js
+physics/mie/ri_smoke.js
+physics/mie/ri_soot.js
+physics/mie/ri_water.js
+physics/pdf/pdf_normal.js
+physics/reflectivity_to_ior.js
+random/generate_halton_jitter.js
+random/randomBytes.js
+random/random_pick_weighted_index.js
+random/seededRandom.js
+spline/catmull_rom_compute_T.js
+spline/computeNonuniformCaltmullRomSplineDerivative.js
+spline/computeNonuniformCatmullRomSplineSample.js
+spline/interpolate_bicubic.js
+spline/spline3_hermite_intersection_spline3_hermite_2d.js
+spline/spline3_hermite_intersects_spline3_hermite.js
+spline/v3_computeCatmullRomSplineUniformDistance.js
+sqr.js
+statistics/computeStatisticalMedian.js
+statistics/computeStatisticalStandardDeviation.js
+statistics/generate_hammersley_jitter.js
+statistics/hammersley_sequence.js
+statistics/hammersley_sequence_2d.js
+```
+
+Of the 10 findings, 4 land in unspecced files (`hammersley_sequence.js`, `ParameterLookupTable.js`, `m2_polar_decomp*.js`); the other 6 land in files whose specs exist but only exercise the working half of the input domain (`sdnoise.spec.js` never samples negative coordinates for 1/3/4D, `fract.spec.js` pins the bug, `copysign.spec.js` never passes `y = 0`, `m2_svd.spec.js` reconstructs only symmetric inputs, `roundFair.spec.js` never passes a negative, `computeStatisticalPercentile.spec.js` never makes a point query).