CS200: Computer Science, Spring 2002

Notes: Friday 22 March 2002
Schedule
 Monday, 25 March: Problem Set 6
 Wednesday, 27 March: Read SICP, Chapter 4 (you may skip 4.1.6 and 4.1.7 and 4.4end).
 Before 3 April: GEB, Aria with Diverse Variations and Chapter XIII: BlooP and FlooP and GlooP.
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 contradicthalts:(define (contradicthalts) (if (halts? contradicthalts) (infiniteloop) 200))But contradicthalts is nonsensical: 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 infiniteloop, and if seems likely to exist (and its worked well for us so far). So, it must be halts? that cannot exist.The alwayshalts 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)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.
Output: true if P always halts when applied to any parameter, false otherwise.With the alwayshalts 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:
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).
Front: Back:
ba bba Card 1
ab a Card 2
Problem 1. Check Post
Input: An ordered sequence of Post Cards.Problem 2. Finite With Copying
Output: true if the sequence is a valid correspondence (the top and bottom sides of the cards spell the same thing), false otherwise.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 LProblem 5. Grading Exam 1 Question
Output: A BNF grammar that describes language LInput: 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. PolicyEnforcement 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. TicTacToe Problem
Input: A position in 3x3 TicTacToe (an array of nine squares, each either contatining an X, an O, or empty)A winning strategy for X means a procedure for selecting moves that makes X win, no matter what O does.
Output: true if X has a winning strategy for the game; false otherwiseProblem 11. Chess Problem
Input: A chess positionNote if we could solve this problem for the initial chess position, chess competitions would quickly become very dull! (Why are there no world tictactoe competitions?)
Output: true if white has a winning strategy for the game; false otherwiseProblem 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 infiniteboard chess
Output: true if white has a winning strategy for the game; false otherwise
University of Virginia Department of Computer Science CS 200: Computer Science 
David Evans evans@virginia.edu Using these Materials 