What a rule owes the interpretation, and the algebra that discharges it #
A hardness reduction into DescriptiveComplexity.DWideAcceptSpace emits a
machine, and an interpretation has to write that machine down: one formula per
relation symbol and tag tuple, read at the coordinates a transition's payload
occupies. So each rule owes, of its guard and of the two things it computes,
that a formula defines them – the same formula at every instance, since an
interpretation carries one.
The obligation is quantified over the structure #
The quantifier therefore sits outside the existential, and what it ranges over
is DescriptiveComplexity.Draw.Env: a finite nonempty linearly ordered structure
of the source vocabulary together with the two designated elements the reduction
may name – the order's least and greatest. Bundling them into one record is what
keeps the algebra readable: every statement below has a single extra binder e,
and instance resolution finds the order, the finiteness and the structure inside
it.
Guards are formulas; writes are sources #
A guard may ask anything first-order of its data, and it has to: the program
evaluates a logic, so a guard eventually compares two control slots in the
order, or asks a relation of the source vocabulary of them – neither of
which is a function of the equality pattern of the data. So
DescriptiveComplexity.Draw.UGDefinable carries a formula over the payload
coordinates, with DescriptiveComplexity.patSetF still available as one way of
building it.
A write, by contrast, never asks anything: every value the program stores is a
copy of one of its slots, one of the two designated elements, or the next
element after a slot (which is what advancing a loop variable needs). So
DescriptiveComplexity.Draw.USlotDefinable is a formula for the graph of the
value, and DescriptiveComplexity.SlotVal builds all three cases.
The three obligations #
A rule is written with its pointer and its tracks apart, so the obligations are
carried in that shape: UGDefinable for the guard, UStDefinable for the
pointer it leaves, UTrDefinable for the tracks it writes – with
DescriptiveComplexity.Draw.URuleDefinable bundling the three together with the
staticness of its two phases and its direction. That is what travels through the
program's tower, one statement per rule, composed site by site, with a kit's
abstract parameters (Match, setFlag …) contributing hypotheses of the same
shape.
Which coordinate a slot occupies #
A relation of the source vocabulary, in the ordered expansion: named,
because a raw Sum.inl is not recognized at the transparency rw matches
at.
Equations
Instances For
Dependency graph
The coordinate of a slot in a rule's payload.
Equations
- DescriptiveComplexity.Draw.slotIx d = (Fintype.equivFin (Q ⊕ W)) d
Instances For
Dependency graph
The two halves of a rule's data, put back together, is the data.
Dependency graph
The structures a reduction's rules are read at #
An environment: a finite nonempty linearly ordered structure of the source vocabulary, with the two elements a reduction may designate – the order's least and greatest, the only ones an interpretation can name. The program's rules are functions of one of these, and their definability is a statement about all of them, which is what an interpretation needs.
- α : Type
The universe.
- ord : LinearOrder self.α
Its order.
Which is finite.
And nonempty.
And carries the source structure.
- zero : self.α
The element a clear track holds.
- one : self.α
The element a set track holds.
The clear element is the order's least.
The set element is its greatest.
The two differ.
Instances For
Dependency graph
In a linear order, being a minimum is being the designated minimum.
Dependency graph
And dually.
Dependency graph
The three obligations, uniformly #
A guard is definable: one formula over the payload coordinates decides it at every environment.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
A written value is definable: one formula over the payload coordinates and one more variable defines its graph.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
A pointer a rule leaves is definable: one value per control slot.
Equations
- DescriptiveComplexity.Draw.UStDefinable F = ∀ (q : Q), DescriptiveComplexity.Draw.USlotDefinable fun (e : DescriptiveComplexity.Draw.Env L) (f : Q → e.α) (g : W → e.α) => F e f g q
Instances For
Dependency graph
And so are the tracks it writes: one value per track slot.
Equations
- DescriptiveComplexity.Draw.UTrDefinable F = ∀ (s : W), DescriptiveComplexity.Draw.USlotDefinable fun (e : DescriptiveComplexity.Draw.Env L) (f : Q → e.α) (g : W → e.α) => F e f g s
Instances For
Dependency graph
A rule is definable: its two phases and its direction do not depend on the instance at all – they are decided when the formula is built – its guard is defined by a formula, and the pointer it leaves and the tracks it writes are named slot by slot. This is what travels through the program's tower.
The phase it fires from is the same at every instance.
And so is the phase it moves to.
And so is its direction.
- guard : UGDefinable fun (e : Env L) => (rl e).guard
The guard is defined by a formula.
- dst : UStDefinable fun (e : Env L) => (rl e).dstSt
The pointer it leaves is definable slot by slot.
- wr : UTrDefinable fun (e : Env L) => (rl e).wr
And so are the tracks it writes.
Instances For
Dependency graph
A whole site's rules are definable.
Equations
- DescriptiveComplexity.Draw.URulesDefinable rules = ∀ (i : S) (ρ : Sh i), DescriptiveComplexity.Draw.URuleDefinable fun (e : DescriptiveComplexity.Draw.Env L) => rules e i ρ
Instances For
Dependency graph
The atoms of a guard #
A slot holds one of the two designated elements; two slots hold the same element; one slot is at most another; and a relation of the source vocabulary holds of a tuple of slots. The last two are what an equality pattern cannot say, and what a program that evaluates a logic needs.
Dependency graph
Dependency graph
Dependency graph
One slot is at most another.
Dependency graph
A relation of the source vocabulary, of a tuple of slots: the one thing a guard asks of the instance itself, and the reason a guard is a formula rather than a reading of the equality pattern.
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
A condition of the kit, not of the data: decided when the formula is
built, so any Prop will do – the two ends among them.
Dependency graph
Dependency graph
Dependency graph
And their connectives #
A guard stated one way is a guard stated any equivalent way.
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
A conjunction over any finite index type – the shape a one-hot clause or a
Match over a block of slots has.
Dependency graph
And a disjunction over any finite index type.
Dependency graph
A condition decided when the formula is built – by the kit, not by the data.
Dependency graph
The atoms of a written value #
A source names a written value: the three cases of
DescriptiveComplexity.SlotVal, read at the payload coordinates.
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
The next element after a control slot – what advancing a loop variable writes, and the only source that reads the order.
Dependency graph
Dependency graph
Dependency graph
A bit is a written value: the two designated elements, chosen by a
guard – so every DescriptiveComplexity.Draw.bitVal a rule writes is definable
as soon as the question behind it is.
Dependency graph
A value chosen by a condition of the kit – not of the data – is definable when both branches are.
Dependency graph
A value chosen by definable cases: finitely many conditions, each definable, at most one of which is asked to hold, with a default. This is what a write depending on which coordinate of a tuple rolled over needs.
Dependency graph
Values a slot may be compared with #
A readable value: one a slot may be compared with. Every written value is one, the comparison being the graph formula read at that slot.
Equations
- DescriptiveComplexity.Draw.UReadable V = ∀ (s : W), DescriptiveComplexity.Draw.UGDefinable fun (e : DescriptiveComplexity.Draw.Env L) (f : Q → e.α) (g : W → e.α) => g s = V e f g
Instances For
Dependency graph
Every written value is readable.
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Dependency graph
A value chosen by a condition of the kit, not of the data.
Dependency graph
From slots to payloads #
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Updating one control slot: every other slot is what it was, and the choice between the two cases is made per slot, when the formula is built.
Dependency graph
Updating one track slot.
Dependency graph
A pointer written by cases, the cases being decided by the kit.
Dependency graph
The payload statements the interpretation reads #
A payload transformation is definable: one formula over the input and the output coordinates defines its graph.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
A payload is definable when each of its coordinates is, the coordinate formulas being conjoined at the output variables they name.
Dependency graph
A definable pointer is a definable destination payload. The control slots are what the rule computes and the track slots are cleared.
Dependency graph
A definable track family is a definable written payload.
Dependency graph
The direction, written as a literal #
A rule that always moves right.
Dependency graph
And one that always moves left.
Dependency graph
The shape of most of the program's rules #
A guard, with the pointer and the tracks riding along unchanged.
Dependency graph
A rule that keeps its pointer, writing only its tracks.
Dependency graph
A rule that keeps its tracks, writing only its pointer – every checkpoint's dispatch.