[{"data":1,"prerenderedAt":4},["ShallowReactive",2],{"kKvkagi6em":3},"# DescriptiveComplexity\n\n[![CI](https://github.com/PierreSenellart/descriptive-complexity/actions/workflows/ci.yml/badge.svg?branch=master)](https://github.com/PierreSenellart/descriptive-complexity/actions/workflows/ci.yml)\n[![Mathlib](https://img.shields.io/badge/Mathlib-v4.33.0--rc1-blue)](https://github.com/leanprover-community/mathlib4/releases/tag/v4.33.0-rc1)\n[![DOI](https://img.shields.io/badge/DOI-10.5281%2Fzenodo.21678423-007ec6)](https://doi.org/10.5281/zenodo.21678423)\n[![Archived in Software Heritage](https://archive.softwareheritage.org/badge/origin/https://github.com/PierreSenellart/descriptive-complexity/)](https://archive.softwareheritage.org/browse/origin/?origin_url=https://github.com/PierreSenellart/descriptive-complexity)\n\nA Lean 4 library for descriptive complexity on top of Mathlib's `ModelTheory`,\nin the style of Immerman (*Descriptive Complexity*, ch. 3). Every complexity\nclass is *defined* logically, so membership, hardness and completeness proofs\nneed no machine model: a definability witness for membership, a first-order\nreduction for hardness, and the framework closes them into a `Complete`\ntheorem. Along the way the library proves a number of results of complexity and\ndescriptive complexity themselves. All declarations live in the\n`DescriptiveComplexity` namespace.\n\nComplexity theory is essentially absent from Mathlib because formalizing a\nmodel of computation with resource bounds is hard. But most classical hardness\nreductions do not need the full power of PTIME: they are *first-order\nexpressible*. An FO reduction is computable in AC⁰ ⊆ LOGSPACE ⊆ PTIME, so\nexhibiting one is strictly stronger than exhibiting a Karp reduction, while\nrequiring only first-order logic, which Mathlib already has.\n\n## Three layers\n\n* **Model theory.** A decision problem is an isomorphism-invariant property of\n  finite structures over a chosen vocabulary. You can also bring your own\n  concrete instance types: a bundled `Encoding` cannot be constructed without\n  proving polynomial size bounds in both directions (no padding, no\n  compression), and computable `Decoding`s read well-formed structures back, so\n  completeness theorems restrict to the non-junk instances in one line.\n* **Complexity classes.** Classes are logically defined and closed under FO\n  reductions by construction: the polynomial hierarchy by second-order\n  quantifier alternation, PTIME by the Horn fragment, NL by the Krom fragment,\n  PSPACE by second-order transitive closure, RE by value invention, with the\n  fixed-point logics FO(LFP)/FO(IFP)/FO(PFP) alongside. Machine models are\n  *theorems* here, not definitions (see the table below). Completeness without\n  a class is available too: the downward closure `below Q₀` of a fixed problem\n  is itself a class, so “GI-complete” is expressible with no logic anywhere.\n* **Reductions.** Tagged `dim`-dimensional first-order interpretations between\n  languages give the reduction `≤ᶠᵒ`, with its order-invariant variant `≤ᶠᵒ[≤]`\n  for gadgets that genuinely need a linear order and a relativized variant\n  `≤ʳᶠᵒ[≤]` for problems whose target domain is definable; all are closed under\n  composition. The problem catalog is one problem per file – vocabulary,\n  reductions, completeness theorem – with tutorial-style worked examples.\n\nHighlights: a machine-free **Cook–Levin** theorem, **all of Karp's 21\nproblems**, the **Immerman–Vardi** theorem (`lfpDefinable_iff_mem_PTIME`), the\n**Abiteboul–Vianu** theorem\n(`ifpDefinableFree_eq_pfpDefinableFree_iff_ptime_eq_pspace`), and the *machine\nbridge*: a problem is in the library's NP (resp. PTIME) exactly when it\nordered-FO-reduces to acceptance by a nondeterministic (resp. deterministic)\npolynomial-time Turing machine (`mem_NP_iff_le_ntmAccept`,\n`mem_PTIME_iff_le_dtmAccept`).\n\nAnd the payoff no machine-first development has, **unconditional lower\nbounds**: Ehrenfeucht–Fraïssé games on finite structures, and the\ninexpressibility of EVEN even when the sentence is handed a linear order\n(`even_not_foDefinable`), whence **`FO ⊊ FO(TC)`** proved outright\n(`exists_tcDefinable_not_foDefinable`). The same problem shows, by the\n`k`-pebble game, that **order-free FO(IFP) does not capture PTIME**\n(`exists_mem_PTIME_not_ifpDefinableFree`), so the linear order in the capture\ntheorems is not a convenience. No complexity assumption enters any of this.\n\n## Complexity classes and complete problems\n\nEach problem listed is proved **complete** for its class: both a member, and\nhard for it under FO reductions.\n\n| Complexity class | Logical characterization | Machine model | Problems proved complete |\n| --- | --- | --- | --- |\n| **L** = LOGSPACE | FO(≤, DTC) | deterministic two-way `k`-head automaton, walking a linear order of the universe | REACHd · UNREACHd |\n| **NL** | SO-Krom(≤); equivalently FO(≤, TC) | two-way `k`-head automaton, walking a linear order of the universe | REACH · UNREACH · 2SAT |\n| **PTIME** = Σ₀ᵖ = Π₀ᵖ | SO-Horn(≤); equivalently FO(≤, LFP) or FO(≤, IFP) | deterministic polynomial-time Turing machine | HORN-SAT · CVP (circuit value) · acceptance by a deterministic polynomial-time Turing machine |\n| **NP** = Σ₁ᵖ | ∃SO | nondeterministic polynomial-time Turing machine | **SAT-family:** SAT · 3SAT · NAE-SAT · NAE-3SAT · 1-in-SAT\u003Cbr>**Coloring:** 3-Colorability · `k`-Colorability (`k ≥ 3`) · Chromatic Number · Clique Cover\u003Cbr>**Cliques & subgraphs:** Clique · Independent Set · Vertex Cover · Subgraph Isomorphism\u003Cbr>**Sets & hypergraphs:** Set Cover · Hitting Set · Set Packing · Exact Cover · Set Splitting · Dominating Set · 3-Dimensional Matching\u003Cbr>**Graphs:** Feedback Vertex Set · Feedback Arc Set · Steiner Tree (node- & edge-weighted) · Max Cut · Hamilton Circuit (directed & undirected)\u003Cbr>**Numbers (in binary):** Knapsack · Partition · 0-1 Integer Programming · Job Sequencing\u003Cbr>**Machines:** acceptance by a nondeterministic polynomial-time Turing machine |\n| **coNP** = Π₁ᵖ | ∀SO | nondeterministic polynomial-time Turing machine, accepting when *every* run does | TAUT · 3-DNF-TAUT · 3-UNSAT · acceptance by such a machine |\n| **DP** | a Σ₁ and a Π₁ sentence conjoined | – | SAT-UNSAT |\n| **Σₖᵖ** (`k ≥ 1`) | Σₖ¹: `k` alternating second-order quantifier blocks, existential first | alternating polynomial-time Turing machine with `k` blocks, existential first | `QBF k` (quantified Boolean formulas, `k` blocks) · acceptance by such a machine |\n| **Πₖᵖ** (`k ≥ 1`) | Πₖ¹: `k` alternating second-order quantifier blocks, universal first | the same machine, universal first | `QBF∀ k` (universal-first, `k` blocks) · acceptance by such a machine |\n| **PH** | SO | – | – |\n| **PSPACE** | SO(TC); equivalently FO(≤, PFP) | polynomial-space Turing machine, deterministic or not | SUCCINCT-REACH · QSAT · acceptance by a space-bounded Turing machine (deterministic & not) |\n| **RE** | ∃SO[new] (∃SO with value invention) | Turing machine with no step bound and no space bound | FINSAT (Trakhtenbrot's theorem) · CODEHALT · HALT · PCP (Post's correspondence problem) |\n| **the degree of a problem** – `below Q₀`, e.g. **GI** | none: a downward closure under FO reductions rather than a logic | – | for GI: Graph Isomorphism · Digraph Isomorphism · DAG Isomorphism |\n\nEach entry of the machine column is an equivalence *proved here* between the\nlogical definition and acceptance by that model. The classes are also matched\nagainst Mathlib's computability layer: RE *is* recursive enumerability, every\nRE-hard problem is undecidable, and RE ≠ co-RE.\n\nThe last row states completeness against a *problem* instead of a logic, which\nis what “GI-complete” means. It agrees with the logical definitions where both\napply: `NP = below SAT`, `PTIME = below HORN-SAT` and their siblings are\ntheorems, so SAT-hardness *is* NP-hardness.\n\n## Scope\n\nThese limitations are *intrinsic* to the machine-free approach; for what is\nmerely not built yet, see `ROADMAP.md`.\n\n* **Complexity of problems, not of algorithms.** No cost model, no `O(·)`, no\n  fine-grained complexity: what you prove is membership, hardness and\n  completeness for the coarse classes above.\n* **Instances are finite relational structures, not strings.** The machine\n  bridges characterize the classes from inside the framework, by acceptance\n  problems whose instances carry the machine; their agreement with the usual\n  presentations over string encodings is classical (Fagin; Immerman–Vardi) and\n  is not formalized here.\n* **The reduction must be expressible in logic.** A poly-time reduction that is\n  not FO-expressible cannot be used; gadgets often need a linear order, tags or\n  extra dimensions, and arithmetic inside formulas is limited (addition and\n  comparison are FO(≤); multiplication is not FO).\n* **Completeness and structure, not class separations.** Whether P = NP and the\n  like is open mathematics the framework does not decide. Separations between\n  *logics* are in scope, and proved (see above).\n\n## Related projects\n\n* **[Complexitylib](https://github.com/SamuelSchlesinger/complexitylib)** (Lean 4\n  and Mathlib) is machine-model-first: `P` and `NP` are defined by time-bounded\n  multi-tape Turing machines, and hardness is a polynomial-time many-one\n  reduction exhibited as a machine. It reaches results out of scope here, notably\n  the deterministic time hierarchy theorem and circuit lower bounds; its complete\n  problems are SAT and 3SAT. Its descriptive-complexity component was developed\n  independently of this library, on its own foundations rather than Mathlib's\n  `ModelTheory`.\n* **[Karp21](https://github.com/wimmers/poly-reductions)** (Isabelle/HOL)\n  formalizes polynomial-time reductions between Karp's problems, with running\n  times accounted for in NREST; the public repository covers about eight of the 21.\n* **The Cook–Levin theorem** is mechanized against concrete models of computation\n  by [Gäher and Kunze, ITP 2021](https://uds-psl.github.io/cook-levin/) in\n  Coq/Rocq (call-by-value λ-calculus) and [Balbach, AFP\n  2023](https://www.isa-afp.org/entries/Cook_Levin.html) in Isabelle/HOL\n  (two-tape oblivious Turing machines). Here (`SAT_NP_complete`) it is proved for\n  the logically defined `NP`, the identification with the machine class being a\n  separate theorem.\n* **[Cookbook reductions](https://doi.org/10.4230/LIPIcs.MFCS.2024.56)** (Grange,\n  Vehlken, Vortmeier and Zeume, MFCS 2024) also specify reductions in first-order\n  logic, but check them automatically in a teaching setting rather than in an\n  interactive theorem prover.\n\n## Use as a dependency\n\nLake builds a single Mathlib per workspace, so pick the release whose Mathlib\npin is the *same* as your project's, not merely a compatible one.\n\n| DescriptiveComplexity | Mathlib | Toolchain |\n| --- | --- | --- |\n| `v1.1.0` | `v4.33.0-rc1` | `leanprover/lean4:v4.33.0-rc1` |\n| `v1.0.0` | `v4.33.0-rc1` | `leanprover/lean4:v4.33.0-rc1` |\n| `master` | latest pin, moves | see `lean-toolchain` |\n\nVersion numbers are the library's own and follow [semantic\nversioning](https://semver.org/); the `lean-toolchain` file at each tag is\nauthoritative for the pin. A **patch** release keeps the Mathlib pin it was cut\nagainst, and **a new pin always takes at least a minor bump** – so depend on\n`~1.0.0`, which stays within a single pin, rather than on `^1.0.0`.\n\nIn a `lakefile.toml`:\n\n```toml\n[[require]]\nname = \"descriptive-complexity\"\ngit = \"https://github.com/PierreSenellart/descriptive-complexity\"\nrev = \"v1.1.0\"\n```\n\nor, in a `lakefile.lean`:\n\n```lean\nrequire \"descriptive-complexity\" from git\n  \"https://github.com/PierreSenellart/descriptive-complexity\" @ \"v1.1.0\"\n```\n\nPin a version tag or a commit hash rather than `master`, for reproducible\nbuilds. Then `import DescriptiveComplexity` brings in the whole library; import\nindividual modules (for instance `DescriptiveComplexity.Problems.Sat`) to keep\nbuild times down.\n\n## Documentation\n\n* **API reference**:\n  \u003Chttps://pierresenellart.github.io/descriptive-complexity/DescriptiveComplexity.html>\n  – the `DescriptiveComplexity` module page is a part-by-part map of the library,\n  and every declaration is documented on its own page. Rebuilt from `master` on\n  every push.\n* **Tutorials**: `DescriptiveComplexity/Examples/ConjunctiveQueries.lean` and\n  `DescriptiveComplexity/Examples/GraphCrawling.lean`, worked examples read top\n  to bottom, each walking through a new problem domain in the order a user meets\n  it (concrete problem → encoding → vocabulary and semantics → faithfulness →\n  membership → hardness → completeness).\n* **Planned work**: `ROADMAP.md` – classes beyond PSPACE, counting and\n  optimization problems, more inexpressibility results, finer reduction notions.\n\n## Building\n\nThe toolchain in `lean-toolchain` must match the pinned Mathlib version.\n\n```\nlake exe cache get   # fetch Mathlib build cache\nlake build\n```\n",1786349531402]