diff --git a/.gitignore b/.gitignore index d9287f3..96f92d5 100644 --- a/.gitignore +++ b/.gitignore @@ -108,3 +108,4 @@ Thumbs.db ehthumbs.db Desktop.ini +.obsidian/ diff --git a/Makefile b/Makefile index afb31e9..510be1c 100644 --- a/Makefile +++ b/Makefile @@ -1,3 +1,5 @@ +SHELL := /bin/bash + TEX_MAIN := tex/computer.tex BUILD_DIR := build OUT_PDF := computer.pdf @@ -6,6 +8,7 @@ SVG_SRCS := $(wildcard svg/*.svg) SVG_PDFS := $(SVG_SRCS:.svg=.pdf) .PHONY: all clean +.PHONY: progress all: $(OUT_PDF) @@ -35,3 +38,24 @@ clean: latexmk -C -output-directory=$(BUILD_DIR) $(TEX_MAIN) || true rm -rf $(BUILD_DIR) $(OUT_PDF) rm -f tex/computer.{aux,log,out,fls,fdb_latexmk,synctex.gz,pdf} + +progress: + @set -e; \ + file="ROADMAP.md"; \ + done=$$(grep -ao "✅" "$$file" | wc -l | tr -d " "); \ + doing=$$(grep -ao "⏳" "$$file" | wc -l | tr -d " "); \ + todo=$$(grep -ao "◽️" "$$file" | wc -l | tr -d " "); \ + total=$$((done + doing + todo)); \ + if [ $$total -eq 0 ]; then pct=0; else pct=$$(((100*done + total/2)/total)); fi; \ + width=20; filled=$$(((pct*width + 50)/100)); \ + bar_short="["; for ((i=1;i<=width;i++)); do if [ $$i -le $$filled ]; then bar_short="$$bar_short█"; else bar_short="$$bar_short░"; fi; done; bar_short="$$bar_short]"; \ + width2=49; filled2=$$(((pct*width2 + 50)/100)); \ + bar_long="["; for ((i=1;i<=width2;i++)); do if [ $$i -le $$filled2 ]; then bar_long="$$bar_long█"; else bar_long="$$bar_long░"; fi; done; bar_long="$$bar_long]"; \ + bottom="0 10 20 30 40 50 60 70 80 90 100"; \ + for f in ROADMAP.md README.md; do \ + [ -f "$$f" ] || continue; \ + PROGPCT="$${pct}% ($${done}/$${total})" perl -0777 -CS -Mutf8 -pi -e 'my $$r=$$ENV{PROGPCT}; s|.*?|$$r|sg' "$$f"; \ + PROGBAR_SHORT="$${bar_short}" perl -0777 -CS -Mutf8 -pi -e 'my $$r=$$ENV{PROGBAR_SHORT}; s|.*?|$$r|sg' "$$f"; \ + PROGBAR_LONG="$${bar_long}" BOTTOM="$${bottom}" perl -0777 -CS -Mutf8 -pi -e 'my ($$r,$$b)=@ENV{qw/PROGBAR_LONG BOTTOM/}; s|(\n```text\n)[^\n]*\n[^\n]*\n(```\n)|$$1$$r\n$$b\n$$2|sg' "$$f"; \ + done; \ + echo "Updated progress to $${pct}% ($${done}/$${total}) across ROADMAP.md and README.md" diff --git a/README.md b/README.md index f8b4a7d..8a2bc35 100644 --- a/README.md +++ b/README.md @@ -14,6 +14,20 @@

By James Ross

+## Status + +**Overall Progress:** 39% (178/460) +] + +[Roadmap & checklist →](ROADMAP.md) + + +```text +] +0 10 20 30 40 50 60 70 80 90 100 +``` + + ## What if computation had a shape? Not metaphorically. Not as a diagram on a whiteboard. But as a navigable geometry, where programs move through possibility space, bugs are wrong turns, optimizations are shorter paths, and every execution leaves a trail you can walk backward. diff --git a/ROADMAP.md b/ROADMAP.md new file mode 100644 index 0000000..ac5d6ff --- /dev/null +++ b/ROADMAP.md @@ -0,0 +1,323 @@ +## Overview + +This roadmap tracks the CΩMPUTER manuscript from rough draft through final release v1.0.0. + +**Overall Progress:** 39% (178/460) +] + +### Progress + + +```text +] +0 10 20 30 40 50 60 70 80 90 100 +``` + + + +## Pre-Flight Stage Definitions + +| **Stage** | **What It Actually Means** | +| --- | --- | +| Rough Draft | Words exist on page | +| Content Complete | All sections have their intended content, nothing major missing | +| Tech Review | Math, code, diagrams verified correct | +| Developmental Edit | Book-wide consistency: tone, voice, narrative flow, structure | +| Copy Edit | Line-level: grammar, punctuation, style guide | +| Images | All visuals finalized | +| Layout | Typeset, paginated PDF | +| Proof | Error-hunt on formatted output | +| RC | Public release candidate | +| Final | v1.0.0 | + +## Pre-Flight Status Matrix + +| **File** | **Rough Draft** | **Content Complete** | **Tech Review** | **Developmental Edit** | **Copy Edit** | **Images** | **Layout** | **Proof** | **RC** | **Final** | +| ----------------------------- | --------------- | -------------------- | --------------- | ---------------------- | ------------- | ---------- | ---------- | --------- | ------ | --------- | +| tex/computer.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| tex/fig-trinity.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| tex/macros.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| tex/titlepage.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ◽️ | ✅ | ◽️ | ◽️ | ◽️ | +| tex/00-toc.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ◽️ | +| tex/01-note-to-the-reader.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| tex/02-prologue.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| tex/03-part-1-intro.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| tex/04-ch-02.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/05-ch-03.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/06-ch-04.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/07-part-2-intro.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ | +| tex/08-ch-05.tex | ✅ | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/09-ch-06.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/10-ch-07.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/11-ch-08.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/12-part-3-intro.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/13-ch-09.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/14-ch-10.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/15-ch-11.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/16-ch-12.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/17-ch-13.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/18-ch-14.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/19-part-4-intro.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/20-ch-15.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/21-ch-16.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/22-ch-17.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/23-ch-18.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/24-ch-19.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/25-part-5-intro.tex | ✅ | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/26-ch-20.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/27-ch-21.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/28-ch-22.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/29-ch-23.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/30-ch-24.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/31-part-6-intro.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/32-ch-25.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/33-ch-26.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/34-ch-27.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/35-ch-28.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/36-ch-29.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/37-ch-30.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/38-epilogue.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/39-codex-micro.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/40-codex.tex | ✅ | ✅ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | ◽️ | +| tex/back-cover.tex | ✅ | ✅ | ✅ | ✅ | ✅ | ◽️ | ✅ | ✅ | ✅ | ✅ | + + +## Appendix + +## Milestone 1: Rough Draft Complete + +> **Definition**: Words exist on the page for every planned section. + +### Acceptance Criteria + +All front matter sections have content (title, legal, dedication, preface) + +All chapter files exist with prose (not just outlines) + +All part introductions written + +Back matter drafted (appendices, glossary, index placeholders, bibliography) + +No empty sections marked "TODO: write this" + +Document compiles without errors + +--- + +## Milestone 2: Content Complete + +> **Definition**: All sections contain their intended content in roughly correct form. Nothing major is missing. + +### Acceptance Criteria + +Each chapter covers all intended topics + +All planned examples are present + +All proofs/derivations included (even if rough) + +Cross-references point to real sections (even if page numbers TBD) + +No "[INSERT X HERE]" placeholders remain + +Chapter flow makes sense when read sequentially + +Scope is locked — no new sections after this point + +--- + +## Milestone 3: Tech Review Complete + +> **Definition**: All technical content has been verified for correctness. + +### Acceptance Criteria + +All mathematical notation is consistent throughout +All proofs verified step-by-step +All code samples tested and working +All diagrams accurately represent the concepts +Category theory notation follows standard conventions +DPO rewriting rules are formally correct +RMG definitions are internally consistent +No hand-wavy claims without justification +Bibliography entries verified (authors, years, titles) +External reviewer sign-off (if applicable) + +--- + +## Milestone 4: Developmental Edit Complete + +> **Definition**: Book-wide consistency achieved. Reads as a unified work. + +### Acceptance Criteria + +Consistent voice throughout (not chapter-by-chapter tone shifts) +Terminology used consistently (same term = same meaning everywhere) +Notation introduced before use in every case +Difficulty progression makes sense (no sudden jumps) +Redundancy eliminated (same concept not explained 3 different ways) +Transitions between chapters flow naturally +Part introductions properly frame their chapters +Foreshadowing and callbacks work correctly +Reader "mental model" builds progressively +Chapter lengths reasonably balanced + +--- + +## Milestone 5: Copy Edit Complete + +> **Definition**: Line-level polish. Grammar, punctuation, style guide adherence. + +### Acceptance Criteria + +Grammar checked (no dangling modifiers, subject-verb agreement) +Punctuation consistent (Oxford comma decision applied throughout) +Hyphenation consistent (e.g., "meta-graph" vs "metagraph" — pick one) +Capitalization rules applied (Title Case for headings?) +Number style consistent (spell out under 10? Always numerals?) +Em-dash vs en-dash vs hyphen used correctly +Quotation style consistent (smart quotes, singles vs doubles) +Abbreviations introduced on first use +No repeated words across line breaks +Spelling checked (including technical terms) +LaTeX typography correct (\ldots vs ..., proper spacing) + +--- + +## Milestone 6: Images Complete + +> **Definition**: All visual assets finalized and production-ready. + +### Acceptance Criteria + +All TikZ diagrams render correctly +All SVG files included and sized appropriately +Consistent visual style across all figures +Color scheme works in both color and grayscale +All figures have captions +All figures referenced in text +Figure numbering correct and sequential +Resolution sufficient for print (300 DPI minimum for raster) +Alt-text/descriptions for accessibility (if digital) +No orphaned images (referenced but missing) + +--- + +## Milestone 7: Layout Complete + +> **Definition**: Typeset, paginated, print-ready PDF structure. + +### Acceptance Criteria + +Page size finalized (letter? 6x9? A4?) +Margins set for binding type (perfect bound needs gutter) +Font choices finalized and embedded +Headers/footers consistent +Page numbers correct +Table of Contents page numbers accurate +Chapter starts on recto (right page) if desired +No widows (single line at top of page) +No orphans (single line at bottom of page) +Figures placed near their references +No excessive whitespace +Code blocks don't break awkwardly across pages +Equations properly spaced and aligned +Index generated (if applicable) + +--- + +## Milestone 8: Proof Complete + +> **Definition**: Error-hunt on the formatted output. RC1 internally reviewed. + +### Acceptance Criteria + +Full read-through on paginated PDF (not source files) +All typos caught in this format documented and fixed +Page breaks reviewed for awkwardness +Spot-check cross-references (do page numbers match?) +Spot-check index entries (do they point to right pages?) +Print test copy reviewed (if physical release planned) +Check on multiple devices/readers (if digital) +All flagged issues from proof resolved +Change log documented + +--- + +## Milestone 9: Release Candidate + +> **Definition**: Public RC. "We believe this is done. Prove us wrong." + +### Acceptance Criteria + +RC announced to beta readers / early access list +Feedback collection mechanism in place +RC version clearly marked (e.g., "RC1" on cover/title page) +Known issues documented (if any) +Minimum soak time defined (e.g., 2 weeks for feedback) +Feedback triaged: blocking vs nice-to-have vs won't-fix +All blocking issues resolved +RC2 issued if significant changes made +Final sign-off from author + +--- + +## Milestone 10: Final Release (v1.0.0) + +> **Definition**: Published. Done. 🎉 + +### Acceptance Criteria + +Version number set to 1.0.0 +"RC" designation removed from all pages +Final PDF generated +Distribution channels ready (website, Gumroad, etc.) +Announcement prepared +ISBN registered (if applicable) +Copyright registered (if applicable) +Archive copy stored (Git tag, backup) + +--- + +## Pre-Flight Checklist: Final Release + +> The moment before you push the button. Go through this list one final time. + +### Legal & Metadata +Copyright page has correct year +Author name spelled correctly (laugh, but check) +ISBN correct (if applicable) +Edition number correct ("First Edition") +License terms clearly stated + +### Content Integrity +Table of Contents matches actual content +All cross-references resolve +No "TODO" or "FIXME" in text +No placeholder text anywhere +Bibliography complete + +### Visual Check +Cover image correct and high-res +No broken images +All figures render +PDF opens without errors in multiple readers + +### Technical +File size reasonable +PDF/A compliant (if archival) +Fonts embedded +Hyperlinks work (if digital) +Bookmarks/outline present in PDF + +### Distribution +Filename follows convention (e.g., `COMPUTER-v1.0.0.pdf`) +Upload to distribution platform tested +Download and verify the uploaded file +Announcement drafted and reviewed +Social media posts queued (if applicable) + +### Emotional Readiness +You've accepted it will never be perfect +You've accepted someone will find a typo on page 3 +You're ready to move on to the next thing diff --git a/computer.pdf b/computer.pdf index 2fc3114..5153c76 100644 Binary files a/computer.pdf and b/computer.pdf differ diff --git a/tex/01-note-to-the-reader.tex b/tex/01-note-to-the-reader.tex index 0aba276..3bb940b 100644 --- a/tex/01-note-to-the-reader.tex +++ b/tex/01-note-to-the-reader.tex @@ -10,7 +10,16 @@ \chapter*{Part I --- The Universe as Rewrite} \textbf{Computation is what reality is made of, not what we do \emph{to} reality.} \end{quote} -Up to now, most of us have only seen the shadows of this truth—projected, flattened, and made safe by decades of comforting abstractions. This book asks you to turn toward the source, to see the forms behind the shadows. Everything that follows traces the geometry of that world. +Up to now, most of us have only interacted with computation through +\emph{abstractions}—interfaces designed to hide structure, flatten history, and +sanitize the underlying machinery. What we call “code” is often just the +silhouette of a far richer process. + +This book asks you to look directly at that process: to stop reasoning from +interfaces and start reasoning from \emph{structure}. Once you do, a different +picture emerges—a picture with geometry, causality, and motion. Everything that +follows is an attempt to map that deeper layer with precision. + \subsection*{Why This Matters: From Black Boxes to Glass Boxes} @@ -123,7 +132,7 @@ \subsection*{A Call to Action: Go Bend Some Universes} We have laid the foundation for a computational cosmology. You now hold the keys to a system that replaces probabilistic guesswork with deterministic geometry, and opaque processes with absolute provenance. This is not an evolution. It is an architectural revolution. \begin{quote} -\textbf{Those who finish this book will not see computation the same way again. Once you learn to perceive the geometry beneath the code, the old mindset of “just running the code” collapses into a kind of flatness. It is like stepping outside Plato’s cave: the familiar shadows of computation give way to a full, three-dimensional world of structures, laws, and histories that were always there, waiting to be seen.} +\textbf{Those who finish this book will not see computation the same way again. Once you learn to perceive the geometry beneath the code, the old mindset of “just running the code” collapses into a kind of flatness. It is like switching from a diagnostic log to a full-system trace: the flat, fragmented view of computation you once relied on is replaced by a living, three-dimensional landscape of structures, laws, and histories that were always there—just never visible at once. Once you learn to see in this geometry, the old mindset of “just running the code” collapses into something impossibly thin.} \end{quote} If you are a physicist, expect parts of this to feel like an API spec for the laws you already know. If you are a computer scientist, expect ``the machine'' to suddenly include galaxies. If you are an ML person, expect models to shrink back down to what they are: ways of steering flows through a much larger space. diff --git a/tex/02-prologue.tex b/tex/02-prologue.tex new file mode 100644 index 0000000..1bdef94 --- /dev/null +++ b/tex/02-prologue.tex @@ -0,0 +1,347 @@ +\chapter*{Prologue: Computation Is Transformation} +\addcontentsline{toc}{chapter}{Prologue: Computation Is Transformation} + +\label{chap:computation-is-transformation} + +I didn't start thinking in graphs because I read a seminal paper, or because I spent my nights studying category theory, or because I had some grand, lightning-strike revelation about the fundamental nature of computation. + +I started thinking in graphs because a game studio I worked at had a build system that \textbf{sucked}. + +I don't mean "mildly inconvenient" sucked. I mean, we had sixty developers and only three build machines, and every morning the entire studio tried to merge their work into the same shared engine codebase like a stampede of buffalo diving into a single narrow canyon. The congestion was physical; you could feel the heat rising in the room as the queue grew. + +If you managed to fix a bug at 11 a.m., good luck seeing it in QA's hands before dinner. The latency loop was measured in hours, not seconds. + +And the stakes were high. If you broke the build, you were \textit{that person}—the one who froze the pipeline, stalled the artists, ticked off the designers, and effectively derailed the entire schedule for the day. The "build debacle," as we affectionately called it, wasn't just an annoyance. It was structurally broken. + +There were too many people trying to integrate at once, and far too few machines to handle the load. There was no isolation between game teams; a breakage in the physics engine for the racing game would halt the RPG team's ability to test their dialogue system. Visibility was non-existent. Rebuild times were excruciatingly long because the system had no concept of incremental reasoning. + +Worst of all, there was no way to ask the most basic questions: +\begin{itemize} + \item What actually depends on what? + \item What \textit{needs} to rebuild versus what is already fresh? + \item Why is this compilation step even happening? +\end{itemize} + +So I started digging. Not because I wanted to—because I had to. Someone needed to unfuck the pipeline, and apparently, that someone was me. + +I didn't have a plan. I didn't have deep experience writing build systems. I wasn't even "the build guy"—I was just the engineer who couldn't stop asking annoying questions. And the first question I asked—the one that changed everything—was embarrassingly simple: + +\textbf{"What \textit{is} a build, really?"} + +It's not the shell scripts. It's not the bespoke tools. It's not Jenkins, or the cloud, or the physical racks of servers humming in the closet. + +What \textit{is} it? + +\section{The Day I Realized Everything Was a Graph} +\label{sec:day-i-realized} + +If you strip away the noise, the implementation details, and the specific syntax of makefiles, a build is essentially three things: +\begin{enumerate} + \item A collection of inputs (source files, assets, configurations). + \item A collection of outputs (executables, archives, binaries). + \item \textbf{A set of transformations that turn one into the other.} +\end{enumerate} + +That's it. It is a transformation engine. + +You can visualize every build process as a directed flow: +\[ +[\text{Assets}] \rightarrow [\text{Compiler}] \rightarrow [\text{Objects}] \rightarrow [\text{Linker}] \rightarrow [\text{Executable}] +\] + +Once I started seeing this, I couldn't stop seeing it. You can draw every dependency tree as a graph of ``this depends on that.'' You can draw every version-control history as a DAG of ``this commit comes after that.'' You can even visualize a merge conflict as a topological mismatch between two graph branches. + +\begin{figure}[h] + \centering + \begin{tikzpicture}[>=latex, node distance=5.0cm] + \tikzset{ + state/.style={circle, draw, minimum size=1.2cm, align=center}, + boom/.style={circle, draw, minimum size=1.8cm, fill=red!20, align=center} + } + + \node[state] (A) {A}; + \node[state] (B) [right of=A] {B}; + \node[boom] (C) [right of=B] {C\\(Boom)}; + + \draw[->, thick] (A) -- node[midway, above] {Code Runs} (B); + \draw[->, thick] (B) -- node[midway, above, yshift=6pt, align=center] {Unexpected\\Condition} (C); + + \end{tikzpicture} + + \caption{A crash bug visualized as a path through state space.} +\end{figure} + +Everything I looked at—builds, merges, crashes, asset pipelines, scripts, even the coordination of the humans involved—suddenly made more sense when drawn as nodes and edges. It wasn't a thunderclap epiphany. It was a slow, creeping realization: + +\textbf{Everything we build is structure transforming into other structure. And the best way to see structure is to draw it.} + +The more problems I solved using this mental model, the more natural it felt. Build steps became nodes. Dependencies became edges. Failures became dead ends. Parallelization became independent branches. Caching was revisiting previously reached nodes. + +Git branching? Graph. +Gameplay systems? Graphs of state transitions. +NPC behavior trees? Graphs. +Physics collision islands? Graphs. +Data flow? Graphs. +Event pipelines? Graphs. + +Everywhere I looked, the same pattern repeated. And the punchline was this: I didn't choose graphs. The problems chose graphs. + +\section{Graphs Reveal What the Code Is Actually Doing} +\label{sec:graphs-reveal} + +\begin{center} +{\LARGE\bfseries Computation is a transformation of state.}\\[6pt] +{\Large\bfseries And transformations have geometry.}\\[6pt] +{\large\bfseries Geometry is how computation makes sense.} +\end{center} + +We like to pretend code is a set of instructions, a recipe, or a linear list of steps to be followed. But that is a lie we tell ourselves to make the complexity manageable. We write in lines because we speak in lines. The machine does not think in lines; it thinks in topology—states, edges, neighborhoods. The mismatch between our linear storytelling and the machine's geometric reality is the root of the pain we feel when software scales. + +We pay for the linear lie in time—in endless debugging, archaeology, and re-computation. The convenience of writing in lines comes with a hidden tax: hours of chasing motion we never bothered to represent. + +\begin{figure}[h] +\centering +\begin{tikzpicture}[baseline] + \node[align=left, text width=3cm] (L) {line 1\\line 2\\line 3\\line 4}; + \node[circle, draw, fill=gray!10] (a) at (5,0.8) {}; + \node[circle, draw, fill=gray!10] (b) at (6.5,1.6) {}; + \node[circle, draw, fill=gray!10] (c) at (6.5,0) {}; + \node[circle, draw, fill=gray!10] (d) at (8,1.2) {}; + \node[circle, draw, fill=gray!10] (e) at (8,-0.4) {}; + \draw[->, thick] (a) -- (b); + \draw[->, thick] (a) -- (c); + \draw[->, thick] (b) -- (d); + \draw[->, thick] (c) -- (d); + \draw[->, thick] (c) -- (e); + \node at (4,0.6) {$\neq$}; + \node at (1.5,-0.6) {\small How we write}; + \node at (7.2,-1.0) {\small How it runs}; +\end{tikzpicture} +\caption{The mismatch between code-as-text and code-as-structure.} +\end{figure} + +What code \textit{actually} is, is a set of rules that transform one state into another: +\[ +\text{State} \xrightarrow{\text{rules}} \text{State}' +\] + +Which is—if we’re honest—a graph rewrite. + +Here’s the short list: +\begin{itemize} + \item Dependencies, data flow, operation ordering—\textbf{graphs}. + \item State transformations—\textbf{graph rewrites}. + \item History and conflicts—\textbf{graph merges}. + \item Parallelism and race conditions—\textbf{graph partitions colliding}. + \item Debugging and optimization—\textbf{navigating and shortening paths}. +\end{itemize} + +The worst graphs are the ones we don't know we're using: undocumented state machines that live only in one engineer's head; the implicit flow Sarah knows but never wrote down; the tribal-knowledge dependency graph that mutates when someone leaves; the mental models that rot while the code keeps moving. + +\textbf{Invisible graphs still drive the system—they just do it silently, until they snap.} +And when they snap, we pay the bill. + +I didn't know it yet, but I was staring at the core idea this book is built on: + +\textbf{Computation isn't made of instructions. Computation is made of transformations.} + +And transformations have shape. And shape is a graph. + +\section{From Build Systems to a Theory of Structured Computation} +\label{sec:theory-of-everything} + +I spent the next decade chasing the same pattern through every layer of the stack—distributed services, engine rewrites, asset pipelines, migrations. The domain kept changing. The geometry never did. And every problem became clearer once I could draw it. + +Once you start thinking in transformations, you stop seeing code as something you ``run'' and start seeing it as something that \textit{moves}. A program is a journey. An execution is a path. A bug is a wrong turn. A merge conflict is two incompatible routes trying to occupy the same space. Concurrency is overlapping travel. Caching is revisiting past locations. Optimization is finding a shorter path. AI reasoning is exploring alternative paths. Simulation is repeated transformation under rules. + +Modern software kept growing—multi-threaded, distributed, asynchronous, reactive, stateful, data-heavy, AI-driven—and the old metaphors collapsed under the load. We don’t need new metaphors. We need a new language. + +Not a language to replace mathematics or computer science, but one to sit beside them—and let us talk about computation as it actually feels today: structural, dynamic, historical, branching, concurrent, emergent, and made of transformations. + +That is what this book is. A language for thinking in transformations. A language for the real shape of software. A language I wish I'd had the day I stared at a broken build system and realized I was seeing the edges of something big. + +\section{How State Moves} +\label{sec:how-state-moves} + +One of the weirdest things about being a software engineer is how often you find yourself working on a system without knowing what the system \textit{is}. + +Not philosophically—literally. You're staring at logs, stack traces, telemetry, exceptions, wire traces, crash dumps, network graphs, build steps, shader compilations, behavior trees—all disconnected snapshots of state—and the entire job boils down to one forbidden question: + +\textbf{How did the system get here?} + +Nobody documents movement. They document pieces—functions, modules, features, APIs—frozen in time like crime scene photos. But what you actually need is the movie. + +And every movie starts the same way: \textbf{Something changes.} + +A value updates $\rightarrow$ a message arrives $\rightarrow$ an event fires $\rightarrow$ a collider triggers $\rightarrow$ an asset loads $\rightarrow$ a network packet arrives $\rightarrow$ an AI agent evaluates a condition $\rightarrow$ a file finishes compiling $\rightarrow$ a row mutates $\rightarrow$ a job queues $\rightarrow$ a coroutine yields $\rightarrow$ a thread wakes up. + +It's all movement. You're not debugging code—you’re debugging motion. + +One day, after chasing a janky asset-pipeline bug that only happened on the third build of the day under full moonlight, I caught myself sketching the system on the whiteboard. And it hit me: I wasn't drawing code. I was drawing state moving through transformations. + +It was just boxes and arrows. But it told a story: + +\textit{This asset caused that task $\rightarrow$ which triggered that compiler $\rightarrow$ which created that file $\rightarrow$ which fed into that linker $\rightarrow$ which produced that binary $\rightarrow$ which crashed on that device $\rightarrow$ because that metadata was malformed $\rightarrow$ because the dependency graph was wrong $\rightarrow$ because someone "optimized" a build script six months ago.} + +None of this was ``business logic.'' None of this was ``gameplay.'' This was just state flowing through a sequence of transformations. + +And the more I stared at it, the more obvious it felt: \textbf{Everything in software is just state moving through transformations.} + +The behavior wasn’t in the individual pieces. It was in the \textit{connections}. +Not in the functions, but in the flow. +Not in the modules, but in the motion. + +Every crash, every deadlock, every corrupted asset, every “why is this broken again” moment was just tracing a path until we found where the universe branched wrong. + +The only honest representation of software is a map of how state moves. +Not the class diagram. +Not the UML. +Not the architecture deck collecting dust. +Just: + +\[ +\text{state} \rightarrow \text{transform} \rightarrow \text{state} \rightarrow \text{transform} \rightarrow \text{state} +\] + +—which is, if you zoom out far enough, a graph rewrite. + +Suddenly: compilers, build systems, asset pipelines, physics engines, networking, distributed systems, UIs, AI planning, databases, version control, even the goddamn game loop—they all look the same: + +\textbf{A world of states, and the rules that transform them.} + +This is where \COMPUTER{} really begins. Once you understand movement, you understand computation. And once you can draw movement, you can control it. If you can see the path, you can change it. + +\section{Why Structure Emerges Everywhere} +\label{sec:why-structure-emerges} + +There’s a moment in every engineer’s life—whether they admit it or not—where they stare at three completely different systems and think: ``Why the hell do these all look the same?'' + +The domains differ. The problems differ. The technologies differ. And yet—\textit{they rhyme}. They want to be graphs. They want to be structure. They want to be transformations. + +That repetition isn’t an accident. It’s a signal. + +\subsection{The Physics Engine That Looked Suspiciously Like a Compiler} + +Back at that studio—long before I had the vocabulary for any of this—I noticed something odd. Our physics engine's collision pipeline looked… a lot like the compiler pipeline. + +\begin{figure}[h] + \centering + \begin{tikzpicture}[node distance=3cm, auto] + \node [draw, align=center] (A) {Physics:\\Broadphase}; + \node [draw, align=center, right of=A] (B) {Contact\\Generation}; + \node [draw, align=center, right of=B] (C) {Solver\\Integration}; + + \node [draw, align=center, below of=A, yshift=1cm] (D) {Compiler:\\Lexing/Parsing}; + \node [draw, align=center, right of=D] (E) {IR\\Optimization}; + \node [draw, align=center, right of=E] (F) {Codegen}; + + \draw[->, thick] (A) -- (B); + \draw[->, thick] (B) -- (C); + \draw[->, thick] (D) -- (E); + \draw[->, thick] (E) -- (F); + + \draw[<->, dashed, gray] (A) -- (D); + \draw[<->, dashed, gray] (B) -- (E); + \draw[<->, dashed, gray] (C) -- (F); + \end{tikzpicture} + \caption{The structural isomorphism between a physics engine and a compiler pipeline.} +\end{figure} + +Totally different domains. Totally different math. Totally different problems. Same shape: +input $\rightarrow$ transform $\rightarrow$ transform $\rightarrow$ output. +A pipeline. A DAG. A rewrite sequence. + +Later in the book, we’ll see why physics and computation rhyme so well—and why the resemblance might not be a coincidence. + +\subsection{The AI Behavior Tree That Looked Like a Build System} + +Debugging a behavior tree bug one day—NPC frozen because a leaf node failed silently—I caught myself thinking: ``Why does this feel exactly like tracing build dependencies?'' + +Pending branches. Cached results. Reactive triggers. Upstream failures. Subtree retries. +Different skin. Same skeleton. + +\subsection{Distributed Systems and Animation Systems} + +Years later, working on distributed backend services, the déjà vu hit again: queues, events, fan-out, rollback, replay, scheduling, dependency ordering. +It felt exactly like the animation system I'd worked on in games. + +Different domain. Same geometry. + +\subsection{After a While, You Start Asking Different Questions} + +First you ask: ``Why does everything look like a graph?'' +Then: ``Is this just how my brain works?'' +Then: ``No seriously—why is this everywhere?'' + +The answer is simple: + +\textbf{Systems that evolve under rules naturally collapse into graph structure.} + +If something has parts—and those parts can change—you get a graph. + +\begin{itemize} + \item Atoms bond $\rightarrow$ graph + \item Functions call each other $\rightarrow$ graph + \item Assets depend on assets $\rightarrow$ graph + \item Events trigger events $\rightarrow$ graph + \item AI nodes activate nodes $\rightarrow$ graph + \item Game states transition $\rightarrow$ graph + \item Machines coordinate $\rightarrow$ graph + \item Humans coordinate $\rightarrow$ graph +\end{itemize} + +Structure emerges because dependencies, causality, concurrency, history, and flow \textit{are} structure. +Rules operating on state create structure. +So it’s not that your brain is “stuck in graph mode.” +It’s that engineered systems are \textbf{forced} into graph shape by the nature of change itself. + +\section*{The Map vs. The Territory} + +Now here’s the grounding point—the thing keeping this book sane. +Just because engineered systems resemble graphs does not mean the universe literally is one. + +\COMPUTER{} doesn’t \textit{start} by redefining physics. +At this layer of abstraction, it's simply a language for reasoning about engineered systems—software, pipelines, architectures, flows. + +\textit{Whether that same language also describes the universe we live in} +is a question we’ll revisit in Part VI, once we've built enough machinery to ask it responsibly. + +That’s why this chapter exists. +To show you: + +\begin{center} +\textbf{You're not imagining it, and you're not alone. +The pattern is real—and we're going to formalize it.} +\end{center} + +We were trying to force a graph-shaped universe into a linear-shaped hole. + +If you can see the geometry of computation, you can redesign the machine itself. + +\medskip + +\noindent\textbf{Where We Go From Here} + +\begin{itemize} + \item \textbf{Part I} formalizes the substrate—Recursive Metagraphs. + \item \textbf{Part II} shows how computation moves through it. + \item \textbf{Part III} gives that movement geometry—distance, curvature, possibility. + \item \textbf{Part IV} builds machines that exploit this geometry: rewinders, explorers, provers. + \item \textbf{Part V} connects this all to engineering practice: correctness, concurrency, provenance. + \item \textbf{Part VI} asks the forbidden question: + + \begin{center} + \textit{If this language explains engineered systems so well… + what else might it explain?} + \end{center} +\end{itemize} + +This book is the answer to that question. + +\bigskip + +\noindent\textbf{Where this leads.} +The moment you see software as state moving through transformations, +you need a formal language for describing that motion. + +Part I gives us that language. diff --git a/tex/03-ch-01.tex b/tex/03-ch-01.tex deleted file mode 100644 index fe3d49b..0000000 --- a/tex/03-ch-01.tex +++ /dev/null @@ -1,241 +0,0 @@ -\chapter{Computation Is Transformation} -\label{chap:computation-is-transformation} - -I didn't start thinking in graphs because I read a seminal paper, or because I spent my nights studying category theory, or because I had some grand, lightning-strike revelation about the fundamental nature of computation. - -I started thinking in graphs because a game studio I worked at had a build system that \textbf{sucked}. - -I don't mean "mildly inconvenient" sucked. I mean, we had sixty developers and only three build machines, and every morning the entire studio tried to merge their work into the same shared engine codebase like a stampede of buffalo diving into a single narrow canyon. The congestion was physical; you could feel the heat rising in the room as the queue grew. - -If you managed to fix a bug at 11 a.m., good luck seeing it in QA's hands before dinner. The latency loop was measured in hours, not seconds. - -And the stakes were high. If you broke the build, you were \textit{that person}—the one who froze the pipeline, stalled the artists, ticked off the designers, and effectively derailed the entire schedule for the day. The "build debacle," as we affectionately called it, wasn't just an annoyance. It was structurally broken. - -There were too many people trying to integrate at once, and far too few machines to handle the load. There was no isolation between different game teams; a breakage in the physics engine for the racing game would halt the RPG team's ability to test their dialogue system. Visibility was non-existent. Rebuild times were excruciatingly long because the system had no concept of incremental reasoning. - -Worst of all, there was no way to ask the most basic questions: -\begin{itemize} - \item "What actually depends on what?" - \item "What \textit{needs} to rebuild versus what is already fresh?" - \item "Why is this compilation step even happening?" -\end{itemize} - -So I started digging. Not because I wanted to—because I had to. Someone needed to unfuck the pipeline, and apparently, that someone was me. - -I didn't have a plan. I didn't have deep experience writing build systems. I wasn't even "the build guy"—I was just the engineer who couldn't stop asking annoying questions. And the first question I asked—the one that changed everything—was embarrassingly simple: - -\textbf{"What \textit{is} a build, really?"} - -It's not the shell scripts. It's not the bespoke tools. It's not Jenkins, or the cloud, or the physical racks of servers humming in the closet. - -What \textit{is} it? - -\section{The Day I Realized Everything Was a Graph} -\label{sec:day-i-realized} - -If you strip away the noise, the implementation details, and the specific syntax of your makefiles, a build is essentially three things: -\begin{enumerate} - \item A collection of inputs (source files, assets, configurations). - \item A collection of outputs (executables, archives, binaries). - \item \textbf{And a set of transformations that turn one into the other.} -\end{enumerate} - -That's it. It is a transformation engine. - -You can visualize every build process as a directed flow: -\[ -[\text{Assets}] \rightarrow [\text{Compiler}] \rightarrow [\text{Objects}] \rightarrow [\text{Linker}] \rightarrow [\text{Executable}] -\] - -Once I started seeing this, I couldn't stop seeing it. You can draw every dependency tree as a graph of \textit{"this depends on that."} You can draw every version control history as a DAG (Directed Acyclic Graph) of \textit{"this commit comes after that commit."} You can even visualize a merge conflict as a topological mismatch between two graph branches. - -\begin{figure}[h] - \centering - \begin{tikzpicture}[node distance=2cm, auto] - % Nodes - \node (A) [draw, circle] {State A}; - \node (B) [draw, circle, right of=A, node distance=3cm] {State B}; - \node (C) [draw, circle, right of=B, node distance=3cm, fill=red!20] {State C (Boom)}; - - % Edges - \draw[->, thick] (A) -- node {Code Runs} (B); - \draw[->, thick] (B) -- node {Unexpected Condition} (C); - \end{tikzpicture} - \caption{A crash bug visualized as a path through state space.} - \label{fig:crash_path} -\end{figure} - -Everything I looked at—builds, merges, crashes, asset pipelines, scripts, even the coordination of the humans involved—suddenly made more sense when drawn as nodes and edges. It wasn't a sudden epiphany where the heavens opened. It was more like a slow, creeping realization: - -\textbf{Everything we build is structure transforming into other structure. And the best way to see structure is to draw it.} - -The more problems I solved using this mental model, the more natural it felt. Build steps became nodes. Dependencies became edges. Failures became dead ends in the graph. Parallelization became independent branches that could be traversed simultaneously. Caching was simply the reuse of previously visited nodes. - -Git branching? Literally a DAG. Gameplay systems? Graphs of state transitions. NPC AI behavior trees? Graphs. Physics collision islands? Graphs. Data flow? Graphs. Event pipelines? Graphs. - -Everywhere I looked, the same pattern repeated. And the punchline was this: I didn't choose graphs. The problems chose graphs. - -\section{Graphs Reveal What the Code Is Actually Doing} -\label{sec:graphs-reveal} - -We like to pretend code is a set of instructions, a recipe, or a linear list of steps to be followed. But that is a lie we tell ourselves to make the complexity manageable. - -What code \textit{actually} is, is a set of rules that transform one state into another. - -You can describe these transformations in many ways—imperative, functional, object-oriented, declarative, reactive—but the underlying operation is always the same: -\[ -\text{State} \xrightarrow{\text{rules}} \text{State}' -\] - -Which is... a graph rewrite. It is just one that nobody ever talks about explicitly. - -The reason graphs felt like the right hammer to me wasn't because I was looking for a hammer. It was because the thing I was trying to hit was already a nail. - -\begin{itemize} - \item Dependencies? \textbf{Graph.} - \item Flow of data? \textbf{Graph.} - \item Order of operations? \textbf{Graph.} - \item Transformations of state? \textbf{Graph rewrites.} - \item History of changes? \textbf{Git DAG.} - \item Conflicts? \textbf{Non-isomorphic merges.} - \item Parallel builds? \textbf{Graph partitioning.} - \item Race conditions? \textbf{Incompatible update paths.} - \item Debugging? \textbf{Tracing a path through state space.} - \item Optimizations? \textbf{Shortening that path.} -\end{itemize} - -I didn't know it yet, but I was staring at the core idea this book is built on: - -\textbf{Computation isn't made of instructions. Computation is made of transformations.} - -And transformations have shape. And shape is a graph. - -\section{From Build Systems to a Theory of Everything-But-Physics} -\label{sec:theory-of-everything} - -It took years for the pattern to fully sink in. I eventually left that studio. I moved on to work in backend systems, built distributed pipelines, and led massive migrations, refactors, engine overhauls, and toolchain designs. - -All the while, I kept seeing the same thing. Every problem became clearer—more obvious, more tractable—once I could draw it. - -And once you start thinking in transformations, you stop seeing code as something you "run" and start seeing it as something that \textit{moves}. A program is a journey. An execution is a path. A bug is a wrong turn. A merge conflict is two incompatible routes trying to occupy the same space. Concurrency is overlapping travel. Caching is simply revisiting past locations. Optimization is finding a shorter path. AI reasoning is the exploration of alternative paths. Simulation is repeated transformation under rules. - -The more modern software grew—becoming multi-threaded, distributed, asynchronous, reactive, stateful, data-heavy, and AI-driven—the more the old metaphors strained under the load. We don't need new metaphors. We need a new language. - -Not a language to replace mathematics or computer science, but to sit beside them—and let us talk about computation as it actually feels today: structural, dynamic, historical, branching, concurrent, emergent, and made of transformations. - -That is what this book is. A language for thinking in transformations. A language for the real shape of software. A language I wish I'd had the day I stared at a broken build system and realized I was seeing the edges of something big. - -\section{How State Moves} -\label{sec:how-state-moves} - -One of the weirdest things about being a software engineer is how often you find yourself working on a system without knowing what the system \textit{is}. - -Not in a philosophical sense. I mean literally: you are staring at logs, stack traces, telemetry, exceptions, wire traces, crash dumps, network graphs, build steps, shader compilations, AI behavior trees—all these disconnected snapshots of state—and the entire job is trying to figure out the one thing nobody ever actually says out loud: - -\textbf{How did the system get here?} - -Nobody writes documentation that explains movement. They document functions, modules, features, APIs, scripts, endpoints—individual pieces frozen in time like photos in a crime scene. But what you actually need, what you're really trying to reconstruct, is the movie. - -And the movie always starts the same way: \textbf{Something changes.} - -A value updates. A message arrives. An event fires. A collider triggers. An asset loads. A user taps a button. A network packet comes in. An AI agent evaluates a condition. A shader completes compiling. A JSON blob gets parsed. A database row gets mutated. A job gets queued. A coroutine yields. A thread wakes up. - -It's all movement. You're not just debugging code. You're debugging motion. You're tracing the path the system took, trying to see the shape of that path through a thousand tiny keyholes. - -This was the thing that finally broke my brain wide open. One day, after chasing some janky asset-pipeline bug that only happened in the third build of the day under full moonlight, I caught myself sketching the system out on the board, and it hit me: I wasn't drawing code. I was drawing state moving through transformations. - -I looked at the whiteboard. It was just boxes and arrows—but it told a story. It wasn't pretty. It wasn't formal. But it was a story of change: \textit{This asset caused that task $\rightarrow$ which triggered that conversion $\rightarrow$ which invoked that compiler $\rightarrow$ which created that file $\rightarrow$ which fed into that linker $\rightarrow$ which produced that binary $\rightarrow$ which crashed on that device $\rightarrow$ because that metadata was malformed $\rightarrow$ because that earlier job never reran $\rightarrow$ because the change detection step skipped it $\rightarrow$ because the dependency graph was wrong $\rightarrow$ because someone "optimized" a build script six months ago.} - -None of this was "business logic." None of this was "gameplay." None of this was "graphics" or "AI." This was just state flowing through a sequence of transformations. - -And the more I stared at it, the more obvious it felt: \textbf{Everything in software is just state moving around.} - -The system's behavior wasn't in any one piece of code. It was in the connections between them. It wasn't in the functions. It was in the flow. It wasn't in the modules. It was in the motion. - -Every bug we ever solved—every crash, every deadlock, every corrupted asset, every "why the hell is this build busted again" moment—was ultimately just tracing a path through the system until we found the turn where the universe branched wrong. - -That was the moment I realized: The only honest representation of software is a map of how state moves. Not the code. Not the diagrams in Confluence. Not the "architecture deck" collecting dust in a forgotten Google Drive folder. Not the class hierarchy, or the UML, or the Gantt chart. - -Just... $\text{state} \rightarrow \text{transform} \rightarrow \text{state} \rightarrow \text{transform} \rightarrow \text{state}$. Over and over again. - -Which is—if you zoom out far enough—a graph rewrite. I didn't know the name for it then. But I could feel the shape of it. And once you see that shape, you can't unsee it. - -Suddenly: compilers, build systems, asset pipelines, physics engines, networking, distributed systems, UIs, AI planning, databases, version control, even the goddamn game loop itself... all look like the same thing: \textbf{A world of states, and the rules that transform them.} - -This is the moment where \COMPUTER{} really begins. Once you understand movement, you understand computation. And once you can draw movement, you can control it. Because if you can see the path... you can change it. - -\section{Why Structure Emerges Everywhere} -\label{sec:why-structure-emerges} - -There's a moment in every engineer's life—even if they don't talk about it—where they're staring at three totally different systems and suddenly think: "Why the hell do these all look the same?" - -The domains are wildly different. The problems are unrelated. The technologies are incompatible. And yet... they rhyme. They want to be graphs. They want to be structure. They want to be transformations. - -It's eerie the first time you see it. It's comforting the second. By the tenth, you just shrug and go: "Huh. Wouldn't ya know it." - -But here's the thing: That repetition isn't an accident. It's a signal. - -\subsection{The Physics Engine That Looked Suspiciously Like a Compiler} -Back at that studio—long before I had the vocabulary for any of this—I noticed something odd. Our physics engine's collision pipeline looked... a lot like the compiler pipeline. I'm talking 1:1 structural rhyme. - -\begin{figure}[h] - \centering - \begin{tikzpicture}[node distance=3cm, auto] - \node [draw, align=center] (A) {Physics: \\ Broadphase}; - \node [draw, align=center, right of=A] (B) {Contact \\ Generation}; - \node [draw, align=center, right of=B] (C) {Solver \\ Integration}; - - \node [draw, align=center, below of=A, yshift=1cm] (D) {Compiler: \\ Lexing/Parsing}; - \node [draw, align=center, right of=D] (E) {IR \\ Optimization}; - \node [draw, align=center, right of=E] (F) {Codegen}; - - \draw[->, thick] (A) -- (B); - \draw[->, thick] (B) -- (C); - \draw[->, thick] (D) -- (E); - \draw[->, thick] (E) -- (F); - - \draw[<->, dashed, gray] (A) -- (D); - \draw[<->, dashed, gray] (B) -- (E); - \draw[<->, dashed, gray] (C) -- (F); - \end{tikzpicture} - \caption{The structural isomorphism between a physics engine and a compiler pipeline.} - \label{fig:physics_vs_compiler} -\end{figure} - -Totally different domains. Totally different math. Totally different problems. But the same shape: $\text{input} \rightarrow \text{transform} \rightarrow \text{transform} \rightarrow \text{output}$. A pipeline. A DAG. A rewrite sequence. - -\subsection{The AI Behavior Tree That Looked Like a Build System} -Then one day I was debugging a behavior tree bug. You know: NPC stands still because some leaf action fails silently. A classic "this tree is alive but has no soul" situation. And as I traced the logic, I thought: "Why does this feel like tracing build dependencies?" - -Nodes failing upstream. Subtrees retrying. Pending branches. Canceled branches. Cached results. Reactive triggers. Execution traces. State snapshots. A behavior tree and a build system? Come on. Except... they're both just graphs of conditions and effects. Just different skins. - -\subsection{Distributed Systems and Animation Systems} -Working on backend services years later, I had déjà vu: queues, events, fan-out, time slices, cascades, scheduling, dependency ordering, rollback, replay, eventual consistency. It felt exactly like the animation system I'd worked on in games. - -The pattern was identical: independent nodes connected by flows, updated according to rules dependent on previous state, with branches for special cases. Different domain. Same skeleton. - -\subsection{After a While, You Start Asking Different Questions} -At first you ask: "Why does everything look like a graph?" Then you ask: "Is this just how my brain works?" Then you ask: "No seriously—why is this everywhere?" - -And the answer you eventually land on—if you follow that thread long enough—is surprisingly simple: \textbf{Systems that evolve under rules naturally collapse into graph structure.} - -Or in plain English: If something has parts and those parts can change, you get a graph—whether you want one or not. -\begin{itemize} - \item Atoms bond $\rightarrow$ graph - \item Functions call each other $\rightarrow$ graph - \item Assets depend on assets $\rightarrow$ graph - \item Events fire events $\rightarrow$ graph - \item AI nodes activate nodes $\rightarrow$ graph - \item Game states transition $\rightarrow$ graph - \item Machines coordinate $\rightarrow$ graph - \item Humans coordinate $\rightarrow$ graph -\end{itemize} - -Structure emerges because dependencies, causality, concurrency, history, and flow \textit{are} structure. Rules operating on state create structure. So it's not that your brain is "stuck in graph mode." It's that the world of engineered systems actually is graph-shaped. Because graphs are the natural mathematical home of relationships. And everything interesting in software is a relationship. - -\section*{The Important Boundary Line} -Now here's the grounding point—the thing keeping this book sane: Just because many engineered systems resemble graphs does not mean the universe literally is one. But the resemblance is interesting enough that the analogy has real explanatory power. - -\COMPUTER{} doesn't try to redefine physics. It tries to give software engineers a way to reason about structure, movement, history, causality, branching, rules, and possibilities using the same language that pops up everywhere anyway. - -That's why this chapter exists. To show you: \textbf{You're not imagining it and you're not alone. The pattern is real—and we're going to formalize it.} \ No newline at end of file diff --git a/tex/03-part-1-intro.tex b/tex/03-part-1-intro.tex new file mode 100644 index 0000000..d29b930 --- /dev/null +++ b/tex/03-part-1-intro.tex @@ -0,0 +1,111 @@ +\part{Computation as Rewrite} +\label{part:rewrite} + +\chapter*{Introduction to Part I} +\addcontentsline{toc}{chapter}{Introduction to Part I} + +\begin{quote} +\emph{Part I builds the foundation. At this layer, we stay disciplined. +We are talking about engineered systems\emdash{}software, pipelines, state, structure, motion. +Nothing more exotic is assumed.} +\end{quote} + +\bigskip + +\section*{Why Rewrite?} +\label{sec:why-rewrite} + +The Prologue showed a recurring pattern in modern systems: +everything we build eventually collapses into structure and change. + +Part I formalizes that pattern. + +To work honestly at this layer, we need a lens that matches the world we actually engineer. +Not the comforting metaphors of the 1970s\emdash{}files, threads, stacks\emdash{}but the deeper +geometry underneath them: \textbf{state evolving under rules}. + +In this part of the book, we take a disciplined position: + +\begin{quote} +\textbf{Computation is best understood as rewrite: +the transformation of structured state under explicit rules.} +\end{quote} + +That’s it. +No cosmology. No metaphysics. No claims about “the universe.” +Those questions will come later, once we have earned the right to ask them. + +For now, we are building the formal substrate for everything that follows. + +\bigskip + +\section*{A Working Hypothesis} +\label{sec:working-hypothesis} + +The systems you work on today\emdash{}distributed backends, +data pipelines, build graphs, reactive UIs, real-time engines\emdash{}do not behave like lists of instructions. +They behave like \textbf{structured state undergoing transformation}. + +Rewrite is not a metaphor. +Rewrite is the geometry of the motion. + +This part of the book establishes three ideas: + +\begin{enumerate} + \item \textbf{Structure:} why engineered systems naturally collapse into graph form. + \item \textbf{Rewrite:} how state evolves under rules. + \item \textbf{Composition:} how these rewrites build, layer, and interact. +\end{enumerate} + +These ideas are the intellectual spine of the entire book. + +\bigskip + +\section*{What This Part Is Not} +\label{sec:not-yet} + +You may notice echoes\emdash{}between rewrite and physics, +rewrite and cognition, rewrite and dynamical systems. +That is intentional. + +But we are not making claims about the universe. + +Not yet. + +In Parts IV–VI, we will explore how far this geometry reaches. +For now, we stay grounded: the domain is engineered systems. + +Part I is about \textbf{what software already is}, +not what the universe might be. + +\bigskip + +\section*{The Road Ahead} +\label{sec:road-ahead} + +Part I sits at the base of a long ascent: + +\begin{itemize} + \item Chapters 2–4 build the substrate: Recursive Meta-Graphs, rewrite rules, + causality, compositional structure. + \item Part II explores movement: execution as path, history as geometry. + \item Part III introduces distance, curvature, and possibility. + \item Part IV builds machines atop that geometry. + \item Part V connects it all to correctness, concurrency, and provenance. + \item Part VI finally asks the forbidden question: + \begin{center} + \emph{If rewrite explains engineered systems so elegantly\emdash{} + what else might it describe?} + \end{center} +\end{itemize} + +But all of that begins here, with a single disciplined idea: + +\[ +\text{state} \xrightarrow{\text{rewrite}} \text{state}'. +\] + +This is computation’s most primitive motion. +Everything else is structure on top of it. + + \ No newline at end of file diff --git a/tex/08-ch-05.tex b/tex/08-ch-05.tex index cc6c5a3..467d671 100644 --- a/tex/08-ch-05.tex +++ b/tex/08-ch-05.tex @@ -364,6 +364,66 @@ \subsection*{2. Rulial Distance as a Directed Pseudometric} Intuitively, $d(s,t)$ is the minimal computational effort (measured in legal rewrites) required to transform one frozen computation into another. \end{definition} +\begin{figure}[h] +\centering +\begin{tikzpicture}[scale=1.0] + +% --- LEFT: UNIT COST METRIC ---------------------------------------- + +% Title +\node at (1.8, 3.2) {\textbf{Unit-Cost Distance}}; + +% Nodes +\node[circle, draw, fill=gray!10] (A) at (0,0) {$s$}; +\node[circle, draw, fill=gray!10] (B) at (2,1) {}; +\node[circle, draw, fill=gray!10] (C) at (4,0) {$t$}; + +% Edges (all cost = 1) +\draw[->, thick] (A) -- node[above] {$1$} (B); +\draw[->, thick] (B) -- node[above] {$1$} (C); + +% Distance label +\node at (2,-0.8) {$d(s,t) = 2$}; + + +% --- RIGHT: WEIGHTED COST METRIC ---------------------------------- + +% Title +\node at (8.2, 3.2) {\textbf{Weighted Distance via $\mathcal{L}$}}; + +% Nodes +\node[circle, draw, fill=gray!10] (A2) at (6,0) {$s$}; +\node[circle, draw, fill=gray!10] (B2) at (8,1) {}; +\node[circle, draw, fill=gray!10] (C2) at (10,0) {$t$}; + +% Edges with Lagrangian weights +\draw[->, thick] (A2) -- node[above] {$\mathcal{L}_1$} (B2); +\draw[->, thick] (B2) -- node[above] {$\mathcal{L}_2$} (C2); + +% Distance label +\node at (8,-0.8) {$d_{\mathcal{R}}(s,t) = \mathcal{L}_1 + \mathcal{L}_2$}; + +% --- Caption ------------------------------------------------------- + +\end{tikzpicture} +\caption{Two parallel notions of Rulial Distance. \textbf{Left:} Each rewrite has unit cost, so distance counts the number of steps. \textbf{Right:} Each rewrite has a Lagrangian cost, producing the weighted distance used for optimization in Chapter~18. Chapter~18 generalizes the metric of Chapter~5 by replacing unit weights with resource-aware costs.} +\end{figure} + +\begin{remark}[On Weighted Distances] +\label{remark-weighted-distance} +The Rulial Distance defined here uses a \emph{unit cost} for each legal rewrite step. In Part~IV we generalize this notion by introducing a Lagrangian $\mathcal{L}(r, s)$ that assigns a non-uniform cost to each rewrite when the system performs optimization under real resource constraints (time, memory, bandwidth, risk, energy, etc.). + +The weighted distance used there is: +\[ +d_{\mathcal{R}}(s,t) + = \inf_{\gamma : s \to t} + \sum_{(u,v) \in \gamma} \mathcal{L}(r_{uv}, u), +\] +which reduces to the unit-cost distance of this chapter when $\mathcal{L} \equiv 1$ for all rewrites. + +Thus the metric introduced here is the \emph{special case} of the general geometric machinery developed later. +\end{remark} + \begin{proposition}[Rulial Pseudometric] For all $s,t,u \in \mathcal{S}$, the Rulial Distance satisfies: \begin{enumerate} diff --git a/tex/23-ch-18.tex b/tex/23-ch-18.tex index 08983df..85e2e16 100644 --- a/tex/23-ch-18.tex +++ b/tex/23-ch-18.tex @@ -2,13 +2,12 @@ \chapter{Deterministic Optimization Across Worlds} \label{chapter-18-deterministic-optimization-across-worlds} \begin{quote} -\itshape -Navigating the Rulial Manifold to discover structurally superior universes. +\emph{Navigating the Rulial Manifold to discover structurally superior universes.} \end{quote} For decades, software optimization has been treated as a dark art. It exists as a collection of tribal knowledge, a bag of disconnected heuristics, and a series of aggressive compiler passes that hope for the best. Engineers tweak flags, unroll loops manually, and pray that the black box of the compiler understands their intent. It is a frantic search through a disorganized state space, governed by luck as much as logic. -However, once we accept the premise that computation is geometry, this chaotic approach becomes obsolete. Optimization transforms from an act of guesswork into an act of navigation. We are no longer merely "improving code" or shuffling instructions; we are selecting superior worldlines from the local rulial manifold. We are not applying arbitrary transformation passes; we are steering the flow of computation toward geodesics—the mathematically shortest paths between intent and result. +However, once we accept the premise that computation is geometry, this chaotic approach becomes obsolete. Optimization transforms from an act of guesswork into an act of navigation. We are no longer merely ``improving code'' or shuffling instructions; we are selecting superior worldlines from the local Rulial manifold. We are not applying arbitrary transformation passes; we are steering the flow of computation toward geodesics—the mathematically shortest paths between intent and result. In the \textbf{C$\Omega$MPUTER} paradigm, you are not guessing what the optimizer might do. You are choosing the shortest legal path through a structured, metric space of possibilities. This chapter details the transition from heuristic hope to deterministic, geometric traversal of nearby universes. @@ -22,9 +21,6 @@ \section{Optimization as Worldline Navigation} \begin{figure}[h] \centering \begin{tikzpicture} - % Grid lines for "geometry" feel (drawn first so it sits behind) - \draw[step=0.5cm, gray!30, very thin] (0,0) grid (9,5); - % Draw the manifold surface \draw[thick, fill=gray!10] plot [smooth cycle] coordinates {(0,0) (4,1) (8,0) (9,4) (5,5) (1,4)}; @@ -36,6 +32,9 @@ \section{Optimization as Worldline Navigation} % Draw a "Geodesic" optimized path \draw[blue, ultra thick, ->] (2,2) to[out=-20, in=200] (6,2); \node[blue, below] at (4,1.2) {Geodesic (Optimized)}; + + % Grid lines for "geometry" feel + \draw[step=0.5cm, gray!30, very thin] (0,0) grid (9,5); \end{tikzpicture} \caption{Optimization as Navigation: The naive execution (red) traverses a high-cost, jagged path. The optimized execution (blue) follows the geodesic—the smoothest path allowed by the manifold's curvature.} \end{figure} @@ -43,18 +42,29 @@ \section{Optimization as Worldline Navigation} \section{The Optimizer's Input: The Bundle at Each Tick} \label{the-optimizers-input-the-bundle-at-each-tick} -The fundamental unit of operation for the optimizer is the rewrite bundle. At every single tick of the clock, the current universe presents a bundle of all legal rewrites available to the scheduler. This is the raw material of the future. +The fundamental unit of operation for the optimizer is the rewrite bundle. At every single tick of the clock, the current universe presents a bundle of all legal rewrites available to the Scheduler. This is the raw material of the future. + +Each candidate rewrite is not just a syntactic tweak. It carries a small packet of geometric and resource data: + +\begin{itemize} + \item how it changes Rulial Distance (structural effort), + \item how it bends or flattens local curvature, + \item how it interferes or composes with other rules, + \item how it moves the system along concrete resource axes: time, memory, bandwidth, energy, risk. +\end{itemize} + +The optimizer functions as a geometric filter. It examines every potential rewrite in the bundle and evaluates them against rigorous criteria. It asks which rewrite most effectively shortens the global path to the objective \emph{under the current cost model}. It analyzes which rewrite reduces the local curvature, making the system more stable. It determines which rewrite best preserves critical invariants and which maximizes the width of future bundles, thereby preserving optionality. Crucially, it identifies which rewrites move the system closer to a known geodesic and which risk bending the worldline into pathological regions of high friction. -The optimizer functions as a geometric filter. It examines every potential rewrite in the bundle and evaluates them against rigorous criteria. It asks which rewrite effectively shortens the global path to the objective. It analyzes which rewrite reduces the local curvature, making the system more stable. It determines which rewrite best preserves critical invariants and which maximizes the width of future bundles, thereby preserving optionality. Crucially, it identifies which rewrites move the system closer to a known geodesic and which risk bending the worldline into pathological regions of high friction. +Formally, each rewrite $r$ at state $s$ is annotated with a resource vector and evaluated by a \emph{Lagrangian of Computation} (Section~\ref{lagrangian-of-computation}), which collapses ``CPU vs memory vs bandwidth vs risk'' into a single scalar cost. The optimizer never asks ``Is this rewrite good in general?'' It asks the only question that matters: \emph{Does this rewrite move us downhill in this universe, under these constraints, right now?} -This process replaces the "optimization passes" of traditional compilers. Instead of applying a fixed sequence of transformations, the system makes dynamic, context-aware choices based on the computable gradient of the state space. +This process replaces the ``optimization passes'' of traditional compilers. Instead of applying a fixed sequence of transformations, the system makes dynamic, context-aware choices based on the computable gradient of the state space. \section{Local Optimization: Following the Gradient of the Manifold} \label{local-optimization-following-the-gradient-of-the-manifold} -Every legal rewrite carries specific geometric data: a local cost (distance), a structural effect on the graph (curvature), and an interference pattern with other rules. By aggregating these factors, the optimizer can compute a local gradient. This vector points in the direction of steepest descent toward a simpler, lower-energy universe. +Every legal rewrite carries specific geometric data: a local resource vector, an induced scalar cost from the Lagrangian, a structural effect on the graph (curvature), and an interference pattern with other rules. By aggregating these factors, the optimizer can compute a local gradient in Rulial Space. This vector points in the direction of steepest descent toward a simpler, lower-energy universe, as measured by your chosen cost function. -This mechanism is the computational equivalent of gradient descent, hill-climbing, or Newton's method, but it operates on the topology of the RMG rather than on numerical landscapes. The system essentially "rolls downhill," following the natural contours of the rule set toward a state of minimal Rulial Distance. +This mechanism is the computational equivalent of gradient descent, hill-climbing, or Newton's method, but it operates on the topology of the RMG rather than on numerical landscapes. The system essentially ``rolls downhill,'' following the natural contours of the rule set toward a state of minimal cost. Where traditional optimization frameworks hand-wave about `hot paths' and `critical sections,' the RMG-based optimizer computes an explicit, discrete Rulial gradient and walks it. \begin{figure}[h] \centering @@ -72,7 +82,7 @@ \section{Local Optimization: Following the Gradient of the Manifold} % Gradient Arrows \draw[->, thick, blue] (0.5, 3.3) -- (1.0, 2.5); \draw[->, thick, blue] (1.0, 2.5) -- (1.5, 1.5); - \draw[->, thick, blue] (1.5, 1.5) -- (2.5, 1.0) node[below] {Local Minima (Optimized)}; + \draw[->, thick, blue] (1.5, 1.5) -- (2.5, 1.0) node[below] {Local Minimum (Optimized)}; % Annotations \node at (4.5, 3) {Gradient $\nabla_{R}$}; @@ -83,16 +93,18 @@ \section{Local Optimization: Following the Gradient of the Manifold} \section{Global Optimization: Finding Geodesics} \label{global-optimization-finding-geodesics} -While local optimization handles immediate efficiency, global optimization seeks the geodesic: the absolute shortest legal worldline between the start state and the target state. Traditional compilers attempt to approximate this using layers of brittle heuristics. In the \textbf{C$\Omega$MPUTER} framework, we find geodesics by combining structured search across counterfactual universes with rigorous curvature analysis. +While local optimization handles immediate efficiency, global optimization seeks the geodesic: the lowest-cost legal worldline between the start state and the target state, measured under the Lagrangian of Computation. Traditional compilers attempt to approximate this using layers of brittle heuristics. In the \textbf{C$\Omega$MPUTER} framework, we find geodesics by combining structured search across counterfactual universes with rigorous curvature analysis. + +By analyzing the interference patterns (Chapter 12) and Rulial metrics (Chapter 5), the system can look ahead. It creates a map of the future cone, identifying paths that may initially look expensive but eventually open up ``wormholes''—shortcuts through the state space that bypass vast amounts of computation. Some worldlines take a few costly steps to align themselves with a low-curvature corridor and then run almost frictionlessly. Others save a tiny amount now and spend massively later. -By analyzing the interference patterns (\cref{chapter-12-interference}) and Rulial metrics (\cref{chapter-5-rulial-space-rulial-distance}), the system can look ahead. It creates a map of the future cone, identifying paths that may initially look expensive but eventually open up "wormholes"—shortcuts through the state space that bypass vast amounts of computation. This allows for deterministic discovery of optimal simplifications, normal forms, and execution paths. The system effectively bends the computation to align with the most efficient geometry the laws of physics allow. +Global optimization is the art of paying a little to get into the right corridor. The search operates over bundles and counterfactual futures, but it is always constrained by legality and invariants. We are not inventing new mathematics in the dark; we are surfacing the shortest lawful path that already exists inside the rule system. \section{Counterfactual Optimization: The Synthesis} \label{counterfactual-optimization-cfee-optimizer-magic} -The true power of this architecture emerges when we combine the Counterfactual Execution Engine (CFEE) from \cref{chapter-16-counterfactual-execution-engines} with the optimizer. This combination yields Deterministic Multiverse Optimization. +The true power of this architecture emerges when we combine the Counterfactual Execution Engine (CFEE) from Chapter 16 with the optimizer. This combination yields Deterministic Multiverse Optimization. -In this cycle, the CFEE proposes alternative futures by spawning parallel universes. The optimizer then evaluates these futures using geometric metrics. Finally, the scheduler collapses reality onto the best performing branch. The system essentially "peeks" into nearby universes to see which timeline offers the flattest curvature and the most direct path to the target. It dismisses brittle or high-cost alternatives before they become reality. It is a form of look-ahead that feels prescient, but is grounded entirely in the deterministic geometry of the bundle. +In this cycle, the CFEE proposes alternative futures by spawning parallel universes. The optimizer then evaluates these futures using the Lagrangian-based geometric metrics. Finally, the Scheduler collapses reality onto the best performing branch. The system essentially ``peeks'' into nearby universes to see which timeline offers the flattest curvature and the most direct path to the target. It dismisses brittle or high-cost alternatives before they become reality. It is a form of look-ahead that feels prescient, but is grounded entirely in the deterministic geometry of the bundle. \begin{figure}[h] \centering @@ -121,7 +133,7 @@ \section{Counterfactual Optimization: The Synthesis} \draw[->, ultra thick] (Opt) -- (End) node[midway, above] {Select $U_1$}; \end{tikzpicture} -\caption{The Optimization Cycle: The CFEE spawns candidate universes ($U_1, U_2, U_3$). The Optimizer measures their geometric cost. The Scheduler collapses reality into the optimal path ($U_1$).} +\caption{The Optimization Cycle: The CFEE spawns candidate universes ($U_1, U_2, U_3$). The Optimizer measures their geometric cost under the Lagrangian. The Scheduler collapses reality into the optimal path ($U_1$).} \end{figure} \section{Optimization as Rulial Shaping} @@ -129,71 +141,183 @@ \section{Optimization as Rulial Shaping} Optimizing code in the RMG+DPO worldview is best understood as shaping the system's possibility geometry so that favorable futures become inevitable and pathological futures become topologically impossible. -This is distinct from the manual application of transformations or the micromanagement of instruction ordering. Instead, it involves designing robust invariants and choosing rules that reinforce smoothness. It requires strengthening K-interfaces to forbid illegal states and introducing canonical forms that reduce the search space. By reducing destructive interference and increasing constructive interference, we flatten curvature spikes and straighten the worldlines. We are, in effect, engineering smooth universes where the "path of least resistance" happens to be the correct one. +This is distinct from the manual application of transformations or the micromanagement of instruction ordering. Instead, it involves designing robust invariants and choosing rules that reinforce smoothness. It requires strengthening K-interfaces to forbid illegal states and introducing canonical forms that reduce the search space. By reducing destructive interference and increasing constructive interference, we flatten curvature spikes and straighten the worldlines. We are, in effect, engineering smooth universes where the ``path of least resistance'' happens to be the correct one. + +There are two levers here: + +\begin{itemize} + \item \textbf{Hard geometry} — the rule set and invariants, which define what is legal and how bundles branch. + \item \textbf{Soft geometry} — the Lagrangian of Computation, which says which legal directions are cheap vs expensive. +\end{itemize} + +Changing the rules reshapes the manifold itself. Changing the Lagrangian leaves the manifold intact but tilts the gradient field that flows across it. Together, they let you sculpt a universe where the optimizer does not fight the physics of your system—it rides it. \section{The Fundamental Metric: Rulial Distance} \label{rulial-distance-as-an-optimization-cost-function} -Up to this point, we have treated Rulial Distance as an abstract concept. For an optimizer to function, this metric must be concrete and calculable. We achieve this by defining a cost functional over the worldline—a quantity we term the \textbf{Lagrangian of Computation}. +\noindent\textbf{Note.} The Rulial Distance used in this chapter is the weighted generalization of the distance introduced in Chapter~5. There, each rewrite had unit cost; here, the Lagrangian $\mathcal{L}(r,s)$ assigns a resource-aware cost, and $d_{\mathcal{R}}$ is defined as the infimum of total Lagrangian action across all worldlines. + +The central innovation here is the replacement of heuristic guesswork with a concrete metric. The optimizer functions by minimizing the Rulial Distance between the current state and the target state—but now understood through the lens of a cost-weighted worldline. -\begin{definition}[Rulial Distance] -Given RMG states $G_{start}$ and $G_{target}$ and a rule set $\mathcal{R}$, the \textbf{Rulial Distance} is defined as the minimal action along a valid rewrite path: +As defined in Chapter 5, Rulial Distance $d(s,t)$ is the minimal number of legal rewrites required to transform one frozen computation into another. It is a directed pseudometric on the Rulial state space: it tells you \emph{how many} steps separate two worlds, not yet how much those steps ``hurt.'' + +Rulial Distance is computable, structural, geometric, and rule-sensitive. It honors invariants and provides the bare, structural notion of effort. This replaces the black-box intuition of traditional compiler optimizations with an explicit, quantifiable substrate. + +On top of this substrate, the Lagrangian of Computation assigns a cost to each step. The distance between two worlds, from the optimizer's point of view, is no longer just ``how many rewrites'' but ``what is the minimum Lagrangian cost over all legal rewrite paths between them.'' We move from hoping a heuristic works to: + +\begin{enumerate} + \item measuring structural distance in Rulial Space, and + \item minimizing a clear, resource-aware cost functional over that space. +\end{enumerate} + +This fundamentally alters the reliability and transparency of the optimization process. When something is ``faster'' or ``cheaper,'' we can say exactly in which metric, by how much, and along which geodesic. + +\section{The Lagrangian of Computation: What ``Cost'' Actually Means} +\label{lagrangian-of-computation} + +Rulial Distance tells you how many legal rewrites separate two states. Real machines care about more than just how many steps they take. + +A rewrite can be cheap in time but expensive in memory, or vice versa. Some steps are almost free until you cross a cache boundary or saturate a network link. Others introduce numerical risk, privacy risk, or external costs (like re-running a third-party service). If we pretend all steps cost the same, we get pretty geometry and terrible systems. + +To make optimization honest, we attach a local resource vector to every rewrite: \[ - d_\mathcal{R}(G_{start}, G_{target}) = \inf_{\gamma} \int_\gamma \mathcal{L}(\dot{\gamma}, \gamma) \, dt +\rho(r, s) = (\Delta T, \Delta M, \Delta B, \Delta E, \Delta R, \dots) \] -where $\gamma$ ranges over legal rewrite sequences from start to target, and $\mathcal{L}$ is the \textbf{Lagrangian of Computation}: +capturing the change in time, memory, bandwidth, energy, risk, and whatever else you care about when applying rewrite $r$ at state $s$. + +The optimizer does not juggle a dozen objectives independently. It pushes them through a single scalar cost functional, the \emph{Lagrangian of Computation}: \[ -\mathcal{L} = \alpha \cdot \text{Cost}_{\text{rewrite}} + \beta \cdot \Delta_{\text{memory}} + \delta \cdot \text{Interference}(B) +\mathcal{L}(r, s) \;=\; w_T \cdot \Delta T + \;+\; w_M \cdot \Delta M + \;+\; w_B \cdot \Delta B + \;+\; w_E \cdot \Delta E + \;+\; w_R \cdot \Delta R + \;+\; \dots \] -\end{definition} -Here, the coefficients allow the optimizer to tune its behavior: +The weights $w_\bullet$ are not universal constants. They encode your constraints: + \begin{itemize} - \item $\alpha$ penalizes pure computational steps (CPU cycles). - \item $\beta$ penalizes the growth of the graph (memory allocation). - \item $\delta$ penalizes high-conflict bundles, steering the system away from brittle, high-interference regions. + \item On a phone, energy and memory get heavy weights; latency gets a softer one. + \item In low-latency trading, wall-clock time dominates; memory is almost free. + \item In a regulated environment, ``risk'' (breaking an invariant, violating a policy) is effectively infinite. \end{itemize} -This formalizes optimization. It replaces the "black-box intuition" of traditional compilers with an explicit, quantifiable objective function. We move from hoping a heuristic works to measuring a Lagrangian and minimizing it. +A worldline +\[ +\gamma = (s_0 \to s_1 \to \dots \to s_k) +\] +then has total cost +\[ +C(\gamma) = \sum_{i=0}^{k-1} \mathcal{L}(r_i, s_i), +\] +where each $r_i$ is the rewrite used from $s_i$ to $s_{i+1}$. + +Geodesic search is now well-defined: among all legal worldlines from the start to the target, we choose the one minimizing $C(\gamma)$. Rulial Distance still measures the structural effort in terms of rewrites; the Lagrangian tells us which effort actually matters. + +Changing the weights does not change which states are reachable. It changes which directions look ``downhill.'' Tuning the Lagrangian literally bends the optimization geometry around your business constraints. When you say ``we care more about memory than CPU cycles,'' you are not making a vague product statement—you are redefining the metric tensor of your computational universe. + +\section{Low Curvature Equals Better Optimization} +\label{low-curvature-better-optimization} + +There is a direct correlation between the curvature of the manifold and the efficacy of optimization. In regions of low curvature, bundles align, worlds remain structurally similar, and collapse is stable. Optimization feels natural because the gradient is smooth; geodesics are easy to locate and CFEE branches quickly converge on similar low-cost futures. + +Conversely, high curvature introduces conflict. Bundles interfere destructively, worlds diverge rapidly, and collapse becomes unstable. In these regions, optimization feels impossible because the geometry itself fights against linearization; tiny local choices induce massive global differences. You can still search, but the gradient keeps lying to you. + +Crucially, curvature is not an abstract aesthetic property; it is measured with respect to your cost model. Weight memory more heavily, and directions that allocate memory become ``steeper.'' Weight latency more heavily, and long sequential chains become cliffs. The same rule system can present low curvature to one Lagrangian and brutal curvature to another. + +This provides a crucial structural insight for system designers: if you desire highly optimized systems, you must design low-curvature rule sets \emph{relative to the cost model you actually care about}. This vocabulary allows us to articulate architectural flaws that were previously invisible: ``This API is not slow because the compiler is dumb. It is slow because the rule geometry around it is high-curvature with respect to latency.'' \section{The Horizon of Optimizability} \label{horizon-of-optimizability} -We must address a critical limitation. Just because we have a geometry does not mean every region of that geometry is navigable. There exist regions in Rulial Space where the gradient vanishes or becomes chaotic. We call this boundary the \textbf{Horizon of Optimizability}. +Optimization is not infinite. For any fixed rule set and cost model, there is a point beyond which the geometry stops helping you. + +In some regions of Rulial Space, the bundles are structured: some edges are much cheaper than others; the gradient clearly points ``downhill.'' In other regions, every legal rewrite has roughly the same Lagrangian cost. The bundles are almost isotropic, interference is violent, and nearby worlds look like unstructured noise. In those zones, there is no cheap direction left. The only way forward is to pay full price. + +We call the boundary between these regimes the \emph{Horizon of Optimizability}. + +Informally: starting from a state $s$, you can optimize within the horizon—shortening worldlines, flattening curvature, finding wormholes. Beyond the horizon, any further savings would require changing the rule system or breaking invariants. You can move, but you cannot move \emph{more cheaply} without changing the laws of your universe. + +This shows up everywhere: -Inside the horizon, the manifold is smooth (low curvature), and gradient-based methods successfully find geodesics. Outside the horizon, the manifold breaks down into: \begin{itemize} - \item \textbf{Chaotic Curvature:} Regions where $\kappa \to \infty$, meaning infinitesimal changes in the worldline lead to divergent, unpredictable futures. Geodesics here are unstable. - \item \textbf{Cryptographic Plateaus:} Regions designed to have zero gradient. A cryptographic hash function, for example, creates a featureless plateau in state space; no local optimization can point toward the preimage. - \item \textbf{NP-Hard Basins:} Areas where local minima are dense and deep, trapping the optimizer in sub-optimal configurations that require "tunneling" to escape. + \item Cryptographic hashes are deliberately engineered to sit beyond the horizon. Each step scrambles structure so thoroughly that, under the cryptographic invariants, the cheapest way to ``compute the hash'' is to actually run the hash. Any geodesic that looks shorter is illegal. + \item High-quality PRNGs, perfect shuffles, and some chaotic simulations intentionally erase exploitable local curvature. The manifold is still there, but all nearby directions cost the same. There is no gradient to follow without changing semantics. \end{itemize} -The C$\Omega$MPUTER optimizer is aware of this horizon. It does not attempt to optimize cryptographic primitives or chaotic attractors; it recognizes the curvature signature of these regions and switches strategies (or aborts optimization) rather than wasting cycles on a gradient that does not exist. +From the optimizer’s point of view, a horizon is detectable. As it explores bundles and counterfactual futures, it can see when gradients flatten out, when candidate geodesics converge to the same total cost, and when CFEE branches fail to expose cheaper alternatives. At that point, it stops pretending: further local search is wasted unless you modify the rules themselves (the MR axis, Section~\ref{multi-model-optimization-mr-axis}) or relax your invariants. + +This is a feature, not a failure. Good system design places security-critical or irreducible components \emph{beyond} the horizon, and keeps everything else in smooth, low-curvature regions where the optimizer can actually do work. \section{Multi-Model Optimization: The MR Axis} \label{multi-model-optimization-mr-axis} -Finally, we must consider the broader context of the Multi-Rule (MR) axis. Optimization is not strictly limited to choosing the best future within a fixed set of rules. It also involves choosing the \emph{best set of rules} for the problem at hand. +Finally, we must consider the broader context of the Multi-Rule (MR) axis. Optimization is not strictly limited to choosing the best future within a fixed set of rules. It also involves choosing the best set of rules for the problem at hand. -By modifying K-interfaces, altering rewrite patterns, refining invariants, or adjusting recursion strategies, we can produce entirely new universes that inherently optimize better. This implies a system capable of reflective self-improvement—rewriting its own physics to better solve the problem it faces. +By modifying K-interfaces, altering rewrite patterns, refining invariants, or adjusting recursion strategies, we can produce entirely new universes that inherently optimize better. This is Multi-Model (MRMW) optimization: the simultaneous optimization of the worldline within a universe and the optimization of the universe itself. This represents the pinnacle of structured computation—a system that can rewrite its own laws to better solve the problem it faces. -This is a profound and complex operation, as it involves navigating the meta-space of all possible rule sets. The mathematics required to perform these "rulial updates" safely is the subject of \textbf{Differential Rulial Analysis}, which we will explore fully in \cref{chapter-twenty-one}. For now, understand that the ultimate optimization is not finding the best path through the universe, but designing a universe where the best path is trivial. +The Horizon of Optimizability makes MRMW optimization unavoidable. Once the optimizer detects that, under the current rules and Lagrangian, a region has gone beyond the horizon—no cheaper legal paths remain—it has three options: -\begin{tcolorbox}[title=\textbf{FOR THE NERDS™}] -\textbf{Theorem (Informal).} Given a rewrite bundle $B$ at state $G$ with a target state $G^*$, the optimal rewrite $r^* \in B$ satisfies: -\[ - r^* = \arg\min_{r \in B} \left[ d_\mathcal{R}(r(G), G^*) + \lambda \cdot \kappa(r) \right] -\] -where $\kappa(r)$ is the local curvature induced by applying $r$, and $\lambda$ is a regularization term preventing the selection of brittle, high-curvature paths even if they are technically shorter. This ensures the optimizer favors \emph{robust} geodesics over fragile shortcuts. -\end{tcolorbox} +\begin{enumerate} + \item accept the horizon and stop searching, + \item relax invariants (change what correctness means), + \item or jump to a new rule universe where the same intent lies in a lower-curvature region. +\end{enumerate} + +Traditional systems usually pick option (1) by accident. \textbf{C$\Omega$MPUTER} gives you all three on purpose. + +\noindent +Navigating this meta-space of rule changes requires tools beyond the local gradients and geodesics of this chapter. It requires understanding how the rule set itself deforms the manifold, how $\mathcal{L}$ and $d_{\mathcal{R}}$ transform under rule updates, and how curvature behaves when the universe rewrites its own laws. These mechanisms constitute the \emph{Differential Rulial Analysis} developed in Chapter~21. + +\section*{FOR THE NERDS™} + +\textbf{Deterministic Optimization $\approx$ Constrained Rulial Geodesic Search} + +Formally, we can describe this process as a uniform-cost search over local bundles, built on top of the formal geometry from Chapter 5: + +\begin{itemize} + \item the underlying space is the Rulial state space $(S, d)$ with directed pseudometric $d$ (Rulial Distance), + \item each legal rewrite edge $s \to t$ is labeled with a local resource vector $\rho(r,s)$, + \item a Lagrangian $\mathcal{L}(r,s)$ turns $\rho$ into a scalar edge cost, + \item the cost of a worldline $\gamma$ is $C(\gamma) = \sum \mathcal{L}(r_i,s_i)$, + \item the optimizer performs a constrained uniform-cost search for geodesics (minimal $C(\gamma)$) over bundles, + \item the search is guided by curvature estimates, bounded by interference patterns, and constrained by DPO typing. +\end{itemize} + +It serves as the computational analog to geodesic extraction and manifold traversal in differential geometry, or metric descent in optimization theory, but it is implemented entirely within a discrete, combinatorial framework. The Horizon of Optimizability corresponds to regions where edge costs become effectively isotropic and the geodesic search cannot beat exhaustive exploration without changing $d$, $\mathcal{L}$, or the rule set. + +(End sidebar.) \begin{center}\rule{0.5\linewidth}{0.5pt}\end{center} \section{Transition: From Optimization to Provenance} \label{transition-from-optimization-to-provenance} -We have constructed a suite of powerful machines: the CFEE to explore futures, MORIARTY to attack universes, and the Optimizer to refine worldlines. However, this generates a massive amount of data. What happens to the paths we explored but rejected? +We have now constructed a suite of powerful machines: the CFEE to explore futures, MORIARTY to attack universes, and the Optimizer to refine worldlines. Together, they let us search the Rulial Manifold, find geodesics under a concrete Lagrangian, and even hop across rule universes when we hit the Horizon of Optimizability. + +The final requirement is a mechanism to \emph{track and record} all of this. A naive system ``optimizes'' by overwriting history: you ship a faster binary, throw away the old worldline, and keep a few benchmark screenshots as ritual proof that it helped. In an RMG universe, that kind of amnesia is unacceptable. + +If the optimizer is allowed to rewrite worldlines—to perform worldline surgery to splice in geodesics—we need a way to preserve the original, inefficient paths as first-class citizens. We need to be able to ask: + +\begin{itemize} + \item What did the naive worldline look like before optimization? + \item Which alternative futures did CFEE and MORIARTY explore but reject? + \item What Lagrangian weights and curvature estimates drove each collapse decision? + \item Where did the optimizer declare ``horizon reached'' and stop searching? +\end{itemize} + +In \textbf{C$\Omega$MPUTER}, optimization never actually destroys history. When the optimizer finds a cheaper geodesic and ``rewrites'' the execution, it is only changing which path the Scheduler treats as canonical going forward. The original worldline, the candidate geodesics, the rejected branches, and the detected horizons are all preserved as part of the system's larger multiverse. + +We call the machine that records this \emph{Rulial Provenance} and the \emph{Eternal Audit Log}. Chapter 19 will build it explicitly. You can think of it, roughly, as: + +\begin{itemize} + \item a graph of all traversed and traversable worldlines, + \item annotated with Rulial Distances and Lagrangian costs, + \item enriched with curvature, interference, and MRMW layers, + \item and tagged with which paths were naive, adversarial, or optimized. +\end{itemize} -Crucially, the optimizer does not simply delete these inefficient paths. Every optimization decision—including the counterfactuals examined and discarded—is recorded. The system marks them as unchosen branches in the provenance graph. To make this practical, we need a machine capable of logging not just what happened, but everything that \emph{could} have happened, forever. +From that structure you can replay any worldline, compare naive vs optimized universes, audit every optimization decision, and even debug the optimizer itself. -We call this Rulial Provenance and the Eternal Audit Log. That is the subject of \cref{chapter-19-rulial-provenance-eternal-audit-logs}—the final machine of Part IV. +We have learned how to steer computation across worlds. Next, we learn how to remember \emph{all} those worlds—what happened, what could have happened, and why one universe won. That is the subject of Chapter 19—the final machine of Part IV. diff --git a/tex/27-ch-21.tex b/tex/27-ch-21.tex index 71f6a69..fbdbc15 100644 --- a/tex/27-ch-21.tex +++ b/tex/27-ch-21.tex @@ -1,13 +1,51 @@ \chapter{Twenty-One}\label{chapter-twenty-one} -\begin{quote} -{[}!NOTE{]} Diagrams Required -\end{quote} +\chapter{Differential Rulial Analysis} +\label{chapter-21-differential-rulial-analysis} \begin{quote} -{[}!NOTE{]} Formalisms Required +\emph{When the laws of computation can move, we need calculus.} \end{quote} +Up to now, our exploration of the Rulial Manifold has assumed a fixed universe. +The rules were stable; the invariants were immovable; the metric was carved +directly into the geometry of the rewrite system. This stability allowed us to +define distances (Chapter~5), gradients (Chapter~18), geodesics, curvature, +and even a Lagrangian of Computation that shaped how the system found +efficient worldlines. + +But optimization eventually reaches the limits of any fixed rule system. +Chapter~18 ended with a critical observation: once the optimizer encounters +the \emph{Horizon of Optimizability}, further improvement becomes impossible +without changing the universe itself. The rule set becomes the bottleneck. + +To move beyond that boundary, we must do more than navigate a manifold. +We must learn how to \emph{deform} one. + +Differential Rulial Analysis is the mathematics of this deformation. It asks: + +\begin{itemize} + \item How does the Rulial metric $d_{\mathcal{R}}$ change when a rule is added, removed, or rewritten? + \item How does the Lagrangian $\mathcal{L}$ transform when the resource model evolves? + \item How does curvature respond when invariants tighten or loosen? + \item How can one compare two universes that differ not in state, but in law? +\end{itemize} + +In physics, geometry bends when mass or energy move. +In computation, geometry bends when \emph{rules} move. + +This chapter develops the calculus that lets us reason about such motion. +It extends the static geometric tools of earlier chapters into a dynamic +framework capable of describing +rule drift, invariant deformation, metric evolution, and universe-to-universe continuity. + +Where Chapter~18 taught us how to follow geodesics \emph{within} a universe, +this chapter teaches us how to compute geodesics \emph{between} universes. + +It is the machinery required for Multi-Model Optimization, +system evolution, self-adaptation, meta-compilers, and any computational +architecture that rewrites its own laws. + \section{Differential Rulial Analysis}\label{differential-rulial-analysis} diff --git a/tex/computer.tex b/tex/computer.tex index 646b6ef..153ce19 100644 --- a/tex/computer.tex +++ b/tex/computer.tex @@ -250,7 +250,8 @@ \mainmatter \input{01-note-to-the-reader} -\input{03-ch-01} +\input{02-prologue} +\input{03-part-1-intro} \input{04-ch-02} \input{05-ch-03} \input{06-ch-04} diff --git a/tex/macros.tex b/tex/macros.tex index 0a52775..0f0eeb5 100644 --- a/tex/macros.tex +++ b/tex/macros.tex @@ -12,6 +12,9 @@ \providecommand{\AIONProjectURL}{\url{https://github.com/flyingrobots/aion}} \newcommand{\emd}{\textemdash\!} +% In preamble (main.tex) +\newcommand{\emdash}{\textemdash{}} + % Simple boxed callout shared by late chapters \newtcolorbox{nerdbox}{