Skip to main content

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 66

Undecidability through Reductions from the Halting Problem

Recommended resources

Hello! Welcome to your next lesson on computability theory.

In the previous lesson, we introduced mapping reducibility, a powerful technique for proving problems are undecidable. We established the core logic: if a known undecidable problem can be reduced to a new problem (written ), then must also be undecidable. We used this to formally prove that the Halting Problem, , is undecidable by reducing the Acceptance Problem, , to it.

Today, we'll put this technique into practice. We will apply reductions from the Acceptance Problem to prove that several other fundamental questions about Turing Machines are also undecidable. This lesson directly addresses the learning outcome: Apply reductions from the Halting Problem to prove that other problems about TMs are undecidable. You will learn the common patterns and "tricks" used to construct these proofs, which are essential for mastering this topic.

We're moving from learning the tool of reduction to becoming proficient in using it on a variety of problems. This will reveal that for almost any non-trivial property of the language a Turing Machine recognizes, we cannot create an algorithm to decide it.

Network of Undecidable Problems and Reductions from the Halting Problem
This flowchart shows how the undecidability of the Halting Problem serves as the foundation for proving a wide range of other problems are undecidable. We'll be constructing some of these links today.

The Proof Template Revisited

Let's quickly review the structure of a proof by reduction. To prove a language is undecidable, we follow these steps:

  1. Assume (for contradiction) that is decidable by some Turing Machine, let's call it .
  2. Goal: Use as a subroutine to construct a decider, let's call it , for the known undecidable language .
  3. Construction: The decider takes an input for . Its key step is to define an algorithm that transforms into a new string that is a valid input for our hypothetical decider .
  4. Logic: The machine is specially constructed so that its properties, which can decide, are linked to the outcome of on . Specifically:
  5. Execution: runs on . If accepts, accepts. If rejects, rejects.
  6. Contradiction: Because correctly decides the undecidable language , we have a contradiction. Therefore, our initial assumption that the decider for problem exists must be false.

A common point of confusion is keeping track of the different machines involved. The following document makes this crystal clear.

Proving that a language L is undecidable by reduction

This guide from the University of Illinois provides a crisp, step-by-step recipe for reduction proofs and highlights a crucial point about the machines involved.

First, read the introduction on the first page, which outlines the three essential steps of a reduction proof. Then, at the top of the second page, carefully read the section marked with a square bullet (■) that lists the 'four distinct Turing machines' involved. Thinking of the reduction as a system with these four components will clarify the process.

The key insight is that the reduction itself is a constructor algorithm. Your experience designing APIs and data pipelines is analogous here: the reduction is a function that takes a description of one computational process ( on ) and generates the description of a new, related computational process ().


Example 1: The Emptiness Problem ()

Let's start with a classic undecidable problem: determining if a Turing Machine's language is empty.

The language is defined as:

We will prove is undecidable by reducing to it. More precisely, it's often easier to reduce to the complement, , which is the language of TMs that accept at least one string. Since a language is decidable if and only if its complement is, proving is undecidable is sufficient.

The following video provides an excellent, detailed walkthrough of this proof. The construction used is a classic "input-filtering" technique.

9. Reducibility

Professor Sipser explains how to prove E_TM is undecidable by reducing A_TM to it. Pay close attention to how the new machine, M_w, is constructed to 'filter' its inputs.

Watch the segment from 22:00 to 34:52. This covers the entire proof, from the initial idea to the formal construction and the final logic. Focus on understanding why the language of the newly constructed machine depends on whether the original machine accepts its input.

Let's summarize the construction from the video.

Proof that is undecidable:
Assume is decidable by a TM, R. We will construct a decider S for .

On input , S does the following:

  1. Construct the description of a new TM, . This is designed as follows:
    On input :
    a. If , reject.
    b. If , run the original machine on the input . Accept if accepts; reject if rejects.
  2. Run the hypothetical decider R on .
  3. If R rejects (meaning is not empty), then S accepts.
  4. If R accepts (meaning is empty), then S rejects.

Proof of Correctness:
Let's analyze the language of :

  • If accepts : The only input doesn't immediately reject is . When given , runs on and accepts. Therefore, . This language is not empty.
  • If does not accept (it rejects or loops): will never accept any input. If the input is not , it rejects. If the input is , it simulates on and also never accepts. Therefore, . This language is empty.

So, we have the crucial connection:

Our decider S uses R to check if is empty and inverts the answer, correctly deciding if . This is a contradiction, so is undecidable.


Example 2: The Regularity Problem ()

Let's tackle a more complex property. Is the language of a given TM regular?

The language is:

The proof strategy is the same, but the machine we construct must be more clever. We need to design an whose language is regular if does not accept , and non-regular if it does.

The following resource provides a concise, visual walkthrough of this proof.

Undecidability Reductions

These lecture slides from Prof. Busch at LSU walk through the undecidability proof for the REGULAR_TM problem. The diagrams clearly illustrate the construction of the new machine M'.

Study slides 36 through 42. They define the problem and then show the reduction from A_TM. Pay special attention to slide 41, which shows the two possible languages that M' can accept and why one is regular and the other is not.

Proof that is undecidable:
Assume is decidable by a TM, R. We build a decider S for .

On input , S does the following:

  1. Construct the description of a new TM, .
    On input :
    a. First, run the original machine on the input .
    b. If accepts , then proceed to check if the input has the form for . If it does, accept . Otherwise, reject.
    c. If does not accept , immediately rejects (or simply never proceeds past step 1a).
  2. Run the hypothetical decider R on .
  3. If R accepts (meaning is regular), then S rejects.
  4. If R rejects (meaning is not regular), then S accepts.

Proof of Correctness:
Let's analyze the language of :

  • If accepts : The check in step 1a passes. then proceeds to accept any string of the form . Therefore, . We know from the Pumping Lemma that this language is not regular.
  • If does not accept (it rejects or loops): The simulation in step 1a never finishes with an "accept". Thus, never accepts any input . Therefore, . The empty language is regular.

The logic holds:


Our decider S inverts the answer from R to decide , leading to a contradiction. We conclude that is undecidable.

Test your understanding!

Let's define a new problem: does a TM accept the string "ILLINI"?

How would you design the machine in a reduction from to prove that is undecidable? Think about the two possible outcomes for on and what should be in each case.

Show answer

We would construct from as follows:

on any input :

  1. Ignore the input .
  2. Run on .
  3. If accepts , then accept.

Now let's analyze :

  • If accepts , then accepts every input . So, . In this case, definitely accepts "ILLINI".
  • If does not accept , then never accepts any input. So, . In this case, does not accept "ILLINI".

Therefore, accepts if and only if accepts "ILLINI". This establishes the reduction , proving is undecidable.
This "ignore the input" technique is another common pattern in reduction proofs.


Conclusion

Today we've seen how the single undecidable problem we proved from scratch, , can be used as a foundation to prove that a whole class of other problems are also undecidable. By mastering the art of constructing a new machine whose properties are tied to the behavior of , we can systematically show the limits of computation.

Key Takeaways:

  • Reductions from are a versatile tool for proving other TM-related problems undecidable.
  • The core of the proof is designing a constructor algorithm that builds a new TM, , from the input .
  • The language of must have a specific property (e.g., being empty, regular, etc.) if and only if accepts .
  • Common construction techniques include input filtering (where only cares about one specific input) and input ignoring (where 's behavior is completely independent of its own input).

Preview of the Next Lesson:
The patterns we've seen today—proving that non-trivial properties of a TM's language are undecidable—are not a coincidence. They are instances of a powerful generalization called Rice's Theorem, which we will explore next. After that, we will look at undecidable problems that don't directly involve Turing Machines, such as the Post's Correspondence Problem (PCP), to see how far these limitations on computation extend.