Lecture from: 31.10.2025 | Video: Videos ETHZ
Recap: The Landscape of Undecidability
We have established a hierarchy of languages based on their solvability.
- (Recursive): The problem is decidable. A Turing Machine exists that always halts and gives the correct Yes/No answer.
- (Recursively Enumerable): The problem is semi-decidable. A Turing Machine exists that will eventually accept a Yes-instance, but for a No-instance, it might run forever.
- Outside : The problem is not even recognizable.
We proved that the Diagonal Language () lies outside . Its complement, , lies inside but outside . We also introduced the Universal Language (), which asks if a given machine accepts a given string . By reducing to , we proved that is also undecidable.
The Halting Problem ()
We now turn to a problem even more fundamental than acceptance: Halting. When we run a program, we often want to know: “Will this code eventually finish, or is it stuck in an infinite loop?”
Formal Definition
Here, “halts” means the machine reaches either the or state. If the machine loops, it never reaches either.
Undecidability via Recursive Reduction
Is decidable? Intuitively, no. If we could solve it, we could solve the Universal Language . Let’s verify this using a Recursive Reduction ().
/Semester-3/Theoretical-Computer-Science/Lecture-Notes/attachments/Pasted-image-20251203151316.png)
Imagine we have a hypothetical “Black Box” (Oracle) that solves . We can use it to build a decider for (Acceptance):
- Input: A pair . We want to know if accepts .
- Ask the Oracle: “Does halt on ?”
- Case NO: If the Oracle says does not halt, then loops forever. Consequently, it can never reach . We reject.
- Case YES: If the Oracle says does halt, we are safe to simulate on . We know the simulation will not run forever.
- If the simulation lands in , we accept.
- If the simulation lands in , we reject.
Since this algorithm would decide , and we know is undecidable, the Oracle for cannot exist. Thus, is undecidable.
Many-One Reductions () and Equivalence
While recursive reduction is powerful, complexity theory often relies on the stricter Many-One Reduction (or Input-to-Input Reduction, ). Here, we cannot use the Oracle as a subroutine or invert its output. We must transform the input of Problem A directly into the input of Problem B.
Let’s examine the relationship between Acceptance () and Halting () using this stricter tool. It turns out they are equivalent: we can reduce them to each other.
Direction 1: Reducing Acceptance to Halting ()
We want to transform a question about acceptance (“Does accept ?”) into a question about halting (“Does halt on ?”).
The Transformation
We construct a new machine that wraps the original machine .
- If reaches , should halt. (This is natural behavior).
- If reaches , should NOT halt.
- If loops, should NOT halt. (This is natural behavior).
Construction of
We modify the transition function of . We locate every transition that points to the reject state . Instead of letting the machine reject and halt, we redirect these transitions to a new state, , which simply transitions to itself forever.
Outcome
- accepts halts.
- rejects enters the infinite loop (does not halt).
- loops on loops (does not halt).
Thus, . We have successfully reduced to .
Direction 2: Reducing Halting to Acceptance ()
Now let’s go the other way. We want to transform a question about halting (“Does halt on ?”) into a question about acceptance (“Does accept ?”).
The Transformation
We need to ensure that whenever stops (regardless of whether it said Yes or No), our new machine says “Yes” (Accepts).
Construction of
We again modify the transition function of .
- We look at the state. It stays as it is.
- We look at the state. We redirect all transitions that would have gone to so that they now go to instead.
Outcome
- halts (accepts) accepts.
- halts (rejects) accepts (because we bent the pointer).
- loops loops (does not accept).
Thus, .
This proves that and are computationally equivalent under Many-One reduction. They reside in the same degree of unsolvability.
The Emptiness Problem () and Its Complement
We now move beyond properties of simulation (like Halting) to semantic properties of the language a machine accepts.
The Emptiness Problem asks: Given a Turing Machine , is the language it accepts empty? In other words, does it reject or loop on every possible input?
Conversely, we have the Non-Emptiness Problem (or the complement of Emptiness): This asks: Does the machine accept at least one input?
Is Recursively Enumerable?
The transcript discusses two ways to see this.
Method 1: Dovetailing (Deterministic)
We want to find one witness string that accepts. We cannot check strings sequentially () because if loops on , we never get to check . Instead, we use Dovetailing (Schwalbenschwanz-Methode). We simulate on all inputs in parallel slices:
- Phase 1: Run on for 1 step.
- Phase 2: Run on for 2 steps; Run on for 2 steps.
- …
- Phase : Run on for steps.
If there is any word that is accepted, it will be accepted in a finite number of steps. Our dovetailing procedure will eventually reach that depth and halt with an “Accept”.
Method 2: Nondeterminism (The “Magical” Solution)
The lecture highlights a much faster, conceptual way to see this using a Nondeterministic Turing Machine (NTM). We know that DTMs and NTMs are equivalent in power ().
We can build an NTM, let’s call it , that recognizes :
- Input: (the encoding of the machine we want to check).
- Guess: Nondeterministically write a binary string on the tape. Because of nondeterminism, one branch of the computation will “guess” the correct witness string if it exists.
- Verify: Simulate on .
- Accept: If the simulation accepts, then accepts.
If there exists any word , the NTM has a computation path that guesses and accepts. Therefore, recognizes . Since NTMs are equivalent to DTMs, is in .
Proving Undecidability of
We know is recognizable. Is it decidable? We suspect not. To prove it, we will use a Many-One Reduction () from the Universal Language .
The Goal
We need a computable function (a transformation) that takes an instance of (a pair ) and produces an instance of (a new machine ) such that:
Constructing the Machine
This is a clever construction where we build a machine that ignores its own input. The machine is hardcoded with the descriptions of and .
Here is the code for (on input ):
- Delete the input . wipes its tape clean. It doesn’t care what input it received.
- Write on the tape. writes the hardcoded string (from our instance) onto its tape.
- Simulate on . runs the code of on this specific input .
- Accept if accepts. If the simulation reaches , accepts.
Analysis of
The behavior of depends entirely on the result of the fixed simulation of on . It does not depend on its own input .
-
Case 1: accepts . The simulation in step 3 succeeds. Therefore, proceeds to step 4 and accepts. Since this logic holds for any input (because was deleted at the start), accepts every possible string. Is this language non-empty? Yes. So .
-
Case 2: does not accept (rejects or loops). The simulation in step 3 never reaches an accepting state (it either rejects or runs forever). Therefore, never reaches step 4. It accepts nothing. Is this language non-empty? No. So .
Conclusion
We have successfully reduced to . Since deciding is impossible, deciding must also be impossible.
The Fate of
Since is undecidable, its complement (the Emptiness Problem) is also undecidable. Furthermore, since is in (recognizable), its complement cannot be in (unless it were recursive, which we just proved it isn’t).
Thus, we have placed these problems on our map:
- (Non-Emptiness): RE but Undecidable.
- (Emptiness): Not RE (completely unrecognizable).
Summary
We have successfully used reductions to expand our list of undecidable problems.
- Halting (): Undecidable. We can reduce Acceptance to Halting () and Halting to Acceptance ().
- Non-Emptiness (): Undecidable. We reduced Acceptance to Non-Emptiness by constructing a machine that ignores its input and runs the specific test case on .
This last proof technique, wrapping a specific computation inside a machine that ignores its input, is a powerful pattern. It hints at a much broader truth: Rice’s Theorem, which states that any non-trivial property of the language recognized by a Turing Machine is undecidable. We will explore this in the next lecture.