Documentation

DescriptiveComplexity.Problems.Wide.DrawDefAsm

The whole assembly is definable, given its semantic packs #

The last floor: one variable's machinery (DescriptiveComplexity.Draw.Data.varRuleF), the evaluation's machineries (smRule), its spine (evalRuleF) and the program's assembly (progAsm) are definable as soon as the semantic packs are – which is what DescriptiveComplexity.Draw.Data.UVarArgsDef says, field by field: the four control locations a variable's machinery names must be the same at every instance, and every guard and control update it carries must be definable.

Nothing above this file reads a rule any more: what is left of the discharge is DescriptiveComplexity.Draw.Data.varArgsOf meeting UVarArgsDef, which is a statement about DescriptiveComplexity.Problems.Wide.DrawArgs alone.

structure DescriptiveComplexity.Draw.Data.UVarArgsDef {L : FirstOrder.Language} {dt : Data L} {Q : Type} [Fintype Q] [Fintype dt.SlotIx] (v : dt.VarIx) (args : (e : Env L) → dt.VarArgs v) :

What one variable's semantic pack owes.

Instances For
    Dependency graph
    theorem DescriptiveComplexity.Draw.Data.uRulesDefinable_varRuleF {L : FirstOrder.Language} {dt : Data L} {Q P : Type} [Fintype Q] [Fintype dt.SlotIx] {v : dt.VarIx} {args : (e : Env L) → dt.VarArgs v} {emb : dt.VarPhF vP} {exitPh : P} (h : UVarArgsDef v args) :
    URulesDefinable fun (e : Env L) => dt.varRuleF e.zero e.one v (args e) emb exitPh

    One variable's machinery is definable: the gates, the round – inner gates and matrix behind the branch checkpoint – and the variable's own checkpoints.

    Dependency graph
    theorem DescriptiveComplexity.Draw.Data.uRulesDefinable_smRule {L : FirstOrder.Language} {dt : Data L} {Q : Type} [Fintype Q] [Fintype dt.SlotIx] {args : (e : Env L) → (v : dt.VarIx) → dt.VarArgs v} (h : ∀ (v : dt.VarIx), UVarArgsDef v fun (e : Env L) => args e v) :
    URulesDefinable fun (e : Env L) => dt.smRule e.zero e.one (args e)

    The evaluation's machineries are definable: one copy of the variable machinery per spine position, and the output's.

    Dependency graph
    theorem DescriptiveComplexity.Draw.Data.uRulesDefinable_evalRuleF {L : FirstOrder.Language} {dt : Data L} {Q : Type} [Fintype Q] [Fintype dt.SlotIx] {args : (e : Env L) → (v : dt.VarIx) → dt.VarArgs v} (h : ∀ (v : dt.VarIx), UVarArgsDef v fun (e : Env L) => args e v) :
    URulesDefinable fun (e : Env L) => dt.evalRuleF e.zero e.one (args e)

    The evaluation is definable: its spine over the machineries.

    Dependency graph
    theorem DescriptiveComplexity.Draw.Data.uRulesDefinable_progAsm {L : FirstOrder.Language} {dt : Data L} {Q : Type} [Fintype Q] [Fintype dt.SlotIx] {args : (e : Env L) → (v : dt.VarIx) → dt.VarArgs v} (h : ∀ (v : dt.VarIx), UVarArgsDef v fun (e : Env L) => args e v) :
    URulesDefinable fun (e : Env L) => dt.outerRule e.zero e.one (dt.evalRuleF e.zero e.one (args e)) (EvalPh.chk 0) (EvalPh.sub dt.smEntryOut)

    The whole program's rule set is definable: the outer loop around the evaluation. This is DescriptiveComplexity.Draw.Data.progAsm's rule field, so an interpretation may be written down from here.

    Dependency graph