The names a trip walks to are definable #
Every trip of the program is aimed by a naming guard: this cell is the
canonically padded cell of the element whose block is b and whose first dd₀
coordinates spell a given tuple. The coordinate loops spell it from the control
directly (DescriptiveComplexity.Draw.Data.nameG); the leaf reads of the
element loops spell an encoded tuple
(DescriptiveComplexity.Draw.Data.encCoord), and this file says that is a
naming guard the interpretation can write down too.
The reason is the layout, not the data: at each coordinate an encoded tuple
holds a component of the one-hot code – one of the two designated elements – or
a payload position, or the clear element, and which it holds is decided by
DescriptiveComplexity.Draw.EncLayout when the formula is built. So an encoded
coordinate is DescriptiveComplexity.Draw.UReadable as soon as the payload is,
and every payload the program spells is a control slot or the clear element.
An encoded coordinate #
A coordinate of an encoded tuple is readable: the code coordinates hold a designated element, the payload coordinates the payload, the rest the clear element – three cases the layout decides, not the data.
Dependency graph
A name coordinate the control computes is readable.
Dependency graph
The naming guard, from readable coordinates #
A naming guard whose coordinates are readable is definable. This is
DescriptiveComplexity.Draw.Data.uGDefinable_nameGF with its hypothesis in
the form the encoded names supply it.
Dependency graph
A witness read's name is definable: the tag's encoded tuple, whose payload is the clear element throughout.
Dependency graph
The payload a read leaf spells #
A padded payload of control slots is readable, position by position: below the arity a slot of the control, beyond it the clear element – and which is which the arity decides.
Dependency graph
A domain read leaf's name is definable: its payload is the loop element at the levels the leaf's atom reads, padded.
Dependency graph
The well-shapedness questions #
The gates' file test asks of a cell that its name slots spell an encoded tuple: the witness of some tag, or a member of some relation variable. The first is a disjunction over a finite type of tags; the second quantifies a tuple of the instance, which no combinator covers – so the existential has to go, and the layout is what removes it. At a coordinate the encoding does not read from the payload the value is pinned; at one it does, the tuple is free, and a witness can be read straight off the cell.
A name coordinate the payload reaches: the encoded tuple is free there, so a well-shapedness test must not ask anything of it.
Equations
Instances For
Dependency graph
Away from the payload the encoded tuple does not depend on it.
Dependency graph
A member of a relation variable is a definable question of the cell: the payload coordinates carry no condition – a witness is read off the cell there – and every other coordinate is pinned by the code and the padding.
Dependency graph
The tag witness is a definable question of the cell.
Dependency graph
A gate's well-shapedness question is definable.
Dependency graph
And so is an inner gate's, the digit read off the VAL register.
Dependency graph
The leaf of a domain sentence #
The value of a domain sentence's matrix from the control is definable: its block atoms are read flags, and its other atoms are the questions a guard may ask of the instance – an equality, an order comparison, a relation of the source vocabulary – at the loop element.