feat(fold): emit per-face isometries and declare the named-line frame #31

New issue

Closed

opened 2026-07-02 14:03:39 +00:00 by toph · 0 comments

toph commented

2026-07-02 14:03:39 +00:00

Owner

beloch:named_lines exports one [a,b,c] triple with no declared coordinate frame, so fold2svg re-derives each face's isometry from float vertex pairs with reflection detection (71b6d77, 6d1016c) — reconstructing, in JS floats, the orientation the exact core already holds in face.iso but never emits. The bug is non-emission, not precision: that hack keeps sprouting epsilons as long as the transform is guessed instead of read.

Emit each face's isometry (Isometry.t — linear part + translation) in a beloch: extension, and declare the coordinate frame that beloch:named_lines / beloch:named_points are expressed in. A proper isometry carries its orientation in its determinant sign, so fold2svg reads the reflection instead of detecting it. Float coefficients are sufficient here — vertex coincidence and layer order are already decided exactly in the kernel and encoded as integers (faces_vertices, faceOrders), so the emitted floats carry positions only, never a decision.

Then port fold2svg to consume the emitted isometry and delete the float reconstruction.

Out of scope: exact coordinates (rational strings / minimal polynomial + isolating interval). Rendering lands on float regardless, and nothing verifies exactness today. Revisit if a verification or round-trip consumer appears — and then decide FOLD extension vs. a Beloch-native sidecar.

`beloch:named_lines` exports one `[a,b,c]` triple with no declared coordinate frame, so `fold2svg` re-derives each face's isometry from float vertex pairs with reflection detection (71b6d77, 6d1016c) — reconstructing, in JS floats, the orientation the exact core already holds in `face.iso` but never emits. The bug is non-emission, not precision: that hack keeps sprouting epsilons as long as the transform is guessed instead of read. Emit each face's isometry (`Isometry.t` — linear part + translation) in a `beloch:` extension, and declare the coordinate frame that `beloch:named_lines` / `beloch:named_points` are expressed in. A proper isometry carries its orientation in its determinant sign, so `fold2svg` reads the reflection instead of detecting it. Float coefficients are sufficient here — vertex coincidence and layer order are already decided exactly in the kernel and encoded as integers (`faces_vertices`, `faceOrders`), so the emitted floats carry positions only, never a decision. Then port `fold2svg` to consume the emitted isometry and delete the float reconstruction. Out of scope: exact coordinates (rational strings / minimal polynomial + isolating interval). Rendering lands on float regardless, and nothing verifies exactness today. Revisit if a verification or round-trip consumer appears — and then decide FOLD extension vs. a Beloch-native sidecar.

toph referenced this issue

2026-07-03 07:58:52 +00:00

feat(fold): emit a folded-form frame per step for interpolation #42

toph referenced this issue

2026-07-03 10:49:59 +00:00

feat(vscode): extension foundation — scaffold, language registration, three stubbed seams #44

toph referenced this issue from a commit

2026-07-03 13:07:58 +00:00

feat(vscode): extension foundation — scaffold, language registration, three stubbed seams (#44)

toph changed title from ~~feat(fold): exact coordinates and per-face isometries in beloch:* fields~~ to feat(fold): emit per-face isometries and declare the named-line frame

2026-07-03 18:55:40 +00:00

toph referenced this issue from a commit

2026-07-03 20:08:25 +00:00

docs(spec): emit per-face isometries, declare named-line frame (#31)

toph referenced this issue from a commit

2026-07-03 20:08:25 +00:00

docs(plan): fold isometry emission + fold2svg port (#31)

toph referenced this issue

2026-07-03 20:08:52 +00:00

WIP: feat(vscode): live preview — per-step diagrams synced to cursor (#42) #53

toph referenced this issue from a commit

2026-07-03 20:09:36 +00:00