Rules that never fire, and the tags they buy #
A clocked program's budget is 2 ^ |Tag|, and its tags are its rule names: one
per site and shape. A reduction that needs a longer clock therefore needs more
rule names – and it needs them without changing anything else, because every
constant the clock is measured against (the file's registers, the evaluation's
widths, the record's own dimensions) is read off the same record.
This file is that knob. A junk site carries one rule whose guard is False:
it can never fire, so no run, no separation argument and no determinism argument
sees it, while the rule names go up by one. Padding a site type by Fin n adds
n of them.
The whole thing is generic in the site type, so it applies to any program the
definability layer writes down (padRules, uRulesDefinable_padRules), and the
count is one line (card_rTagOf_pad).
A rule that never fires: its guard is false, and everything else is the identity. It sits at a phase of the caller's choosing and is never reached there, the guard being what a step asks for first.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
The shapes of a padded site type: the old sites keep theirs, and each new one has a single rule.
Equations
- DescriptiveComplexity.Draw.padSh Sh n (Sum.inl i) = Sh i
- DescriptiveComplexity.Draw.padSh Sh n (Sum.inr val) = Unit
Instances For
Dependency graph
Dependency graph
The rules of a padded site type: the old ones, and a rule that never fires at each new site.
Equations
- DescriptiveComplexity.Draw.padRules rules p₀ n x✝ (Sum.inl i) ρ = rules x✝ i ρ
- DescriptiveComplexity.Draw.padRules rules p₀ n x✝ (Sum.inr val) x_4 = DescriptiveComplexity.Draw.falseRule p₀
Instances For
Dependency graph
Dependency graph
Dependency graph
The padded rules are definable: the old ones by hypothesis, and a rule
that never fires by uGDefinable_false.
Dependency graph
A junk rule writes nothing, so it keeps the file, keeps the addressed tracks, keeps every slot and writes bits – the four facts a backward reading asks of a rule it meets by name.
Dependency graph
And it leaves every slot as it found it.
Dependency graph
The rules of a padded site type, at one instance: the same padding as
padRules, for a program written down at a fixed universe rather than as a
family.
Equations
- DescriptiveComplexity.Draw.padRulesAt Sh rl p₀ n (Sum.inl i) ρ = rl i ρ
- DescriptiveComplexity.Draw.padRulesAt Sh rl p₀ n (Sum.inr val) x_2 = DescriptiveComplexity.Draw.falseRule p₀
Instances For
Dependency graph
Dependency graph
A junk rule never fires, which is all any run, separation or determinism argument needs to know about it.
Dependency graph
Padding keeps in-shape separation: two rules that fire on the same data in the same phase are the same, the junk ones firing on none.
Dependency graph
The family and the pointwise padding agree, which is what lets a program written down at one universe be read as the definability layer's.