Reading a win back: the phases of a question #
The backward simulation, for the phases that settle a question. Where the forward direction builds a play, this one reads one back, so the two players change roles: an existential phase now has to be case-analyzed (the play chose one successor, and we must see what that choice proves) and a universal one may be instantiated at the successors we care about.
Everything it needs was built as an equivalence for exactly this reason –
DescriptiveComplexity.ctrlCfg_cases reads a control step back, and the
_det-style rule lemmas read a walk step back.
The three shapes of a phase #
- existential (
claim,conc,seek,preat an existential variable):DescriptiveComplexity.exists_altWin_succ_of_exgives the successor the play chose, and the step analysis says what it can be; - universal (
check,preat a universal variable):DescriptiveComplexity.altWin_succ_of_univinstantiates the play at any successor we can build – which is what the forward direction's step lemmas supply; - a walk (
seek): neither, but an induction onDescriptiveComplexity.ATMData.AltWinitself, the invariant being the one thing the walk is looking for. That the seek's phase does not change along the way is what makes it work.
What a seek proves #
DescriptiveComplexity.SeekArrives is what a winning seek delivers: a cell
whose symbol answers the test, together with the transition's tuple – the
seek's own valuation up to the arity its phase declares, and an address that
argsOf reads as the cell's. The tuple is kept because isTarget is a
condition on it, and only the program knows that the coordinates outside those
two halves are irrelevant.
Reading a win back, one step #
At a universal configuration every successor wins.
Dependency graph
At an existential configuration some successor wins, and it is the one the play chose.
Dependency graph
The cell a winning seek arrived at: its symbol answers the test, at a
tuple carrying the phase's valuation and an address argsOf reads as the
cell's.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
A configuration of the control accepts only in the accepting phase.
Dependency graph
What a winning seek delivers #
What a step of a seek may be: it stays in the phase with the tape untouched, or it is the arrival at the cell the seek was looking for.
Dependency graph
A winning seek has arrived somewhere. The phase never changes along the
walk and the tape is never touched, so the induction is on
DescriptiveComplexity.ATMData.AltWin itself.
Dependency graph
What a step of a rewind may be #
A rewind either walks on or hands over, and either way the tape is untouched – both its rules write back what they read. The handover lands on the lowest position, which is what the two sentinels being adjacent buys.
Dependency graph
A phase with one successor #
A phase with exactly one successor hands its win on, whichever player owns it: the universal one because every successor wins, the existential one because the successor it chose is that one. The valuation is carried over because the two phases declare the same coordinates.
Dependency graph
The concluding phase, the challenge round, the claim #
A winning concluding phase has its guard satisfied – which is the only thing it can be doing, since a false guard leaves it with no transition.
Dependency graph
A winning challenge round has correct claims and a satisfied guard. The phase is universal, so the play answers every challenge and the concluding branch as well; each is a successor we build.
Dependency graph
A winning claim phase has claimed something that survives the round.
Dependency graph
The prefix, read back #
A winning prefix phase proves its prefix. The mirror of
DescriptiveComplexity.altWin_pre, with the players' roles exchanged: at an
existential variable the play chose a value and we read it off, at a universal
one we instantiate the play at every value – each being a successor the forward
direction knows how to build.