University of Virginia, Department of Computer Science
CS200: Computer Science, Spring 2002

Notes: Friday 22 March 2002

Schedule
Undecidability

The version of the halting problem from the previous lecture was actually a more complicated (and more undecidable) version of the halting problem.

This is the traditional halting problem:

Input: a functional procedure P that takes no parameters Output: true if P halts; false otherwise.
We can prove it is undecidable informally by arguing that if we could define halts?, we could use it to define contradict-halts: 
   (define (contradict-halts)
      (if (halts? contradict-halts) 
          (infinite-loop)
          200))
But contradict-halts is non-sensical: if it halts, it loops infinitely; if it doesn't halt, it evaluates to 200 and halts. This means something in the program must not exist. I'm pretty sure 200 exists, and we know how to define infinite-loop, and if seems likely to exist (and its worked well for us so far). So, it must be halts? that cannot exist.

The always-halts problem (sometimes called the totality problem) from Lecture 23 is actually even more undecidable than the halting problem.

Input: a procedure P that has a parameter (with an infinite number of possible values)
Output: true if P always halts when applied to any parameter, false otherwise.
With the halting problem, we can at least sometimes get the right answer and know it. We could just evaluate (P) — if it halts we know the answer is true. If it doesn't halt, we don't know anything, we just keep waiting.

With the always-halts problem, we can't even do that. We can try evaluating (P x) for a particular x. If it halts that means it halts for some inputs, but we don't know if it always halts for all possible inputs. These kinds of problems are sometimes called highly undecidable, to distinguish them from partially undecidable problems (like the halting problem) for which we can sometimes get a correct answer. We won't worry about this distinction in this class. Knowing a problem is undecidable is enough to know there is no general procedure to solve it.

Today's Task: Problem Classification

Below is a list of problems. Classify each problem as decidable or undecidable. For the decidable problems, explain why it is possible (at least theoretically) to define a procedure that solves the problem. For the undecidable problems, argue convincingly why it is not. The easiest way to do this is usually to show the problem is at least as hard as some other problem that you already know is undecidable (such as the halting problem).

For the decidable problems, further classify them as O(n), P, NP or maybe not in NP.

The problems are grouped into sets around themes, but not necessarily in order of difficulty (either for you to classify them, or for producing a procedure that solves them). So, you may want to skip around instead of trying to answer them in order. Note that you can use what you learn in one problem to help solve another. For example, if you are able to determine that Problem 3 is undecidable, you attempt to show Problem 5 is undecidable by showing it is at least as hard as Problem 3.

I don't expect anyone will be able to classify all of these problems today. Most of these questions are really hard (for you to classify, not necessarily in the theoretical sense), the point of this is to practice.

Post's Correspondence Problem

This problem was invented by Emil Post in 1946. For these problems, you can think of the input are cards with one or more letters on each side of each card. We'll call each card a Post Card. A correspondence is when the sequence of letters on the front and back of the cards is the exact same. It is not permitted to flip the cards. For example, given the Post Cards:

Front:
Back:

ba
bba

Card 1

ab
a

Card 2

We can produce a proper arrangement by putting Card 2 first and Card 1 second. Then, both the top and bottom of the cards will spell abba (it is not necessary to spell the name of a Swedish pop group to have a satisfactory correspondence).

Problem 1. Check Post

Input: An ordered sequence of Post Cards.
Output: true if the sequence is a valid correspondence (the top and bottom sides of the cards spell the same thing), false otherwise.
Problem 2. Finite With Copying
Input: A set of cards as described above, a maxcopies number.
Output: Either a sequence of the cards (which may reuse each card up to maxcopies times) such that the top and bottom sides of the cards spell the same thing, or false.

Problem 3. With Copying (this is the standard Post's Correspondence Problem)

Input: A set of cards as described above.
Output: Either a sequence of the cards (which may reuse cards infinitely many times) such that the top and bottom sides of the cards spell the same thing, or false.


Languages

Recall that a language is a (possibly infinite) set of strings. Two languages are the same, if they describe the same sets of strings. That is, every string in the first language is also a string in the second langauge; and, every string in the second language is also a string in the first language.

Problem 4. Exam 1 Question

Input: An RTN that describes language L
Output: A BNF grammar that describes language L
Problem 5. Grading Exam 1 Question
Input: An RTN R and a BNF grammar G
Output: true if R and G describe the same language; false otherwise.

Problem 6. Language Correspondence

Input: Two BNF grammars, G1 and G2
Output: true if G1 and G2 describe the same language; false otherwise.

Viruses
Problem 7. Melissa Problem
Input: A Word macro (like a program, but embedded in an email message)
Output: true if the macros will forward the message to people in your address book; false otherwise.

Problem 8. Code Red Problem

Input: A program P and a virus program V
Output: true the there are inputs to the program that make it eventually behave identically to V; false otherwise.

Problem 9. Policy-Enforcement Program

Input: A program P and a safety policy S. You can view a safety policy as program that takes a description of an action (for example, '(read file C:\secret\mydiary.txt)) and evaluates to true if that action should be allowed.

Output: A program P' that behaves like P if P satisfies the safety policy, but if P would violate the safety policy, P' behaves like P until it would violate the safety policy and then halts instead of violating the policy.

Games
Problem 10. Tic-Tac-Toe Problem
Input: A position in 3x3 Tic-Tac-Toe (an array of nine squares, each either contatining an X, an O, or empty)
Output: true if X has a winning strategy for the game; false otherwise
A winning strategy for X means a procedure for selecting moves that makes X win, no matter what O does.

Problem 11. Chess Problem

Input: A chess position
Output: true if white has a winning strategy for the game; false otherwise
Note if we could solve this problem for the initial chess position, chess competitions would quickly become very dull! (Why are there no world tic-tac-toe competitions?)

Problem 12. Infinite Chess Problem

Instead of using the standard 8x8 chess board, consider playing chess on an infinite board. The checkerboard square pattern continues forever in all directions.

Input: A chess position for infinite-board chess
Output: true if white has a winning strategy for the game; false otherwise
CS 655 University of Virginia
Department of Computer Science
CS 200: Computer Science
 David Evans
evans@virginia.edu
Using these Materials