The handed program, with room on its clock #
DescriptiveComplexity.Draw.Data.nexProgHanded is the program a reduction
into DescriptiveComplexity.WideRegAccept emits, and its clock is 2 ^ |Tag|
at its own rule names. The clock's one remaining obligation
(clock_count_of_tags) is that those names outnumber a constant of the kernel –
and a program may always have more of them, since a rule whose guard is False
changes nothing (PadRules.lean).
This file is that program: the same rules at the same sites, plus n sites
carrying a rule that never fires. Its record, its channel, its marks and its
phases are the originals – only the rule names are wider – so every constant the
clock is measured against is unchanged and the count goes up by n.
The rule names of the padded program: the clocked program's sites, and
n more carrying a rule that never fires.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
The tags of the padded machine's universe: the padded rule names, the alphabet's, the phases and the argument blocks.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
What the padding buys, at this program's rule names: one name per junk site, and nothing else moves.
Dependency graph
The handed program with n junk rule names: the same program, its rule
names padded.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
The padded program a clocked reduction emits: nexProgHanded with n
junk rule names.
Equations
- dt.nexProgHandedPadAt hzo hpl bot n = dt.nexProgHandedPad zero one hzo hpl (dt.regionSpec zero one) (fun (w : dt.VarIx) => dt.varArgsOf zero one w) bot n
Instances For
Dependency graph
The interpretation, and that it reads the padded table #
The padded program is the definability layer's, at the padded rules.
Dependency graph
The padded machine, written down: the interpretation whose universe is tagged by the padded rule names – the clock's budget, widened by the junk sites and by nothing else.
Equations
Instances For
Dependency graph
The interpreted structure reads the padded program's table: the same statement as at the unpadded program, at the wider rule names.
Dependency graph
The padded program separates just as the program does #
The padded program separates after its guess: at the old rule names this
is nexProgHanded_sep_rules, and a junk name fires on nothing.
Dependency graph
No rule of the padded program fires from its accepting phase: at an old
name that is nexProgHanded_srcPh_ne_acceptP, and a junk rule fires from the
start phase.
Dependency graph
The marking's consequences, at any program with that channel #
What a backward reading needs of the rules #
The rules a program of this shape has: at every rule name, either the rule of a site of the clocked program, or a rule that never fires. That is all a backward reading asks – it meets a rule by the name a step carries, not by the site it was written at – and both the emitted program and the padded one answer it, the second by its junk names.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
And so is the padded one, its junk names carrying a rule that never fires.
Dependency graph
What the marking, the order and the marker give the run, at any program whose channel writes for the argument elements and the one below them: the seven facts the join asks about the channel and the file's ends. This is This is the marking's seven consequences with the program abstracted, so that a padded program gets them by the same statement.
Dependency graph
What a reduction's program provides, in one record #
The facts a clocked program of this shape provides, collected: its rules
at the named sites, its channel's marks, its constants, its accepting predicate
and the separation its determinism is read off. Every layer of the run takes
this one hypothesis, and the two programs a reduction may emit – the plain one
and the padded one that buys the clock its room – provide it the same way, by
rfl at each field.
The rule name of a site and a shape.
- rules_site (i : NexSite dt.SEF) (ρ : NexSh dt.SEF (Option dt.KIx) (dt.d.B.ι → Bool) dt.NexSESh i) : PR.rules (self.site i ρ) = dt.nexRule PR.one (dt.nullSpec (Option dt.KIx)) (dt.regionSpec PR.zero PR.one) (dt.nexEvalRuleF PR.zero PR.one fun (w : dt.VarIx) => dt.varArgsOf PR.zero PR.one w) (EvalPh.chk 0) bot i ρ
And the rule it names is the clocked one.
- homeBuild : HomeKit.HomeRule → R'
The rule name of a step of the walk home after the file is laid.
- rules_homeBuild (ρ : HomeKit.HomeRule) : PR.rules (self.homeBuild ρ) = { t := Slot.mir, wk := Slot.wk, ph := NexPh.homeBuildP }.rule PR.one ρ
And it names that step.
- homeGuess : HomeKit.HomeRule → R'
The rule name of a step of the walk home after the guess.
- rules_homeGuess (ρ : HomeKit.HomeRule) : PR.rules (self.homeGuess ρ) = { t := Slot.mir, wk := Slot.wk, ph := NexPh.homeGuessP }.rule PR.one ρ
And it names that step.
- covered : NexCovered PR (dt.regionSpec PR.zero PR.one) (fun (w : dt.VarIx) => dt.varArgsOf PR.zero PR.one w) bot
Every rule name carries a site's rule or one that never fires.
- mark (x : Univ A R' (NexPh (Option dt.KIx) (EvalPh dt.nv dt.PMF)) dt.KIx dt.dd) : PR.mark x = regSlotMark PR.zero PR.one ⋯ x
The mark the channel writes.
- marked (x : Univ A R' (NexPh (Option dt.KIx) (EvalPh dt.nv dt.PMF)) dt.KIx dt.dd) : PR.marked x ↔ (∃ (k : dt.KIx), x.1 = Tag.arg k) ∨ IsTopNonArg x
And who it writes for: the argument elements and the one below them.
The tape is blank where the channel wrote nothing.
The machine starts in the start phase …
… with its control clear.
- accept_iff (p : NexPh (Option dt.KIx) (EvalPh dt.nv dt.PMF)) (f : dt.CtlIx → A) : PR.accept p f ↔ p = NexPh.acceptP ∧ (dt.varArgsOf PR.zero PR.one none).accBit f
It accepts in the accepting phase, at the output variable's bit.
- sepOn : PR.table.SepOn NexPh.PostGuess
Two rules firing on the same data after the guess are the same rule.
The post-guess phases are closed.
And no rule fires from the accepting phase.
Instances For
Dependency graph
The machine is deterministic after its guess, at any program of this shape: separation there, and the post-guess phases closed.
Dependency graph
An accepting control is in the accepting phase.
Dependency graph
And so does the padded one, its junk names never firing.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
Determinism after the guess, at any program of this shape #
The accepting phase is stuck, at any program no rule fires from it.
Dependency graph
An accepting configuration is stuck: it is in the accepting phase, and no rule fires from there.
Dependency graph
A configuration whose verdict is false accepts nothing below it, at any program that is deterministic after the guess: the run into the accepting phase with the bit clear is a dead end that does not accept, and there is only one run. What it reads of it is uniqueness after the guess and the accepting phase's two facts.