SO(TC) needs no order: the order is a guessed state component #
DescriptiveComplexity.SOTCDefinable, like the clausal fragments and the
reachability logics, reads its three sentences over the ordered expansion of
the vocabulary and asks for the equivalence at every linear order on the
universe. For SO(TC) that hypothesis is removable, and this file removes it.
The reason it is removable here and not for SO-Horn, SO-Krom, FO(TC) or
FO(DTC) is the reason Fagin's theorem needs no order either: a walk over
assignments of a block can guess the order and carry it along. A state of
the walk is an assignment of relation variables, so one more binary variable
holds a candidate order; the source condition checks that it is a linear one
(DescriptiveComplexity.linearGuard), the transition condition says it does
not change, and every sentence of the original specification reads it in place
of the order symbol (DescriptiveComplexity.orderElimLHom and its two-copy
analogue below). The order is then a component of the certificate, exactly as
it is in the first block of a Σₖ₊₁ sentence
(DescriptiveComplexity.SecondOrderOrdered), and nothing outside the
specification sees it.
A deterministic fragment cannot do this – guessing is what the Horn and Krom
kernels do not have, and their capture theorems are genuinely statements about
ordered structures – so DescriptiveComplexity.PTIME,
DescriptiveComplexity.NL and DescriptiveComplexity.LOGSPACE keep the
hypothesis while DescriptiveComplexity.PSPACE loses it.
What this file contains #
DescriptiveComplexity.SOTCSpecFree, an SO(TC) specification whose three sentences live over the bare vocabulary expanded by copies of the block, with its semantics: acceptance is defined on structures carrying no order at all.DescriptiveComplexity.SOTCSpecFree.toSpec, reading such a specification as an ordinary one (the order symbol is simply never used), andDescriptiveComplexity.SOTCSpecFree.accepts_toSpec_iff.DescriptiveComplexity.SOTCSpec.orderFree, the converse construction: the order is guessed into the state, guarded at the source and frozen by every step (DescriptiveComplexity.SOTCSpec.orderFree_accepts_iff).DescriptiveComplexity.SOTCDefinableFreeand the equivalenceDescriptiveComplexity.sotcDefinable_iff_free, whenceDescriptiveComplexity.mem_PSPACE_iff_sotcDefinableFree: membership inPSPACEis definability by an order-free specification.
Order-free specifications #
An SO(TC) specification that does not see a linear order: as in
DescriptiveComplexity.SOTCSpec, the states of the walk are the assignments of
a block, but the three sentences live over the bare vocabulary expanded by
copies of the block, with no order symbol available.
- B : SOBlock
The block whose assignments are the states of the walk.
The transition sentence, over two copies of the block: the current state reads the first copy, the next state the second.
The sentence defining the admissible starting states.
The sentence defining the accepting states.
Instances For
Dependency graph
A state of the walk: an assignment of the block.
Equations
- spec.State A = spec.B.Assignment A
Instances For
Dependency graph
One step of the walk: the transition sentence, read with the current state in the first copy of the block and the next state in the second.
Instances For
Dependency graph
Reachability in the walk: the reflexive-transitive closure of
DescriptiveComplexity.SOTCSpecFree.Step.
Equations
- spec.Reach = Relation.ReflTransGen spec.Step
Instances For
Dependency graph
A state is a starting state when it satisfies the source sentence.
Instances For
Dependency graph
A state is accepting when it satisfies the target sentence.
Instances For
Dependency graph
The structure is accepted: some accepting state is reachable from some
starting state. No order on A is involved.
Equations
Instances For
Dependency graph
Reading an order-free specification as an ordinary one #
The easy direction: a specification that does not mention the order is one that happens never to use it. The language morphism below adds the order symbol to the vocabulary, and the two structures agree on everything else.
Adding the order to the vocabulary, over one copy of a block.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
Adding the order to the vocabulary, over two copies of a block.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
Dependency graph
Dependency graph
An order-free specification, read as an ordinary one: the three sentences
are transported along DescriptiveComplexity.addOrderOne and
DescriptiveComplexity.addOrderTwo, so the order symbol is present in the
vocabulary and used nowhere.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
Dependency graph
Dependency graph
Dependency graph
Acceptance does not depend on the order, for a specification that does not mention it.
Dependency graph
The order symbol, eliminated in favor of a state component #
The hard direction. The block of the walk is extended by one binary relation
variable (DescriptiveComplexity.SOBlock.withOrder, shared with the
order elimination of DescriptiveComplexity.SecondOrderOrdered), the three
sentences read that variable in place of the order symbol, the source condition
adds DescriptiveComplexity.linearGuard and the transition condition adds that
the variable does not change.
The order variable of the current state, as a symbol of the two-copy expansion.
Equations
Instances For
Dependency graph
The order variable of the next state, as a symbol of the two-copy expansion.
Equations
Instances For
Dependency graph
The guessed order does not change: the order variables of the two copies of the block agree.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
The language morphism eliminating the order symbol of the ordered expansion, over two copies of a block: the order is read in the copy holding the current state.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
Realization of DescriptiveComplexity.fixedOrdS: the two copies assign the
same relation to the order variable.
Dependency graph
The two-copy analogue of
DescriptiveComplexity.orderElimLHom_isExpansionOn: when the current state
assigns the linear order of the structure to the order variable, the two-copy
block expansion is an expansion along DescriptiveComplexity.orderElimTwoLHom
of the ordered one.
Dependency graph
The order-free reading of a specification #
The order-free reading of an SO(TC) specification: its state carries one extra binary relation variable holding a guessed order, the source condition checks that the guess is a linear order, every step freezes it, and the three sentences read it in place of the order symbol.
Equations
- One or more equations did not get rendered due to their size.
Instances For
Dependency graph
A sentence over the ordered expansion and one copy of a block says, read
through DescriptiveComplexity.orderElimLHom at a state whose order variable
holds the order, what it says of the underlying assignment.
Dependency graph
The two-copy analogue of DescriptiveComplexity.realize_orderElim_one: the
order is read in the copy holding the current state.
Dependency graph
At a state whose order variable holds the order of the structure, the
guard of DescriptiveComplexity.SOTCSpec.orderFree is satisfied.
Dependency graph
Dependency graph
Dependency graph
Dependency graph
The guessed order is the same all along a walk, and the rest of the state walks in the original specification.
Dependency graph
The converse walk: a walk of the original specification, run with the order of the structure guessed into every state.
Dependency graph
Acceptance by the order-free reading is acceptance under a guessed
order: the walk accepts exactly when the original one accepts for some
linear order on the universe. Together with order-invariance – the equivalence
required at every linear order in DescriptiveComplexity.SOTCDefinable –
this is what removes the hypothesis.
Dependency graph
Order-free SO(TC) definability #
A decision problem is order-free SO(TC) definable if it is defined by a
DescriptiveComplexity.SOTCSpecFree on nonempty finite structures – with no
linear order in the statement at all, unlike
DescriptiveComplexity.SOTCDefinable.
Equations
- DescriptiveComplexity.SOTCDefinableFree P = ∃ (spec : DescriptiveComplexity.SOTCSpecFree L), ∀ (A : Type) [inst : L.Structure A] [Finite A] [Nonempty A], P.Holds A ↔ spec.Accepts A
Instances For
Dependency graph
The order of SO(TC) can be guessed: order-invariant SO(TC) definability
over ordered structures and order-free SO(TC) definability are the same notion.
Left to right the order is guessed into the state
(DescriptiveComplexity.SOTCSpec.orderFree) – a linear order exists on every
finite universe, and by order-invariance any one of them will do; right to left
a specification that never mentions the order is one that ignores it.
Dependency graph
PSPACE needs no order: membership is definability by an order-free SO(TC) specification.