c2e3ecb3e3
Some checks are pending
Lean Action CI / build (push) Waiting to run
Implements the cells-spec vision: a computation space that preserves auditability, correctness, interactivity. Phase 1 (Lean kernel + naga-IR Rust backend) is closed; foundation hypothesis stack (Selection H1+H2, Subobject H3, Trace H5, Obs.Ctx C2, Cubical.Trace) landed. Highlights: - Cubical-HoTT syntax + value/eval/readback in Lean - naga-IR pipeline (no GLSL string crosses FFI; 17/17 probes pass) - Honesty audit: every non-transport (sealed cells, vertex shader, Y-flip, presentation conventions) is documented as such - Polymorphic Trace α as free monoid; Cubical.Trace gives CTerm → Trace CTerm by structural fold (homomorphism = definition) - Selection as Huet zipper; Subobject as Boolean algebra over WCell - All theorems proven; the proof IS the implementation See STATUS.md for the resume guide. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
132 lines
6.3 KiB
Markdown
132 lines
6.3 KiB
Markdown
# Topolei — Hypothesis Log
|
||
|
||
Scientific tracking for the cells interface project.
|
||
Each hypothesis has: statement, prediction, falsification condition, test protocol, status.
|
||
|
||
---
|
||
|
||
## H1 — EML as Computational Cell Primitive
|
||
|
||
**Statement:** `eml(x,y) = exp(x) − ln(y)` with constant `1`, embedded as a single
|
||
primitive 1-cell, is sufficient to generate all elementary function cells via transport
|
||
composition. No other arithmetic primitives are needed in the computational layer.
|
||
|
||
**Prediction:** sin, cos, +, ×, √, π can each be type-checked as EML tree cells in
|
||
Lean 4 with verified derivation proofs.
|
||
|
||
**Falsification:** Any elementary function requiring a primitive outside the EML grammar
|
||
`S → 1 | eml(S,S)`.
|
||
|
||
**Test protocol:** Formalize each derivation in `Topolei/EML/Derive.lean`. A failed
|
||
`#check` or `sorry`-free proof attempt falsifies.
|
||
|
||
**Status:** Supported by Odrzywolek (2026) constructive proof. Not yet formalized in Lean.
|
||
|
||
---
|
||
|
||
## H2 — Uniform Tree Structure Enables Intuitive Interface
|
||
|
||
**Statement:** Because all EML expressions share the grammar `S → 1 | eml(S,S)`,
|
||
the interface can present math manipulation as composing identical nodes — subjectively
|
||
more intuitive than a multi-button calculator or ad-hoc function syntax.
|
||
|
||
**Prediction:** After N interactive sessions, user reports EML-tree manipulation feels
|
||
natural for expressing the math they care about (calculus, ODEs, geometry).
|
||
|
||
**Falsification:** User finds EML trees opaque or mechanical for expressions of
|
||
practical interest, even after familiarity. Specific failure case: depth > 4 trees
|
||
feel unmanageable without additional abstraction.
|
||
|
||
**Test protocol:** Subjective sessions recorded in this file under H2-Sessions.
|
||
Scale: 1 (not intuitive, not powerful) to 5 (intuitive and powerful).
|
||
|
||
**Status:** Untested.
|
||
|
||
### H2-Sessions
|
||
<!-- append entries here after each test session -->
|
||
<!-- format: DATE | expression attempted | depth | score | notes -->
|
||
|
||
---
|
||
|
||
## H3 — Text and Graph Rendering Are Co-Projections of EML Cells
|
||
|
||
**Statement:** Text layout and graph rendering are both sections of the same cell
|
||
fibration — `RenderCell` parameterized by a projection map — not architecturally
|
||
distinct subsystems. EML provides the shared computational substrate for both.
|
||
|
||
**Prediction:** A single `RenderCell` type with two projection instances (text, graph)
|
||
compiles and renders correctly without duplicated primitives.
|
||
|
||
**Falsification:** Text rendering requires primitives (glyph rasterization, string
|
||
indexing, Unicode) with no EML analog, forcing a separate non-cell subsystem.
|
||
|
||
**Test protocol:** Implement `RenderCell` in Phase 4. If the text projection requires
|
||
falling outside the EML/cell framework, H3 is falsified. Partial falsification
|
||
(glyph lookup is external but layout is EML) is recorded as a refinement.
|
||
|
||
**Status:** Partially supported by cells-spec §1.5 (rendering context as a cell).
|
||
EML connection is new and untested.
|
||
|
||
---
|
||
|
||
## H4 — FM^fr as the Mathematical Foundation for Mathematical Notation
|
||
|
||
**Statement:** Mathematical notation should be modeled as factorization homology
|
||
∫_M A over a framed syntactic space M with an E_n-algebra A encoding local
|
||
mathematical operations. Under this model:
|
||
|
||
- A mathematical expression is an element of ∫_M A, where M is a framed manifold
|
||
(1-manifold for linear text; 2-manifold for 2D layout — fractions, matrices, integrals)
|
||
- A **rendering** (typeset, graph, interactive widget) is a choice of framing on M,
|
||
not a separate compilation pipeline
|
||
- A **transport between framings** is a provably structure-preserving language
|
||
transformation — syntax ↔ geometry ↔ interactive manipulation
|
||
- **Custom functionality** = changing A while holding M fixed (same syntactic space,
|
||
different algebra — e.g. symbolic vs. numeric vs. proof-term interpretation)
|
||
- **Custom language transformations** = changing the framing of M (same expression,
|
||
different geometric embedding — e.g. inline text vs. displayed equation vs. 3D surface)
|
||
|
||
LaTeX, under this model, is not a compiler but a particular choice of framing with
|
||
a fixed algebra. "Parsing" is not a pipeline but section selection. The ⊗-excision
|
||
property of FM^fr guarantees that local composition rules are globally consistent —
|
||
which is exactly what LaTeX currently enforces by convention and fragile macros.
|
||
|
||
**Prediction:** The `RenderCell` type from H3 is correctly typed as a section of the
|
||
FM^fr fibration ∫_{M^fr} A, where:
|
||
- M^fr is the framed syntactic manifold of the expression
|
||
- A is an E_n-algebra in the cells/EML framework
|
||
- Different renderings are provably related by framing transports
|
||
|
||
**Falsification:** Mathematical notation requires operations that cannot be expressed
|
||
as local E_n-algebra data over any framing of a finite-dimensional manifold — i.e.,
|
||
some notational structure is genuinely global and not ⊗-excisive.
|
||
|
||
**Connection to existing framework:**
|
||
- Refines H3: FM^fr is the *reason* text and graph are co-sections, not just an
|
||
architectural claim
|
||
- Fits cells-spec §1.6: the Grothendieck fibration whose sections are programs is
|
||
precisely ∫_{(−)} A as M varies over framed manifolds
|
||
- Lives in the ∞-operad / (∞,1)-category world that the cubical embedding targets
|
||
- EML is the computational algebra A; the framed syntactic space M is what the
|
||
cells-spec calls the "rendering context" (§1.5)
|
||
|
||
**Test protocol:** Formalize a minimal FM^fr structure in Lean 4:
|
||
1. Define a framed 1-manifold type (for linear text)
|
||
2. Define an E_1-algebra over EMLExpr
|
||
3. Show that ∫_M A recovers the standard left-to-right evaluation of a formula
|
||
4. Show that a framing change (1-manifold → 2-manifold embedding) recovers a
|
||
2D layout (e.g., fraction bar as a geometric separator)
|
||
|
||
**Status:** Proposed. Not yet formalized. Depends on Phase 1 (EML evaluator) and
|
||
the cubical core (transport, composition) being in place first.
|
||
|
||
---
|
||
|
||
## Open Questions
|
||
|
||
- OQ1: Does the EML framework extend to complex-valued rendering (i.e. shaders that
|
||
need ℂ arithmetic natively, not just as derived operations)?
|
||
- OQ2: Can EML tree depth be bounded for all functions needed in practical math
|
||
visualization, or do some require unbounded depth (infinite series)?
|
||
- OQ3: Is there a ternary EML variant (hinted at in the paper) that removes the
|
||
need for the distinguished constant `1`, and does that simplify the cell primitive?
|