Skip to content

feat(MultiTapeTM): Nondeterministic multi-tape Turing machines - #802

Closed
barni120400 wants to merge 1 commit into
leanprover:mainfrom
barni120400:multitape/nondeterministic
Closed

feat(MultiTapeTM): Nondeterministic multi-tape Turing machines#802
barni120400 wants to merge 1 commit into
leanprover:mainfrom
barni120400:multitape/nondeterministic

Conversation

@barni120400

Copy link
Copy Markdown

This adds nondeterministic multi-tape Turing machines next to the deterministic ones from #384. The transition function is replaced by a transition relation ([Papadimitriou94] 2.7); nothing else about the model changes, so configurations and the effect of a single step move to a shared MultiTape/Basic.lean. No existing statement changes meaning.

The semantics is a labelled transition system on configurations, labelled by the emitted symbol. A computation is a chain of such transitions, in the style of SimpleGraph.Walk, recording the trajectory that space depends on and the labels that the output depends on. MultiTapeTM.toNTM embeds the deterministic machine and preserves computation in bounded time and space.

@barni120400
barni120400 force-pushed the multitape/nondeterministic branch 3 times, most recently from 7450891 to f44edbc Compare August 15, 2026 07:39
A nondeterministic multi-tape Turing machine is a `MultiTapeTM` whose
transition function is replaced by a transition relation. Configurations,
transition outputs and the effect of a single step move to a shared
`MultiTape/Basic.lean`; no existing statement changes meaning.

The semantics is a labelled transition system on configurations, a step
labelled by the symbol it emits. A `Computation` is a chain of such
transitions, with time, output and space read off it. `MultiTapeTM.toNTM`
embeds the deterministic machine and `toNTM_computes` shows the embedding
preserves computation in bounded time and space.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@barni120400
barni120400 force-pushed the multitape/nondeterministic branch from f44edbc to 1ef9de2 Compare August 15, 2026 07:46
@crei

crei commented Aug 18, 2026

Copy link
Copy Markdown
Collaborator

I already posted this on zulip while github was down.

Thanks for the pull request! I basically have two overall design questions:

First, do we really want to base the definitions on LTSs? It will look a bit alien to people used to the way NTMs are introduced in textbooks, and I'm also not sure that the output symbol is a natural label.

Secondly, and I think this also addresses the label question: I think it would be nice if a List of configurations would be the same as a computation. Then we could re-use the machinery from RelatesInSteps.lean and the number of steps is just the length of the list. At the same time, I myself recently removed the "output so far" from Cnf which makes it impossible to derive a unique output string from a list of configurations.

The main reason I removed it was to be able to count the number of reachable configurations. In the PR that does this, though, I also extracted a "storage configuration" which is the fields of the configuration without the input head position. So we need to be able to speak about a subset of the fields already.

After all, the output is written on a tape, so one could argue that it should be part of the configuration.
So maybe we should put it back after all? That would allow us to instantly "read off" the output from the halting configuration and also make a List Cnf be the same as a computation.

transition function is replaced by a transition relation: `Tr q input work out` holds when `out` is
one of the transitions permitted in that situation. Configurations, transition outputs and
`TransitionOut.apply` are shared with the deterministic machine.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if this is the right place, but I think we should clarify that in contrast to deterministic machines, it is possible that there is no successor configuration. This is not the same as halting because it does not reach a configuration with state = none. Maybe we should also cross-check what the textbooks say about this possibility.

Comment on lines +72 to +73
Tr (q : State) (input : Option Symbol) (work : Fin k → Option Symbol) :
TransitionOut k Symbol State → Prop

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Tr (q : State) (input : Option Symbol) (work : Fin k → Option Symbol) :
TransitionOut k Symbol State → Prop
Tr (q : State) (input : Option Symbol) (work : Fin k → Option Symbol) (action : TransitionOut k Symbol State) : Prop

Since we are making big modifications here anyway, maybe we can find a better name for TransitionOut as well?


/-- A computation of `ntm` from configuration `c`: a chain of transitions of `lts`, in the style of
`SimpleGraph.Walk`. -/
inductive Computation (ntm : MultiTapeNTM k Symbol State) (input : List Symbol) :

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you think (assuming we have #779), this could also be defined via List.isChain - something like

structure Computation (ntm : MultiTapeNTM k Symbol State) (input : List Symbol) where
  configurations : List (Cfg k Symbol State input)
  isChain : configurations.isChain ntm.Step
```

simp [Step, LTS.UnlabelledTr, lts_tr_of_halt h_halt]

/-- The initial configuration corresponding to an input string. -/
@[simp]

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found this simp annotation a bit annoying for deterministic TMs, maybe we should remove it for both.

@barni120400

Copy link
Copy Markdown
Author

Superseded by #820, which implements the same thing along the lines we settled on in the Zulip thread: the output tape lives in the configuration, so a computation path is a series of configurations rather than a labelled transition system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants