4.6.14 · D3Theory of Computation

Worked examples — Variants — multi-tape TM, non-deterministic TM, all equivalent

4,588 words21 min readBack to topic

This is the hands-on companion to the parent topic. The parent proved the theorems; here we turn the crank on concrete machines so no scenario surprises you in an exam. If a term feels unfamiliar, it is built in Turing Machine — formal definition.


The scenario matrix

Every case this topic can throw at you falls into one of these cells. The worked examples that follow are each tagged with the cell they cover.

# Case class What is degenerate / extreme about it Example
A Multi-tape, normal step all heads in the middle of their blocks Ex 1
B Multi-tape, head hits right # a virtual tape is too short → grow on the right Ex 2
B′ Multi-tape, head hits left # head walks off the left end → grow on the left Ex 2b
C Multi-tape, (degenerate) "multi" with one tape = plain TM, zero overhead Ex 3
D Multi-tape time cost plug numbers into Ex 4
E NTM, accepting branch exists tree has ≥1 accept leaf → DTM must find it Ex 5
F NTM, all branches reject / loop wrong order (DFS) traps you forever Ex 6
G NTM, branching factor (degenerate) non-determinism that never branches = DTM Ex 7
H NTM time cost plug numbers into Ex 8
I Real-world word problem translate a story into "which model, which cost" Ex 9
J Exam twist combine variants + a trap in the reasoning Ex 10

Multi-tape examples

Ex 1 — Cell A · a normal simulated step

We encode all three tapes on one tape, #-separated, dot = virtual head. Figure s01 shows the whole step at a glance: the top row is BEFORE, the bottom row is AFTER, and the three colours (magenta, violet, orange) track tapes 1, 2, 3.

Figure — Variants — multi-tape TM, non-deterministic TM, all equivalent
  1. Write the "before" tape. In s01's top row, each coloured block is one virtual tape and the small orange dot sits over the head cell: Why this step? The single tape has no separate heads, so head positions must be stored as data — the orange dot in the figure is that storage.
  2. Sweep 1 (gather). Read left→right, record the three dotted symbols into the finite control. In s01, follow the top row left→right and read off the dotted cells. Why this step? The real reads all three heads simultaneously; one sweep collects them so the control holds the full tuple.
  3. Look up . Control now knows , so it fetches and moves . This is the labelled arrow between the two rows of s01. Why this step? is a finite table — once the read tuple is in hand the output is fully determined, no tape access needed.
  4. Sweep 2 (write & move). At the dot in each block: write the new symbol, then shift the dot one cell in the move direction. Compare the bottom row of s01 to the top:
    • Block 1 (magenta): write x, move dot R
    • Block 2 (violet): write e, move dot L
    • Block 3 (orange): write g, move dot R Why this step? This applies the simultaneous update the -tape machine did in one shot.

Result — "after" tape (bottom row of s01):

Recall Verify

No head ran off the left/right end of its block (every dot landed on a real symbol), so no block grew — this is a clean case. Two sweeps total. State advanced . The three virtual tapes now read x b c (head 2), d e (head 1), f g (head 2), which is exactly what the -tape machine would show. ✔


Ex 2 — Cell B · a head falls off the right end (grow on the right)

  1. Sweep 1 (gather), then before-state. As always, the simulator first sweeps left→right gathering the dotted symbols and looks up . The before-tape is . Why this step? This is the mandatory first of the two sweeps from the two-sweep definition above — even in a growth case we must gather all heads before touching anything.
  2. Sweep 2 begins on block 2. Write d, then try to move the dot R. The cell right of d is #, not a tape symbol — the virtual tape 2 is shorter than the head now needs. Why this step? Real Turing tapes are unbounded; a # is only our drawing of a boundary, not a real end. We must extend the block during this write-and-move sweep.
  3. Shift-right to insert a blank. Copy everything from that # rightward one cell further right, and drop a blank (the never-written symbol from the definition above) into the freed cell. Now the block reads d ␣ and the dot can sit on the new . Why this step? Growing a virtual tape on a shared real tape means physically pushing all later blocks over to make one cell of room.

Before → After:

Recall Verify

Tape 2 was length , now length — it grew by exactly one blank, which is what "reading past the written end" means for a real TM (unwritten cells are blanks ). Tape 1's head simply moved onto b. The dot now rests on a genuine cell, so the next step can read it. ✔


Ex 2b — Cell B′ · a head falls off the left end (grow on the left)

Figure s04 draws this mirror-image growth: the block gains a blank cell on its left side, and everything to the right slides over.

Figure — Variants — multi-tape TM, non-deterministic TM, all equivalent
  1. Sweep 1 (gather), then before-state. Sweep left→right gathering and look up . Before-tape: . Why this step? Same mandatory first sweep of the two-sweep skeleton; only the move direction in sweep 2 will differ.
  2. Sweep 2 on block 2. Write d, then try to move the dot L. The cell left of d is the opening # of block 2 — the head wants to stand before the first written cell. Why this step? Just like the right case, a # is only our drawing of a boundary; the real tape continues, unwritten, to the left.
  3. Insert a blank on the left — precisely which cells move. Everything from block 2's opening # onward — that is, the # itself and all symbols and delimiters to its right (here just d and the final #) — is copied one cell to the right. The single freed cell, sitting immediately after the opening #, is filled with a blank . Block 2 now reads ␣ d, and the dot sits on the new leading . Why this step? To make room on the left we push the opening # and the entire rest of the tape one cell right, then fill the one-cell gap with a blank — nothing to the left of block 2's opening # moves.

Before → After:

Recall Verify

Block 2 grew from d (length 1) to ␣ d (length 2), gaining its blank on the left, mirroring Ex 2's right-growth exactly. The head now sits on the fresh , ready to be read. Both directions handled ⇒ every off-the-end case is covered. ✔


Ex 3 — Cell C · the degenerate case

  1. Encode: . One block, one dot. Why this step? The general recipe still applies; there just happens to be a single block.
  2. Observe: the two # delimiters and the single dot are pure decoration around the original tape a b. Why this step? To see that the "simulator" is doing genuinely nothing extra structurally.
  3. Cost: each step is still 2 sweeps of an -length-overhead block, i.e. constant-factor overhead — no quadratic blow-up because there is only one head to track. Why this step? The bound comes from many blocks over a long tape; with one block the region is just the original tape.
Recall Verify

A -tape "multi-tape" machine is an ordinary single-tape TM, matching Turing Machine — formal definition exactly (up to the two harmless #s and the dot). The equivalence is trivial in this cell — a useful sanity anchor. ✔


Ex 4 — Cell D · plug the numbers into the time bound

  1. Recall the bound: single-tape time . Why this step? Proven in the parent: used tape length , and sweeps per simulated step . (The " sweeps" and the " blocks per sweep" both sit in the hidden constant.)
  2. Substitute : Why this step? The constant (and thus every trace of ) vanishes inside big- — this is exactly the constant-dropping rule from the definition above, and why is a red herring for power and even for the asymptotic cost.
  3. Evaluate the tight count at : base step-units. Why this step? A concrete number makes "quadratic slowdown" tangible.
Recall Verify

The multi-tape machine took steps; the simulator took on the order of — a slowdown, exactly the "square" the parent promised. because the constant is dropped. ✔


Non-deterministic examples

Ex 5 — Cell E · an accepting branch exists

Figure s02 draws the guess tree: the root is the empty address , each downward edge appends a choice digit, and the accepting node 2 1 is circled in orange.

Figure — Variants — multi-tape TM, non-deterministic TM, all equivalent
  1. List the BFS order over , shortest-first then lexicographic (read s02 level by level, left to right): Why this step? Tape 3 enumerates addresses in exactly this order; BFS guarantees a finite-depth accepting branch is reached in finite time.
  2. Walk them. For each address: copy tape 1 → tape 2 (fresh input), simulate using the tape-3 digits to pick choices, reject/abort, then increment tape 3. Why this step? This is the three-tape loop defined just above; the fresh copy on tape 2 is why the read-only input on tape 1 exists.
  3. Find the winner. Addresses all lead to reject/abort; address 21 (the orange-circled node in s02) reproduces the accepting run. Why this step? 2 1 = "step 1 take choice 2, step 2 take choice 1", the given accepting sequence.

The DTM accepts while tape 3 holds 2 1.

Recall Verify

21 is the 6th address in the enumeration . Since the accepting branch sits at depth , BFS reaches it after exhausting all depth- prefixes — finite, guaranteed. The DTM accepts iff some branch accepts, and one did. ✔ Compare with Non-determinism in Finite Automata (NFA = DFA), where the same "guess-and-verify collapses to deterministic" idea appears without the exponential cost.


Ex 6 — Cell F · why order matters (DFS trap)

Figure s03 contrasts the two strategies: the violet branch 1 spirals down into an infinite loop (where DFS dives and never returns), while the magenta branch 2 reaches ACCEPT at depth 1.

Figure — Variants — multi-tape TM, non-deterministic TM, all equivalent
  1. DFS attempt. DFS commits to choice 1 and follows it as deep as possible first. That path loops forever (the violet coil in s03), so DFS never returns to try choice 2. Why this step? DFS goes deep before wide; an infinite branch is a bottomless pit it never climbs out of.
  2. Consequence. The machine loops instead of accepting — a wrong answer on an input in the language. That is a correctness failure. Why this step? Recognizing a language means: accept every string in it. Getting stuck = failing to accept = wrong.
  3. BFS fix. BFS tries , then 1 (one step — no loop yet), then 2 — and 2 (the magenta accept node in s03) accepts. It explores depth fully before diving into 1's infinite depth. Why this step? By bounding depth per round, BFS reaches every finite-depth accept leaf before any infinite branch can trap it.
Recall Verify

Accepting address 2 sits at depth ; BFS reaches it in round 1 (order ). DFS would still be inside choice 1's loop. This is precisely why the parent insists on breadth-first. The distinction (loop vs accept) ties into Decidability and Recognizability: a recognizer may loop on non-members, but must never loop on a member. ✔


Ex 7 — Cell G · the degenerate NTM,

  1. Tree shape. With every node has one child: the "tree" is a single path. Why this step? Branching factor means no branching at all.
  2. Address enumeration. Tape 3 addresses over are — but every step's only valid choice is 1, so the first full-length address already runs the unique computation. Why this step? No wrong guesses exist to skip; the enumeration is trivial.
  3. Cost. Tree size branches ⇒ simulation cost is just the cost of running that one branch: polynomial, no blow-up. Why this step? Substitute into the parent's node count.
Recall Verify

for every , so there is exactly one branch — this NTM is a deterministic TM in disguise. The exponential blow-up of P vs NP problem appears only when . ✔


Ex 8 — Cell H · plug the numbers into the exponential bound

  1. Node count. A depth- binary tree has up to nodes. Why this step? Level holds nodes; summing all levels the top term dominates ⇒ .
  2. DTM cost. The DTM may visit them all, so simulation time . Why this step? BFS visits nodes; worst case it visits every one before the accept leaf.
  3. Evaluate at : total nodes ; the quadratic comparison value is . Why this step? A concrete count to feel the explosion: nodes to walk versus step-units — already larger.
Recall Verify

At : multi-tape-style cost ; NTM-style node count . Already bigger at , and the gap explodes as grows (: vs ). Same power, wildly different cost — the seed of P vs NP problem. ✔


Word problem and exam twist

Ex 9 — Cell I · real-world translation

  1. Identify the variant. "Guess a route, then verify" = non-determinism: branch over all candidate routes, accept if any verifies. That is an NTM. Why this step? Guessing-then-checking is the textbook signature of the NTM's accept-if-any-branch rule.
  2. Answer (a): the junior is describing an NTM.
  3. Answer (b): By the parent's theorem, every NTM has an equivalent DTM (via BFS over the guess tree on the three tapes above, exactly as in Ex 5–6). So a deterministic machine can solve the exact same decision problem — the guess adds zero new computable languages. Why this step? Power = set of recognizable languages, which is identical across the two models.
  4. The honest caveat. The known deterministic simulation costs — exponential. So the guess might be faster, but "faster" is a claim about complexity, not computability. Why this step? Separating the two axes is the whole point of the topic (and of Church–Turing Thesis).
Recall Verify

The junior conflated power with speed. Correct scoring: (a) NTM ✔; (b) not more powerful — a DTM solves it too — but possibly (unproven) not as fast. This is exactly the P-vs-NP open question, per P vs NP problem. ✔


Ex 10 — Cell J · exam twist (combine variants + spot the trap)

  1. Spot the trap. The word "combines" suggests two powers stacking into something new. Test that against the equivalence theorems. Why this step? Exam traps hide in unproven "combination" claims.
  2. Chain 1 — strip non-determinism. A non-deterministic -tape TM has an equivalent deterministic -tape TM (NTM→DTM simulation works tape-count-agnostically; the BFS just runs on however many tapes exist). Why this step? The NTM→DTM simulation from the parent does not depend on there being one tape.
  3. Chain 2 — strip extra tapes. A deterministic -tape TM has an equivalent single-tape deterministic TM (multi-tape→single-tape simulation, the #-and-dot encoding of Ex 1–2b). Why this step? The #-and-dot encoding collapses any down to .
  4. Conclude. Non-det -tape det -tape det -tape. So it recognizes exactly the single-tape-recognizable languages — nothing new. Why this step? Equivalence is transitive; two hops land us back at the humblest model.

Verdict: FALSE. Both upgrades are finite bookkeeping conveniences; composing them still stays inside computability.

Recall Verify

Transitivity of "" gives non-det-3-tape 1-tape-DTM, so the class of recognized languages is identical — the claim of new power is false. Any efficiency difference is a complexity matter, not a computability one. This robustness under stacked variants is the strongest evidence for the Church–Turing Thesis. ✔


Recall One-line self-test

Does adding tapes or guessing ever make a new language recognizable? ::: No — same computability, only (possibly) different speed. Why BFS and not DFS for NTM→DTM? ::: A wrong first guess can loop forever; DFS would get trapped and miss a nearby accepting branch, breaking correctness. Multi-tape slowdown order? ::: — quadratic. NTM→DTM slowdown order? ::: — exponential. When a head runs off the left #, where does the blank go? ::: Inserted on the left of the block (push everything right, fill with ). How many tapes does the DTM that simulates an NTM use, and what are they for? ::: Three — tape 1 = read-only input, tape 2 = working copy for one branch, tape 3 = the address naming which choices to take.