Mathematics Projection Multiplicity Method Classical Extremal Problem

The method

A classical extremal problem asks for the largest or smallest number of objects, or relations between objects, under constraints. The Erdős unit-distance problem is the famous example: how many pairs of points in the plane can be exactly one unit apart? The answer is not known, but a 2025 proof by OpenAI and Joshua Sawin showed a lower bound that surprised many. The Recognition Science library's ClassicalExtremalProblem structure captures the abstract shape of such problems: a set of visible objects, a relation whose instances are counted, and two numerical readouts, visible size and event count.

The library's contribution is not the proof itself, but the method it exposes. The idea is to lift the problem to a richer carrier space, count many events there, and project them back to the visible surface. The structure LiftData records this: a carrier type, a projection map back to the visible objects, a carrier relation, and an energy function. A finite window in the carrier gives a projected visible set and certified events. The key definition, BeatsLinearBy, says the visible event count grows at least as fast as N^(1+δ) for some fixed positive δ, beating linear growth.

The library then proves a theorem: given a certificate with the right pieces, a polynomial gain in the visible event count follows. The certificate requires four ingredients: a richer carrier, finite windows in it, a proof that carrier events project to valid visible events, and a fixed polynomial gain. This is the abstract shape of the lift-return proof. The theorem is machine-checked in the framework's library of formal theorems.

The method's diagnostic value is the point. A problem should be checked for projection multiplicity when its visible relation can be expressed as the projection of a carrier relation and the event count is controlled by fiber multiplicity rather than by visible dimension alone. The structure ProjectionMultiplicityCandidate lists four tests: a hidden carrier exists, the visible relation is a projection, fibers can grow, and carrier geometry stays controlled. When all four hold, a full attack is worth starting.

This is a naming of a failure mode, not a proof of any specific extremal result. The library does not formalize the OpenAI/Sawin proof, does not solve the unit-distance problem, and does not claim the method always works. It says only that visible-dimensional counting can be beaten when a high-rank carrier has many distinct events projecting to the same low-dimensional invariant. The consequence for a reader is a checklist: before attacking a classical extremal problem, ask whether a hidden carrier might be inflating the count.

/-- A classical extremal problem consists of visible objects, a relation whose
instances are counted, and two numerical readouts: visible size and event count. -/
structure ClassicalExtremalProblem where
  Visible : Type u
  relation : Visible → Visible → Prop
  size : Finset Visible → ℝ
  eventCount : Finset (Visible × Visible) → ℝ

/-- The formal output of the method: the lifted carrier gives a visible
polynomial gain. -/
theorem certificate_gives_polynomial_gain
    (C : ProjectionMultiplicityCertificate.{u, v}) :
    ∃ δ : ℝ, 0 < δ ∧ BeatsLinearBy C.visibleSize C.eventCount δ :=
  ⟨C.delta, C.delta_pos, C.polynomial_gain⟩

/-- Diagnostic predicate for the rule we missed.  A problem should be checked
for projection multiplicity when its visible relation can be expressed as the
projection of a carrier relation and the event count is controlled by fiber
multiplicity rather than by visible dimension alone. -/
structure ProjectionMultiplicityCandidate where
  has_hidden_carrier : Prop
  visible_relation_is_projected : Prop
  fibers_can_grow : Prop
  carrier_geometry_stays_controlled : Prop

What this page does not claim

The library does not formalize the OpenAI/Sawin proof of the unit-distance lower bound. The method is not proved to succeed for any particular extremal problem, only that a certificate yields a polynomial gain. The four candidate tests are necessary conditions, not a guarantee that a projection-multiplicity attack will work.

Verify this page

Every tagged claim above names its theorem. To check one yourself rather than trust this page, elaborate the source module with Lean 4 and audit its axiom basis:

$ lake env lean IndisputableMonolith/Mathematics/ProjectionMultiplicityMethod.lean
expected axiom basis: [propext, Classical.choice, Quot.sound] (the Lean kernel's standard three; no RS-specific axioms)

A page whose claims cannot be reproduced this way does not ship. In production, every anchor links to the exact declaration in the public source release, and this block carries the build receipt for the page itself.

Derived articles

This page is generated by a question-recursion engine: the questions its answers raise become the next pages. The current agenda, with open targets marked red: