The cell of an encoded tuple: what one leaf read reads #
Every atom subroutine of the EXPSPACE program bottoms out in the same operation: ask one membership question of the block value held in an argument block of a register. The machine asks it by scanning to a cell – the register cell of the element whose tag is that block and whose coordinates spell the tuple – and reading the register's track there. This file is the joint between the two descriptions:
DescriptiveComplexity.Draw.Data.blkElt– the element an encoded tuple is, in a given argument block, andencCoord– its coordinates, computed from the control's slots (thecfofDescriptiveComplexity.Draw.Data.nameGF);DescriptiveComplexity.Draw.Data.encG_iff– the leaf read's guard holds at exactly that cell, which is what a navigation-by-name scan needs of its stopping condition, and what makes the trip's arrival known;DescriptiveComplexity.Draw.Data.blk_encAsgTup_iffandblk_encTagTup_iff– the digit found there: at a block holding the encoding of a point, a member tuple's question is one bit of the point's assignment – with no tag to match, the member codes carrying none – and a tag witness's question is the point's tag test (DescriptiveComplexity.Draw.mem_encPt_asg,mem_encPt_tag).
What makes the scans stop at the encodings' cells at all is that an encoded
tuple is canonically padded (encTup_isPad): the layout inhabits the first
dd₀ coordinates only, which is the budget
DescriptiveComplexity.Draw.Data.lyLt fixes.
The same padding is what carries all of this to a coarse file, where a
register is not an element: DescriptiveComplexity.Draw.Data.ixEncG_iff says
the read stops at the register the layout names by the encoded tuple's
coordinates, and elt_reg_encCoord says that register's address is the cell the
elementwise read would have gone to.
The element an encoded tuple is #
The cell of a tuple in an argument block: the block's tag with the tuple as its coordinates. Reading a register's track at this cell is asking whether the tuple belongs to the block value the register holds.
Instances For
Dependency graph
Dependency graph
Dependency graph
The coordinates of an encoded tuple #
The coordinates a leaf read compares against: the encoded tuple of a fixed discrete datum over a payload the control supplies, cut down to the name slots' width.
Equations
- dt.encCoord zero one c pay fc j = DescriptiveComplexity.Draw.encTup dt.ly zero one c (pay fc) (Fin.castLE ⋯ j)
Instances For
Dependency graph
An encoded tuple is canonically padded. The layout puts its code and
payload coordinates among the first dd₀, so beyond them the tuple carries
the designated zero: encoded tuples live in the cells the marks name, which
is what lets the machine scan to them.
Dependency graph
An encoding's members are canonically padded, so a block value that encodes a point is decided by the questions the machine can ask: the cells it can scan to are exactly the padded ones.
Dependency graph
The cell the guard identifies #
A leaf read stops at exactly the encoded tuple's cell. The guard of the trip – the block one-hot, the padding mark and the name slots against the coordinates the control computes – holds at a register cell precisely when that cell is the cell of the encoded tuple.
Dependency graph
A coordinate-loop trip stops at exactly the padded cell of the tuple
the control holds. The comparison and copy loops enumerate tuples of dd₀
coordinates and visit the canonically padded cell of each, in whichever block
they are reading.
Dependency graph
The register an encoded tuple is, at an arbitrary file #
A leaf read at a coarse file stops at exactly one register: the one the
layout names by the encoded tuple's coordinates. The elementwise
DescriptiveComplexity.Draw.Data.encG_iff read at a file whose registers are
not elements – the trips of an expansion atom ask which register they stopped
at, and the answer is a name the layout knows.
Dependency graph
The coordinates of an encoded tuple are the tuple, cut down: what the control computes for a leaf read is the payload the layout stores, so padding it back gives the encoded tuple itself.
Dependency graph
The register a leaf read names holds the encoded tuple: with the file's
names coherent with the encoding, the address of that register is the
elementwise cell the same read would have gone to. This is the one place the
coarse file and the encoding have to agree, and
DescriptiveComplexity.Draw.Data.pad_encCoord is why they do.
Dependency graph
What the trip finds there #
A register's digit at the cell of a tuple is the block value's membership question: the track holds a bit per element, and the elements of one argument block are that block's tuples.
Dependency graph
One leaf read is one bit of the assignment: at a block holding the
encoding of a point, the register's digit at a member tuple's cell says that
the point carries the tuple's tag and its assignment holds of the payload.
This is DescriptiveComplexity.Draw.mem_encPt_asg with the machine's cell in
place of the membership question.
Dependency graph
A tag witness's question is the point's tag test.