A full audit of `doc/` plus root-level markdown files (27 files) against
the actual ground truth in the C++ code and the local Java repository at
`/Users/tarikmoussa/Desktop/conformallab/` revealed four pre-existing
mis-labels and a stale test count. All are corrected here.
Audit findings — corrected
─────────────────────────
1. **`InversiveDistanceFunctional` mis-labelled as Java port** (4 doc sites)
Empirical verification:
find /Users/tarikmoussa/Desktop/conformallab -iname "*nversive*"
(zero matches)
The class does NOT exist in `de.varylab.discreteconformal`. The C++
implementation is built from Luo 2004 + Glickenstein 2011 + Bowers-
Stephenson 2004 — new research, not a port.
Fixed in: java-parity.md, references.md, add-inversive-distance.md.
2. **HyperIdeal Hessian mis-labelled as "Java has analytic Hessian"**
Empirical verification: `HyperIdealFunctional.java:295-298`:
public boolean hasHessian() { return false; }
Java has NO Hessian at all. Both the FD (Phase 4a) and the block-FD
(Phase 9b) Hessians in C++ are research beyond the Java port. The
chain rule (b,a) → ℓ → ζ → α/β is the *mathematical formulation*
from Springborn 2020, not something Java implements.
Fixed in: java-parity.md.
3. **Stale test count** README:87 said "28 suites, 170 tests" — current
actual is 35 suites, 176 CGAL + 36 non-CGAL. Fixed.
4. **Tutorial framing** — `add-inversive-distance.md` was framed as
"porting an InversiveDistanceFunctional.java" that does not exist.
Rewritten as "Implementing the Inversive-Distance functional from
Luo 2004" with prominent verification block at top.
New document: `doc/roadmap/research-track.md`
─────────────────────────────────────────────
Consolidates everything in conformallab++ that goes beyond a Java port:
* Items already on `main`: HyperIdeal FD Hessian, period matrix τ
partial-research components, Möbius holonomy storage.
* Items on open PRs: CP-Euclidean (PR #8, port), Inversive-Distance
(PR #8, research), block-FD Hessian (PR #9, research).
* Planned research with full citations:
- **Phase 9b-analytic** — full analytic HyperIdeal Hessian via
Schläfli identity (Schläfli 1858/60) and chain rule through
ζ₁₃/ζ₁₄/ζ₁₅, citing Springborn 2020 §4, Cho-Kim 1999,
Glickenstein 2011 §4. Includes acceptance-criteria checklist
(per-case derivative cross-checks, gauge null space, PSD,
measured ≥ 3× speed-up, LaTeX correctness note).
- **Phase 9a.2-analytic** — analytic inversive-distance Hessian
via Glickenstein 2011 eq. (4.6).
- **Phase 10c** — full uniformization for genus g ≥ 2 (Fuchsian
group representation) — fully new research, no Java reference.
- **geometry-central** GC-1/2/3 exploratory track.
* Java backlog summary: 11 worth-porting Java classes identified by
the parallel survey (FundamentalPolygonUtility, DiscreteHarmonicForm-
Utility, DiscreteHolomorphicFormUtility, CanonicalBasisUtility,
HyperbolicCyclicFunctional, QuasiisothermicUtility, KoebePolyhedron, …).
~6 500 Java lines, ~5 months of porting work, organised by phase.
Updated documents
─────────────────
* CLAUDE.md
- New "Port-vs-research maintenance rule" with empirical verification
command and the four corrected mis-labels.
- Doc map: 23 → 24 documents (research-track.md added).
* README.md
- Test count corrected (170 → 176+36).
* doc/math/references.md
- Luo 2004 entry corrected ("new research" instead of "not yet ported").
- New entries for Bowers-Stephenson 2004, Glickenstein 2011,
Bobenko-Pinkall-Springborn 2010, Schläfli 1858/60.
* doc/roadmap/phases.md
- Phase 9 reorganised: 9a split into 9a.1 (port) / 9a.2 (research),
9b clarified as research (Java has no Hessian), 9c expanded with
Java line counts and effort estimates.
- Phase 10 reorganised: 10a/10b/10c with their Java prerequisites
explicitly listed; 10c flagged as "fully new research".
- Phase 10b' added: parallel research track (hyperbolic functional,
quasi-isothermic, Möbius centering).
- Phase 10c' added: optional Java-port additions (Koebe, circle
patterns, electrostatic sphere).
* doc/roadmap/java-parity.md
- Inversive-distance row: ❌ Java, ❌ C++ (Phase 9a.2) — new research.
- CP-Euclidean row added: ✅ Java, ❌ C++ (Phase 9a.1) — port.
- HyperIdeal Hessian row: ❌ Java, ⚠️ FD + block-FD in C++.
- Worth-porting table replaced with the survey results (12 classes,
Java line counts, suggested phases).
- "HyperIdeal Hessian: FD vs analytic" section rewritten with the
correction notice.
* doc/tutorials/add-inversive-distance.md
- Rewritten end-to-end with prominent verification block at top.
- Now correctly framed as "Implementing the Inversive-Distance
functional from Luo 2004" — research, not port.
- Includes the four required cross-validations:
limit cases, Bowers-Stephenson round-trip, FD-vs-analytic,
cross-validation against euclidean_functional at u=0.
- New "How to know if it's a port or research" closing section
with the empirical verification command.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
12 KiB
Development Roadmap
Legend: ✅ complete · 🔲 planned
Porting / research boundary:
Phases 1–7 are direct ports of the Java original and its dissertation.
From Phase 8 onwards the work goes beyond the scope of the Java library.
Phase 8 (CGAL package) is infrastructure. Phase 9 is porting of remaining Java features.
Phase 10+ is independent research with no direct Java reference implementation.
◼ Porting complete — Phases 1–7
Phase 1 Clausen / Lobachevsky / ImLi₂ special functions ✅
Phase 2 Hyper-ideal geometry (ζ, lᵢⱼ, αᵢⱼ, σᵢ, σᵢⱼ) ✅
Phase 3 CGAL Surface_mesh infrastructure + all three functionals
(Euclidean, Spherical, HyperIdeal)
+ analytical Hessians for Euclidean + Spherical
(HyperIdeal Hessian: symmetric FD — analytic deferred to 9b) ✅
Phase 4 Newton solver (SimplicialLDLT + SparseQR fallback)
+ Mesh I/O (OFF/OBJ/PLY) + example programs ✅ 68 tests
Phase 5 Priority-BFS layout + CLI app + JSON/XML serialisation ✅ 95 tests
Phase 6 Gauss–Bonnet check/enforce, tree-cotree cut graph (2g),
exact hyperbolic trilateration, layout normalisation ✅ 121 tests
Phase 7 MobiusMap, halfedge_uv, Möbius holonomy (SU(1,1)),
period matrix τ∈ℍ + SL(2,ℤ) reduction,
fundamental domain parallelogram + tiling ✅ 176 tests
◼ Infrastructure — Phase 8: CGAL Package
Goal: conformallab++ as a standalone CGAL package, submission-ready, fulfilling all CGAL package conventions with a traits-class design compatible with any CGAL-conforming mesh type.
8a Traits class & concepts
→ include/CGAL/Conformal_map_traits.h
Separates MeshType, KernelType, ScalarType from the algorithm.
Enables use with any CGAL-compatible mesh, not just Surface_mesh.
→ Concept checks via static_assert / CGAL_concept_check
8b Public CGAL header hierarchy
→ include/CGAL/Discrete_conformal_map.h (user-facing entry header)
→ include/CGAL/Conformal_newton_solver.h
→ include/CGAL/Conformal_layout.h
→ include/CGAL/Conformal_cut_graph.h
All existing include/conformallab/*.hpp remain as implementation details.
8c CGAL-style documentation
→ doc/Conformal_map/PackageDescription.txt
→ doc/Conformal_map/fig/ (pipeline diagrams)
→ Doxygen comments on all public concepts and functions
→ User_manual.md + Reference_manual.md
8d CGAL test format
→ test/Conformal_map/CMakeLists.txt (CGAL-style CMake)
Existing GTest tests remain; CGAL-format tests are added alongside.
8e Declarative YAML pipeline
→ Lightweight YAML format for reproducible experiments
(specification in doc/api/cgal-package.md)
→ Validator: checks require/provide tokens before execution
→ CLI integration: conformallab_core --pipeline experiment.yml
◼ Phase 9 — Mixed: remaining Java port + first research extensions
Audit 2026-05-21: Phase 9 was originally framed as "remaining porting", but a closer look at the local Java repository revealed: several Phase-9 items are not in Java at all (
InversiveDistanceFunctionaldoes not exist;HyperIdealFunctional.java:295-298declareshasHessian()=false). The plan below now distinguishes Java-port items from research items. Full research catalogue:research-track.md.
9a — Circle-packing functionals (split 2026-05-19)
─────────────────────────────────────────────────────
9a.1 CPEuclideanFunctional (Java port)
→ cp_euclidean_functional.hpp
Java source: CPEuclideanFunctional.java (260 lines)
Mathematical reference: Bobenko-Pinkall-Springborn 2010
Status: 🟡 PR #8 open, 10 tests passing.
9a.2 Inversive-distance functional (RESEARCH, not a port)
→ inversive_distance_functional.hpp
Java source: NONE. Empirically verified.
Mathematical reference: Luo 2004 + Bowers-Stephenson 2004 + Glickenstein 2011
Status: 🟡 PR #8 open, 11 tests passing.
Cross-validation: G_id(0) = G_eu(0) at 1e-10 (Glickenstein §5).
9b — HyperIdeal Hessian (RESEARCH — Java has no Hessian at all)
─────────────────────────────────────────────────────────────────
9b Block-FD HyperIdeal Hessian
→ Replace full FD in hyper_ideal_hessian.hpp
Java source: NONE (HyperIdealFunctional.java:295-298 declares
hasHessian()==false; Java has NO Hessian).
Algorithm: per-face 6×6 block, scatter to global sparse matrix.
Status: 🟡 PR #9 open, 7 tests passing, ~96× speed-up measured.
9b-analytic Full analytic HyperIdeal Hessian via Schläfli identity
→ planned, see research-track.md
Mathematical source: Springborn 2020 §4 + Schläfli 1858/60
+ Cho-Kim 1999 + Glickenstein 2011 §4
Algorithm: explicit chain rule through (bᵢ,aₑ) → ℓᵢⱼ → ζ₁₃/ζ₁₄/ζ₁₅ → αᵢⱼ/βᵢ
Includes: short LaTeX correctness note in doc/math/.
Effort: 10–14 days net. Trigger: profiling on V > 5000.
9c — Genus g > 1 fundamental domain (Java port + research extensions)
──────────────────────────────────────────────────────────────────────
9c 4g-polygon boundary walk (genus g > 1)
→ Extend compute_fundamental_domain() beyond genus 1
Java sources: FundamentalPolygonUtility.java (698 lines)
+ CanonicalFormUtility.java (532 lines)
+ CuttingUtility / SurgeryUtility (~800 lines)
Mathematical source: Poincaré 1882 + Sechelmann 2016 §5
Research component: bridging to conformallab++ cut_graph.hpp
+ holonomy infrastructure.
Effort: ~2 weeks for fundamental polygon, +2 weeks for surgery
layer, +1 week integration.
◼ Optional / Hypothetical — geometry-central Cross-Comparison
Status: no planned phase — purely exploratory.
These items are not prerequisites for Phase 8–10. They are of interest because geometry-central (Keenan Crane, CMU) is built on the same mathematical foundations as conformallab++ — in particular Springborn 2020 and its direct extension by Gillespie, Springborn & Crane (SIGGRAPH 2021).
The key difference: geometry-central solves the same problem (discrete conformal equivalence) using intrinsic triangulations + Ptolemaic flips, while conformallab++ applies Newton on the original triangulation.
GC-1 [optional, possible now]
Mathematical output comparison
→ load the same test meshes (cathead.obj, brezel.obj, torus_4x4.off) into
both libraries
→ compare UV coordinates, u-vector, residual norm
→ align normalisation conventions (u mean, scaling)
Goal: independent cross-validation of convergence points.
Effort: small Python/C++ comparison script, no library restructuring.
GC-2 [optional, useful after Phase 8]
Intrinsic Delaunay pre-conditioning
→ before the Newton solver: apply geometry-central SignpostIntrinsicTriangulation
to the input
→ Ptolemaic flips pre-condition the Hessian matrix
→ hypothesis: fewer Newton iterations on non-Delaunay inputs
→ implementable as an optional cmake flag: -DWITH_GC_PRECOND=ON
Dependency: geometry-central as an optional external dependency
(header-only parts suffice for the flip algorithm).
GC-3 [hypothetical, Phase 10+ research]
Ptolemaic flip-based solver as an alternative backend
→ instead of Newton: Ptolemaic flips + penultimate-step normalisation
(Gillespie–Springborn–Crane 2021 algorithm)
→ comparison: convergence radius, robustness on pathological meshes,
numerical stability on high-genus surfaces
→ relevant for conformallab++ because the Newton approach can become
unstable on strongly non-Delaunay meshes (e.g. after remeshing).
No implementation planned — conceptual note for Phase 10 research.
Connection to the literature:
The Springborn 2020 paper ("Ideal Hyperbolic Polyhedra and Discrete
Uniformization") is already implemented in conformallab++ as the HyperIdeal
geometry mode (Phase 2/3). The Gillespie–Springborn–Crane
2021 extension — implemented in geometry-central — augments this with
intrinsic triangulations and makes the algorithm robust against
poor input triangulations. Both share the same
mathematical core (discrete conformal equivalence, Gauss–Bonnet,
variational principle of Bobenko–Springborn 2004).
◼ Phase 10 — Genus g ≥ 2 (research with partial Java support)
Most Phase-10 items have partial Java references (utility classes for
forms and homology) but the assembly into a working uniformization
pipeline is research. Full catalogue with primary literature:
research-track.md.
Phase 10 Global uniformization for genus g ≥ 2
10a Discrete holomorphic and harmonic 1-forms
→ Integrate basis 1-forms ωᵢ along b-cycles of the cut graph.
Mathematical reference: Bobenko-Springborn 2004 §6 + Mercat 2001.
Java sources (partial, port-with-research):
CanonicalBasisUtility.java 337 lines (homology basis)
HomologyUtility.java 122 lines
DualityUtility.java 308 lines
DiscreteHarmonicFormUtility.java 657 lines
DiscreteHolomorphicFormUtility.java 285 lines
Effort: ~6 weeks net (4 utility ports + 1 integration).
10b Siegel period matrix Ω ∈ H_g (g×g complex symmetric, Im(Ω) > 0)
→ Ωᵢⱼ = ∫_{bⱼ} ωᵢ
→ Reduction to Siegel fundamental domain via Sp(2g,ℤ).
Mathematical reference: Bobenko-Springborn 2004 + Gottschling 1959.
Java partial reference: DiscreteRiemannUtility.java (186 lines).
Requires: 10a.
Effort: ~1 week net after 10a.
10b' Alternative methods (parallel research track)
→ HyperbolicCyclicFunctional (Java, 530 lines) — completes the
classical three-mode set with hyperbolic energy.
→ Quasi-isothermic parametrisation (Lawson correspondence):
QuasiisothermicUtility.java + SinConditionApplication.java
(~1 200 Java lines combined).
→ MobiusCenteringFunctional (Java, 289 lines) — sphere centering.
Each independent; can be tackled in any order.
10c Full uniformization for genus g ≥ 2
→ Embedding as H²/Γ with Γ ⊂ PSL(2,ℝ) a Fuchsian group.
Mathematical reference: Sechelmann 2016 §6 (discrete instance);
Bers 1960 (continuous theory).
Java reference: NONE — Java has the polygon + period matrix
pieces but does not assemble them into
a Fuchsian-group representation.
Status: **fully new research.**
Requires: 10a + 10b + Phase 9c.
10c' Optional Java-port additions (low priority)
→ KoebePolyhedron.java (321 lines) — Koebe-Andreev-Thurston
circle packings. Adds a fifth DCE method.
→ ElectrostaticSphereFunctional (127 lines) — sphere
distribution baseline.
→ CirclePatternLayout / CirclePatternUtility — face-circle
pattern layouts.
None of these are required for the genus-g uniformization
pipeline; they extend the breadth of methods.