Implementation Status — Mathematician FAQ

This page wires the current code, tests, and benchmark assets to the concrete questions mathematicians keep asking about the project:

1. What mathematical structures do we already implement?
2. How trustworthy are the numeric kernels today (order-of-magnitude error bounds, failure modes)?
3. Which tests exercise the algebraic paths (as opposed to “it runs” tests)?
4. Where do we already compute $c_{EHZ}$ and the systolic ratio against trusted values?
5. How long does a full systolic-ratio evaluation take on typical inputs (e.g., nine facets)?
6. Which polytope families are covered (Lagrangian products vs. generic/symmetric shapes)?

Each section cross-references the relevant thesis pages, Rust modules, and benchmark snapshots so you can keep drilling down.

1. What features exist today?

Summary: All math-facing layers (geometry, oriented-edge search, generators, atlas pipeline) now run off the same native solver; remaining work is about confidence (more fixtures, telemetry), not missing features.

2. Correctness levels and numerical tolerances

Expectation for large batches (1e6 polytopes). The geometry kernels (H/V conversions, volume, 2D push-forward) already run deterministically with stable tolerances, so we do not anticipate catastrophic drift at scale. The atlas builder now invokes the oriented-edge solver for every row; when the solver fails to find a minimizer the row is explicitly marked as NaN. Achieving “0 false systolic ratios” therefore boils down to tracking/understanding those fallbacks rather than wiring new features.

3. Mathematically meaningful tests

• Graph construction & $\tau$-domain sanity: crates/viterbo/src/oriented_edge/tests.rs::smoke_graph_build_cube_edges_exist and ::tau_domain_basic_properties_on_cube show every ridge/facet pairing respects the analytic inequalities derived in the thesis.
• Fixed-point closure: ::cycle_closure_unique_fixed_point_on_tiny_graph constructs a contraction with known fixed point $z^*$ and verifies the recovered action matches zero.
• Capacity invariants: ::golden_capacity_product_of_squares_matches_min_area, ::golden_capacity_hypercube_minus1_1_pow4_is_4, and ::invariance_under_block_rotation_symplectomorphism compare against Siburg’s area formula and symplectic invariance, catching regressions in both graph building and DFS.
• Non-product shapes: ::cross_polytope_and_simplex_smoke_capacities exercises the solver on the $\ell_1$ ball and the orthogonal simplex (after H-rep conversion), ensuring we cover symmetric/non-generic catalogs.
• Python orchestration: tests/e2e/test_atlas_build.py rebuilds a tiny atlas config, checks the hypercube row, and confirms the preview asset is non-empty—linking the native kernels to stage_save semantics.
• Random generator replay: The rand4 module replays every generated polytope via stored tokens so atlas provenance can be trusted.

Together these tests cover every mathematical code path, from native solvers to the Python atlas orchestration.

4. Where we already compute capacities

No published literature provides “trusted” values for generic random polytopes, so atlas now streams solver outputs directly from the native bindings; future work is to compare aggregates (e.g., by family) and watch for anomalous clusters.

5. Performance snapshots (including nine facets)

Volume scaling. Criterion benches on random H-reps highlight how 4D volume cost grows with facet count:

Updated 2025-11-11 01:41:11Z · commit 585a129 · host ab5b4864ef14 · rustc rustc 1.91.1 (ed61e7d7e 2025-11-07)

Oriented-edge internals. Microbenchmarks for the $\psi_{ij}$ push-forward, $\tau$ inequality, and per-edge lower bound kernels (derived from the cube fixture) show sub-millisecond latencies:

Updated 2025-11-11 01:41:11Z · commit 585a129 · host ab5b4864ef14 · rustc rustc 1.91.1 (ed61e7d7e 2025-11-07)

End-to-end systolic ratio for nine facets. A deterministic “cube with an oblique cap” (eight axis-aligned halfspaces plus $ (1,1,1,1)/2 \cdot x \le 1.8$) gives us the requested data point:

Measured with cargo run -p viterbo --example systolic_ratio --release on 2025-11-08 16:34:12 UTC (commit 7bd6b64)

Interpretation:

• Volume dominates only for very large facet counts (≥48); for nine facets, the facet-fan kernel finishes in ~0.08 ms.
• The oriented-edge solver spends ≈0.65 ms on the nine-facet sample (including graph build + DFS). Because both steps are deterministic, a full systolic ratio evaluation currently lands well under 1 ms on this hardware.
• The atlas builder uses this same native solver at dataset time; tests/e2e/test_atlas_build.py asserts the hypercube capacity ($4$) and systolic ratio ($0.5$) so regressions surface immediately.

6. Supported polytope families

Bottom line: We already support both Lagrangian product families and the generic “atlas background” polytopes. Symmetric shapes are part of the fixture catalog, the solver has dedicated tests for them, and atlas rows now carry finite capacity_ehz / systolic_ratio values unless the solver reports “no cycle”.

7. Outstanding gaps & next steps

1. Instrument solver fallbacks: record how many atlas rows return None (degeneracies, rotation budget hits) and surface that statistic next to dataset summaries.
2. Expand golden fixtures beyond products/symmetric bodies (e.g., orthogonal simplex values, Chaidez–Hutchings counterexample) once their analytic capacities are derived in the thesis.
3. Document failure budgets: classify the fallback causes (e.g., canonicalization errors vs. true absence of admissible cycles) so mathematicians know what “NaN” means operationally.

Keeping this page updated whenever a new generator, test, or visualization lands will make it trivial to answer “are we ready?” the next time the conjecture discussion resurfaces.