conformallab/ConformalLabpp
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

docs(reviewer): research alignments + 2 new Q1/Q2 + reordered agenda

Browse Source 
Adds the two research-track questions to the front of the queue, where
they belong for a reader whose publication line maps directly onto our
research-track roadmap entries.

briefing.md gains two new sections:

  * Research alignments — a 6-row table mapping the reader's research
    threads (decorated DCE, canonical tessellations, hyperideal
    rigidity, optimal cone placement, polygon Laplacian, Schläfli
    machinery) onto concrete phases of the roadmap, with the closest
    published line cited generically (year + venue only).

  * What's new on this snapshot — the 6 new porting phases + 9 new
    citations + Phase 9f (RESEARCH, no Java parent) + output_uv_map
    extension to Inversive-Distance.

questions.md restructures the question set from 5 to 7:

  * Q1 (NEW) — research-track alignment: which of 9d.2 / 9f / 10c /
    10c′ would unblock concrete experiments?
  * Q2 (NEW) — decorated-DCE API surface: A/B/C named parameter vs
    new solver vs property-map auto-detect?
  * Q3 — Phase 9b-analytic (was Q2)
  * Q4 — Phase 9c port-literal vs re-derive (was Q1)
  * Q5 — GC-1 cross-validation co-authorship (was Q5)
  * Q6 — CGAL submission packaging (was Q4)
  * Q7 — The "no" question (was the trailing section)

  Also drops Q3 from the previous list (CP-Euclidean output_uv_map),
  since that question is now answered (Phase 9c, runtime error today,
  on the deferred list — no reviewer input needed).

  Adds a final "After the meeting — would you collaborate?" block so
  the post-meeting collaboration options (acknowledgement / co-author /
  cadence / PRs) do not surprise the reader on the day.

agenda.md reorders §2 to match the new question order; the timing
shifts Q1/Q2/Q3 (research) to the front and Q4/Q6 (project
management) to the back.  Memo template at the bottom now has 7
named answer slots instead of 5 numbered ones.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
This commit is contained in:
Tarik Moussa
2026-05-26 00:21:50 +02:00
parent 1eff8c6bce
commit 07c653cb4c
3 changed files with 245 additions and 101 deletions
Download Patch File Download Diff File Expand all files Collapse all files

222
doc/reviewer/questions.md
View File

@@ -4,13 +4,111 @@
> "do A" / "do B" / "either is fine" is a sufficient answer; deeper
> dives are welcome but not required.
These are the five decisions that would benefit most from a second
opinion. Items 1-3 affect the porting roadmap directly; 4-5 affect
the long-term goal (CGAL submission).
These are the seven items that would benefit most from a second opinion.
* **Q1–Q2** are research-track questions — your active publication line
in **decorated DCE / Penner coordinates / canonical tessellations /
hyperideal polyhedra** makes you the best-positioned reader for them.
They ask whether conformallab++ could become *infrastructure for your
own future numerical experiments*, and what the minimum API surface
would be.
* **Q3–Q4** are porting decisions in our roadmap where your view of the
underlying mathematics would change the answer.
* **Q5–Q6** are project-management questions where peer input is
valuable but not blocking.
* **Q7** is an open invitation to push back on any architecture
decision you think we got wrong.
---
## Q1 — Phase 9c (4g-polygon canonical form): port-literal vs re-derive?
## Q1 — Research-track alignment: which RESEARCH phase would unblock concrete experiments you want to run?
Three phases in `doc/roadmap/research-track.md` are research-only
(no Java parent, no immediate user request), but each maps onto a
recognised live research line and each has explicit acceptance
criteria:
| Phase | What it would add | Closest published line |
|---|---|---|
| **9d.2** | Decorated DCE in non-Euclidean (spherical + hyperbolic) geometries; Penner coordinates as first-class DOF; automatic cone placement for non-Euclidean targets | Decorated DCE in non-Euclidean geometries (2025, *Discrete Comput. Geom.*); optimal cone singularities for Euclidean flattening (2018, *SIGGRAPH*) |
| **9f** | Discrete Laplace–Beltrami on **non-triangular** polygonal meshes (virtual-node / generalised cotangent), making DCE work on quad / Voronoi tessellations without re-triangulation | Polygon Laplacians (2011 *SIGGRAPH* + 2020 *TOG*) |
| **10c + 10c′** | Canonical Delaunay tessellations of decorated hyperbolic surfaces; Koebe polyhedron realisation (KAT) with rigidity-aware Newton | Canonical tessellations of decorated hyperbolic surfaces (2023, *Geom. Dedicata*); rigidity of circle / hyperideal polyhedra (2026, preprint) |
**Question A:** which of these (if any) would unblock concrete
numerical experiments you have wanted to run but currently have no
reference implementation for?
**Question B:** for the one(s) you would use, would you want us to
target the *next* milestone after Phase 9c, or is there a different
order that would serve your research better?
Context:
[`research-track.md`](../roadmap/research-track.md) §"Non-Euclidean
cone extensions" and §"Polygon Laplacian"; the integrated literature
sits in [`math/references.md`](../math/references.md).
---
## Q2 — Decorated-DCE API surface: what would you need from us to use the library for Penner-coordinate work?
If you wanted to compute the variational energy + Newton update for
**decorated discrete conformal equivalence** (vertex `u`-DOFs plus
per-edge Penner decoration `λ_e`), the existing five-solver scaffold
gives us three plausible API directions:
- **(A) Named parameter on the existing Euclidean entry.**
`discrete_conformal_map_euclidean(mesh, parameters::penner_decoration_map(λ))`.
Smallest change; preserves the single-entry-per-geometry pattern;
hides the decoration as "just another property map".
- **(B) Separate `decorated_*` solver headers.**
New entry `CGAL::decorated_discrete_conformal_map_{euclidean,
spherical, hyperbolic}` with its own `Default_decorated_*_traits`.
Cleaner separation of concerns; mirrors the way CP-Euclidean and
Inversive-Distance are their own headers.
- **(C) Per-edge decoration as just another property map** that the
existing solvers consume when present (zero-decoration = current
behaviour by construction). Minimal API expansion; risk of
surprising convergence behaviour when decoration is silently zero
vs explicitly zero.
**Question:** which of A / B / C matches what you would expect from
a CGAL-style header? If "none of the above" — what would you write
in our place?
Context: Phase 9d.2 in
[`research-track.md`](../roadmap/research-track.md); the existing
named-parameter helpers in
[`code/include/CGAL/Conformal_map/internal/parameters.h`](../../code/include/CGAL/Conformal_map/internal/parameters.h).
---
## Q3 — Phase 9b-analytic Hessian: implement now or later?
We have:
- **Done**: per-face block-FD Hessian (96× faster than naive full-FD).
- **Derived but not implemented**: analytic Hessian via the Schläfli
identity, expected ~6× further speedup over block-FD.
- **Derivation document**:
[`doc/math/hyperideal-hessian-derivation.md`](../math/hyperideal-hessian-derivation.md)
(805 lines, all sign pitfalls covered, references Schläfli 1858,
Milnor 1982, Vinberg 1993, Cho–Kim 1999, Glickenstein 2011,
Springborn 2020, Rivin–Springborn 1999).
**Question:**
- At what mesh size does the ~6× become user-visible enough to
justify ~2 weeks of implementation work, given the typical sizes
in your work?
- Are you aware of subtleties in the Schläfli-based derivation our
document might be missing?
If the answer is "implement", we'd target Phase 9b-analytic right
after the meeting.
---
## Q4 — Phase 9c (4g-polygon canonical form): port-literal vs re-derive?
The Java original has two utility classes:
@@ -38,48 +136,30 @@ Context: `doc/roadmap/phases.md` §Phase 9c, `doc/roadmap/porting-status.md`.
---
## Q2 — Phase 9b-analytic Hessian: implement now or later?
## Q5 — geometry-central cross-validation (GC-1): would you co-author?
We have:
Two libraries solve the DCE problem from opposite algorithmic
directions:
- **Done**: per-face block-FD Hessian (96× faster than naive full-FD).
- **Derived but not implemented**: analytic Hessian via the Schläfli
identity, expected ~6× further speedup over block-FD.
- **Derivation document**:
[`doc/math/hyperideal-hessian-derivation.md`](../math/hyperideal-hessian-derivation.md)
(805 lines, all sign pitfalls covered, references Schläfli 1858,
Milnor 1982, Vinberg 1993, Cho-Kim 1999, Glickenstein 2011,
Springborn 2020).
- **conformallab++**: Newton on the fixed mesh (no intrinsic flips).
- **geometry-central**: Ptolemy flips on an intrinsic triangulation.
**Question**:
An automated comparison on common meshes would be:
- At what mesh size does the ~6× become user-visible enough to
justify ~2 weeks of implementation work?
- Are you aware of subtleties in the Schläfli-based derivation our
document might be missing?
- A short paper (the disagreement modes are interesting in their own
right and connect to the decorated-DCE framework via canonical
tessellation invariants).
- A confidence-building tool for both libraries.
- ~3 days of plumbing (CMake-fetch geometry-central, write 5 common
test meshes, compare `u_per_vertex` to a tolerance).
If the answer is "implement", we'd target Phase 9b-analytic right
after the meeting.
**Question:** would you be interested in co-authoring such a comparison
note (with us doing the implementation)? Or do you know someone in a
neighbouring group who would be a natural co-author?
---
## Q3 — `output_uv_map` for CP-Euclidean: build now or defer?
For CP-Euclidean (face-based DOFs, BPS 2010) the natural output is a
**per-face circle packing** in ℝ² — not a per-vertex `Point_2` map
the way the other four DCE entries produce.
Today the entry throws `std::runtime_error` with a helpful pointer if
the caller passes `output_uv_map(...)`. A faithful layout would be
~150 lines implementing BPS-2010 §6.
**Question**: do *your* CP-Euclidean use cases need a UV-like output,
or are the face circle radii themselves the deliverable? The answer
shapes whether Phase 9c gets it now or later.
---
## Q4 — CGAL submission strategy: one package or five?
## Q6 — CGAL submission strategy: one package or several?
For the long-term CGAL submission:
@@ -94,34 +174,31 @@ Today the code is structured per-functional (Strategy C — see
[`locked-vs-flexible.md`](../architecture/locked-vs-flexible.md) §7).
Either submission packaging is achievable from this base.
**Question**: what's the CGAL editor convention for related-but-distinct
algorithms — Polygon_mesh_processing as one example (one package, many
algorithms), vs Triangulation_2/Triangulation_3/Periodic_*/Hyperbolic_*
as another (multiple packages for related algorithms)?
**Question:** what's the CGAL editor convention for related-but-distinct
algorithms — `Polygon_mesh_processing` as one example (one package, many
algorithms), vs `Triangulation_2`/`Triangulation_3`/`Periodic_*`/
`Hyperbolic_*` as another (multiple packages for related algorithms)?
---
## Q5 — geometry-central cross-validation (GC-1)
## Q7 — The "no" question (this is the highest-value answer)
Two libraries solve the DCE problem from opposite algorithmic
directions:
Looking at any of the 12 architecture decisions in
[`locked-vs-flexible.md`](../architecture/locked-vs-flexible.md), is
there one where you think *"no, that's the wrong call, here's why"*?
- **conformallab++**: Newton on the fixed mesh (no intrinsic flips).
- **geometry-central**: Ptolemy flips on an intrinsic triangulation.
This is a deliberately blunt question because positive feedback is
nice but negative feedback is rarer and more valuable. The 🔴
load-bearing decisions are the most consequential to revisit, because
waiting longer makes them more expensive:
An automated comparison on common meshes would be:
- **#1** `CGAL::Surface_mesh<P>` as default mesh
- **#3** header-only, no compiled library
- **#6** Eigen as linear-algebra back-end
- **#11** MIT license (only relevant if it conflicts with a CGAL-
submission constraint)
- A nice paper (the disagreement modes are interesting in their own
right).
- A confidence-building tool for both libraries (we benefit from
catching corner-case bugs, they benefit from cross-validation
against a Newton baseline).
- ~3 days of plumbing (CMake-fetch geometry-central, write 5 common
test meshes, compare `u_per_vertex` to a tolerance).
**Question**: would you be interested in co-authoring such a comparison
note (with us doing the implementation)? Or do you know someone in
the Crane group who would?
"No" is the most useful answer.
---
@@ -133,21 +210,24 @@ the Crane group who would?
[`code/deps/THIRD-PARTY-LICENSES.md`](../../code/deps/THIRD-PARTY-LICENSES.md)).
- Build system (CMake ≥ 3.20, header-only consumer + optional
CLI/Viewer).
- Documentation tooling (Doxygen with auto-generated `headers.md`).
These are conscious decisions matched to CGAL conventions and aren't
load-bearing in the sense that revisiting them later is cheap.
These are conscious decisions matched to CGAL conventions and are
not load-bearing in the sense that revisiting them later is cheap.
---
## What I'm hoping you'll say "no" to
## After the meeting — would you collaborate?
This is a deliberately blunt question because positive feedback is
nice but negative feedback is rarer and more valuable:
A separate "after the meeting" conversation, but flagged here so it
does not surprise you on the day:
**Looking at any of the 12 architecture decisions in
[`locked-vs-flexible.md`](../architecture/locked-vs-flexible.md), is
there one where you think "no, that's the wrong call, here's why"?**
The 🔴 load-bearing decisions are the most consequential to revisit,
because waiting longer makes them more expensive. No is the most
useful answer.
- **Acknowledgement** in any future CGAL submission / paper would be
the default, and we would ask first.
- **Co-authorship** on Q5 (the GC-1 cross-validation note) is on the
table if you said yes there.
- **Periodic update cadence** (quarterly? per-milestone?) — open
question, no expectation.
- **Pull requests** from your side are welcome and reviewable on the
Codeberg repo. We would not expect them — but we would not turn
them away either.