Files
ConformalLabpp/doc/reviewer/math-derivation-citation-audit-2026-05-31.md
Tarik Moussa fed39da8fe docs(reviewer): update audit status + add finding-orchestration plan
Session 1 (2026-05-31) resolved 26 findings across Sonnet/Haiku/Opus; 298/298
CGAL tests green.  Bring the audit docs in line with reality:

- README.md: G0 banner now records that the original authors were contacted by
  email about porting/relicensing rights (awaiting reply); headline-status cells
  updated per finding; new "Session 1 — implemented" record; link to the plan.
- Per-audit resolution banners (api-performance, numerical-stability,
  input-validation, test-coverage, math-citation, thread-safety) + G0-blocked
  banners (cgal-submission, dependency-license).
- NEW finding-orchestration.md: the meta-plan mapping every finding to a session,
  an implementing model (Haiku/Sonnet/Opus by the "how much must be understood"
  rule), and an Opus review gate after each implementation session.  Records S1
  (done) and lays out S2–S6 so the next session can be picked up cold.

Docs only — no code change.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-05-31 18:23:30 +02:00

9.8 KiB
Raw Blame History

Math-Derivation & Citation Audit — ConformalLabpp

Date: 2026-05-31 Auditor: External reviewer (Claude Opus 4.8) Scope: Correctness of the mathematical derivations in doc/math/ and the integrity/consistency of the literature citations in code comments and docs. Focus: Are the derivations sound and are the citations accurate, complete, and consistent? Distinct from java-port-audit.md (which checks code vs. Java) — this checks code/docs vs. the published mathematics.

Status legend: 🔴 Critical · 🟡 Important · 🔵 Polish

Resolution status (2026-05-31, Session 1): M1 (KolpakovMednykh + Meyerhoff/Ushijima added to references.md), M2 (BPS year unified to the published 2015), M4 (citation format normalized). M3 (re-verify future-dated/arXiv citations) open → S4; M5 (prose derivation review) needs a domain expert (out of model scope). See finding-orchestration.md.

Good news up front: doc/math/references.md is unusually scholarly and already contains several self-corrections (the Glickenstein "eq. (4.6)" numbering fix → §5.2 parametrization; the Schläfli boundary-term re-attribution to RivinSchlenker 1999; the BowersStephenson formula-vs-theory clarification). That is exemplary and rare. The findings below are the gaps that remain despite this strong baseline.


Summary table

ID Sev Title Location
M1 🟡 KolpakovMednykh volume formula is used in code but absent from references.md hyper_ideal_utility.hpp:80, hyper_ideal_functional.hpp:321
M2 🟡 BPS circle-packing paper cited as "2010" in code but "2015" in references.md — inconsistent year for a load-bearing reference of an implemented phase cp_euclidean_functional.hpp, newton_solver.hpp, Discrete_circle_packing.h vs references.md
M3 🟡 Future-dated / arXiv-only citations (2025, 2026) back unimplemented phases but sit alongside implemented ones — re-verify against published versions before submission references.md
M4 🔵 No canonical citation-key convention — the same work appears as Luo 2004 / Luo-2004 / Luo (2004) / Luo's 2004 etc. code + docs
M5 🔵 The large hand-derivations (notably hyperideal-hessian-derivation.md, 34 KB) have their results numerically validated but the prose derivations are unreviewed by a domain expert doc/math/*-derivation.md

M1 — 🟡 KolpakovMednykh volume formula not in references.md

Evidence

// hyper_ideal_utility.hpp:80
/// the Kolpakov-Mednykh formula (arxiv math/0603097).  Same as Java …
// hyper_ideal_functional.hpp:321
///   * Exactly one vertex ideal (…) → Kolpakov-Mednykh volume

grep -c Kolpakov doc/math/references.md0.

Problem

The hyper-ideal volume computation — a core ingredient of the Springborn-2020 functional and the energy itself — rests on the KolpakovMednykh formula (and a Meyerhoff/Ushijima component, cited 6× elsewhere). The code cites it inline by arXiv ID, but references.md, the stated "citation source of truth", omits it entirely. A reviewer auditing the math foundation against the references file would find a load-bearing formula with no entry.

Fix

Add a references.md row: Kolpakov, Mednykh — (full title), arXiv math/0603097, mapped to hyper_ideal_utility.hpp. Likewise confirm the Meyerhoff / Ushijima 2006 volume reference (cited in code) has a row.

Acceptance criteria

  • Every formula cited inline in code/include/ has a matching references.md entry.

M2 — 🟡 BPS paper: "2010" in code vs "2015" in references.md

Evidence

  • Code/docs cite it as 2010 (e.g. cp_euclidean_functional.hpp, newton_solver.hpp, CGAL/Discrete_circle_packing.h, plus 26 doc hits of "Bobenko-Pinkall-Springborn 2010").
  • references.md lists it as 2015: "Discrete conformal maps and ideal hyperbolic polyhedra, Geometry & Topology 19(4) (2015), arXiv 1005.2698."

Problem

Both are "correct" in a sense — the arXiv preprint (1005.2698) is 2010, the published Geometry & Topology version is 2015 — but the project uses the two years interchangeably for the same paper, including in the public CGAL header (Discrete_circle_packing.h) and the phase-9a-validation.md mapping. This is the reference for an implemented, shipped phase (9a.1 CP-Euclidean), so the inconsistency is user-visible and would be flagged in CGAL review.

Fix

Pick one canonical citation (recommend the published 2015 Geometry & Topology version, with the arXiv 2010 ID noted) and use it everywhere. Update the code comments and docs that say "2010" to match references.md, or vice-versa — but make them agree.

Acceptance criteria

  • The BPS circle-packing paper is cited with a single, consistent year across code and docs (matching references.md).

M3 — 🟡 Future-dated / preprint citations must be re-verified before submission

Evidence

references.md cites, among others:

  • Bobenko, Lutz 2025 (arXiv 2310.17529) — Phase 9d.2 (🔜 planned)
  • Bowers, Bowers, Lutz 2026 (arXiv 2601.22903) — Phase 9b-analytic / 10c
  • Lutz 2024 PhD thesis; Bobenko-Lutz 2024 IMRN

Problem

Two issues:

  1. Verification: arXiv-only and future-dated (2025/2026) references can change (version bumps, final published venue, even withdrawal). Before any public release or CGAL submission, each should be re-checked against its final published form. The arXiv ID 2601.22903 in particular (Jan 2026) is very recent relative to this audit and warrants a manual confirmation that it resolves.
  2. Scope confusion: these back unimplemented "future research" phases (🔜), but the Bowers-Bowers-Lutz 2026 row claims it "supports correctness of the analytic Hessian" — which is implemented (Phase 9b-analytic, ). A reader could conclude the shipped analytic Hessian depends on a 2026 preprint. Clarify that the implemented derivation stands on its own (it is numerically validated, see M5) and the 2026 paper is corroborating, not foundational.

Fix

  • Re-verify every 20242026 / arXiv-only citation against its published version; add DOIs once available.
  • Sharpen the wording so implemented-phase correctness is never described as resting on an unpublished/future reference.

Acceptance criteria

  • All post-2023 citations are confirmed to resolve; no implemented-phase correctness claim depends solely on a preprint/future reference.

M4 — 🔵 No canonical citation-key convention

Evidence

The same works appear in many surface forms across code and docs: Luo 2004 / Luo-2004 / Luo (2004) / Luo's 2004; Springborn 2020 / Springborn (2020) / Springborn-2020; Bowers-Stephenson vs Bowers, Stephenson.

Problem

Cosmetic but it defeats grep-ability and cross-referencing (cf. the false-negative in this audit's own tooling: Bowers-Bowers-Lutz 2026 did not match the comma-form Bowers, Bowers, Lutz). For a library aiming at CGAL, a consistent citation key (e.g. [SpringbornDCG2020]) referenced from both code and references.md is the clean solution.

Fix

Define short citation keys in references.md and use them verbatim in code comments and docs.

Acceptance criteria

  • One canonical key per reference; code/docs cite the key, not free-form variants.

M5 — 🔵 Large derivations: results validated, prose unreviewed

Evidence

doc/math/hyperideal-hessian-derivation.md (34 KB) derives the analytic HyperIdeal Hessian; validation.md and the FD-vs-analytic tests (test_hyper_ideal_hessian.cpp, block-FD vs full-FD) check the result numerically.

Problem

The derivation result is well-protected — the analytic Hessian is tested against finite differences, so an algebra error would surface as a test failure. But the prose derivation itself (the step-by-step algebra a reader would follow to trust or extend it) has not been reviewed by a domain expert, and a derivation that "happens to match FD at the tested points" can still contain a sign/indexing slip that the specific test meshes don't excite.

Fix

  • Have a discrete-differential-geometry expert read hyperideal-hessian-derivation.md and discrete-conformal-theory.md for derivational soundness (this is naturally part of the planned reviewer meeting — see briefing.md).
  • Strengthen confidence cheaply by adding a randomized/property-based FD check (random valid DOF vectors on several genera) so the numerical safety net covers more than the fixed smoke meshes.

Acceptance criteria

  • The key derivations are signed off by a domain reviewer, and/or the FD validation is randomized rather than fixed-mesh-only.

What is already good

  • references.md is scholarly and self-correcting — it explicitly fixes its own earlier over-citations (Glickenstein equation numbering, Schläfli→RivinSchlenker, BowersStephenson). This is well above typical project hygiene.
  • Implemented vs. planned references are marked / 🔜 — the reader can tell which citations underpin shipped code (M3 only asks to keep that discipline airtight).
  • The primary source (Sechelmann 2016 PhD thesis, CC BY-SA 4.0) is correctly identified, and the Java provenance is linked — directly relevant to CGAL audit G0.
  • Derivation results are numerically validated (FD vs analytic) — the right safety net (M5 just asks to widen it and get a human sign-off).

Suggested order

  1. M2 (BPS year) + M1 (KolpakovMednykh) — quick citation fixes, user-visible.
  2. M3 (re-verify post-2023 refs; fix scope wording) — before any submission.
  3. M5 (expert sign-off + randomized FD) — fold into the reviewer meeting.
  4. M4 (citation keys) — polish.