Labelled branches of counting machines #
MultiTapeCTM specializes the shared multi-tape machine to lists of transition occurrences.
An occurrence is identified by its list index: two equal actions in the list remain two choices.
Deterministic instructions have singleton lists. Configurations, actions and tape operations are
the existing Turing ones; no new machine storage or instruction model is introduced.
A branch records occurrence indices and stops at its first halted configuration. In contrast to the upstream unlabelled step relation, halted configurations have no further labelled steps. An empty list at a running configuration is stuck, not a rejecting halt.
Main definitions #
Turing.MultiTapeCTM: the list-choice specialization of the common machine.Turing.MultiTapeCTM.lts: labelled transitions, using the existingCslib.LTSinterface.Turing.MultiTapeCTM.runBranch: replay a list of occurrence indices.Turing.MultiTapeCTM.branches: first-halting branches of bounded length.Turing.MultiTapeCTM.HaltsWithin: an all-branches time bound excluding stuck states.Turing.MultiTapeCTM.Nonblocking: no local view has an empty live transition list.Turing.MultiTapeCTM.acceptCount,Turing.MultiTapeCTM.rejectCount: terminal branch counts.
Main results #
Turing.MultiTapeCTM.mem_branches_iff: the enumeration is exactly the bounded terminal traces.Turing.MultiTapeCTM.HaltsWithin.branches_eq: larger sufficient clocks preserve every branch.Turing.MultiTapeCTM.exists_branchBound: finite control and alphabet bound occurrence counts.
This is operational counting semantics, without a claimed polynomial-time verifier or a new
storage/instruction model. Canonical certificates are developed in MultiTape.Counting.Certificate.
References #
- L. Valiant, The complexity of computing the permanent
- S. Fenner, L. Fortnow, S. Kurtz, Gap-definable counting classes
The shared machine calculus is adapted from the cslib crypto branch; its source and authors are
credited in MultiTape.Machine and MultiTape.Machine.Equivalence. The counting layer retains
the transition identities forgotten by the relation-based nondeterministic interface.
The live transition occurrences, in their specified order. A halted state has no choices.
Instances For
Every running local view has a transition occurrence. This excludes stuck states even on
unreachable configurations; a native HaltsWithin hypothesis only needs the reachable ones.
Instances For
A nonblocking transition table has an occurrence at every running configuration.
Execute one occurrence. Invalid indices and attempts to step a halted configuration fail.
Instances For
The native labelled transition system; labels identify occurrences, not their effects.
Instances For
Replay is exactly the existing LTS multistep relation, with the occurrence labels retained.
From a halted configuration, only the empty trace can be replayed.
Replaying concatenated traces is sequential replay; a premature halt cannot be crossed.
A labelled step is exactly an in-range list occurrence, even if other occurrences agree.
The finite enumeration is exactly the first-halting LTS traces within the given clock.
Every branch halts within this many actual transitions. Running configurations must have at least one occurrence, so a stuck branch cannot make a time bound hold vacuously.
- halt {k : ℕ} {Symbol : Type u_1} {State : Type u_2} {input : List Symbol} {machine : MultiTapeCTM k Symbol State} {fuel : ℕ} {cfg : Cfg k Symbol State input} (halted : cfg.Halted) : machine.HaltsWithin fuel cfg
- step {k : ℕ} {Symbol : Type u_1} {State : Type u_2} {input : List Symbol} {machine : MultiTapeCTM k Symbol State} {fuel : ℕ} {cfg : Cfg k Symbol State input} (nonempty : machine.actions cfg ≠ []) (next : ∀ (index : Fin (machine.actions cfg).length), machine.HaltsWithin fuel ((machine.actions cfg)[index].apply cfg)) : machine.HaltsWithin (fuel + 1) cfg
Instances For
Enlarging a sufficient clock does not add transitions after a branch halts.
A successful replay cannot pass the all-branches halting bound.
A sufficient clock can be increased without changing any terminal branch multiplicity.
The no-stuck condition guarantees at least one terminal branch.
Count terminal branches whose output satisfies a Boolean verdict. A failed replay is never counted, even for the complementary verdict.
Instances For
Acceptance and rejection partition the terminal branches, without counting stuck states.
Finite control and a fixed finite alphabet give one fixed bound on transition occurrences.
Repeated actions are counted separately; their multiplicity is not bounded by Nat.card Action.