Lecture 19. Reduction: More Undecidable problems

1. Lecture 19. Reduction: More Undecidable problems • It turns out that many problems are undecidable. • In fact, many problems are even “harder” than being “undecidable”. You can actually have an infinite hierarchy of undecidable problems --- each level contains problems that are “more undecidable” than those in the previous level. • Here is another undecidable problem – The Post correspondence problem. • Input: list of pairs of strings (x1, y1), … ,(xn,yn) • Question: Does there exist a finite nonempty list of indices i1, i2, ... , ir such that • xi1 xi2 ... xir = yi1 yi2 ... yir ?

2. Example of the Post correspondence problem • Input might be (x1, y1) = (1, 111) (x2, y2) = (10111, 10)(x3, y3) = (10, 0) and a corresponding solution is (i1, i2, i3, i4) = (2,1,1,3) which gives xi1 xi2 xi3 xi4 = yi1 yi2 yi3 yi4 = 101111110 • Exercise: is the following instance solvable? If so, provide it: (x1, y1) = (0, 1) (x2, y2) = (1, 011)(x3, y3) = (011, 0) • Emil Post proved in 1944 that the Post correspondence problem is unsolvable.

3. Reductions: proving problems unsolvable • If we know a problem A is unsolvable (e.g. the Turing’s Halting problem), in order to show another problem B to be unsolvable, we “reduce” A to B via computable process. If this can be done, then B is also unsolvable, since otherwise we can always reduce A to B and solve B, and then get solution for A, a contradiction to the fact that A is unsolvable.

4. Examples of reductions. • Claim. “Does program P halt on all inputs?“ is unsolvable. • Proof. Suppose it is solvable. I.e. a program "alwayshalts" that takes a program P as an input and returns "true" iff P halts on all inputs. We show how to use "alwayshalts" to solve the original halting problem. Given P and I, we create a new program as follows: Reduce(); /* simply run P on I { run P on I; } Now call alwayshalts(Reduce()). Since no matter what the input is to “Reduce”, it runs P on I, if alwayshalts(Reduce) returns "true", then P halts on input I. If alwayshalts(Reduce) returns "false", then P doesn't halt on input I. Thus calling "alwayshalts(Reduce)“ solves the halting problem for program P and input I. But we know that is unsolvable, a contradiction. QED

5. One more example. Claim. "does P index an array out of bounds on input I?“ is unsolvable. Proof. Suppose the problem is solvable. I.e. a program "arrayindex" takes a program P and input I as input and returns "true" iff P attempts to index an array out of bounds on input I. Reduction: void indextest(J:input); x : array[1..1] of integer; simulate P on input I, making sure P never indexes an array out of bounds (by run-time checking) if (P halts on I) x[2] := 1; /* array out of bound Function "indextest" has been defined in such a way that it indexes an array out of bounds if and only if P halts on I. We have now reduced halting problem to “array-out-of-bound”.

6. Reductions – understand it better • We say a computational problem A reduces to a problem B if you can solve A given access to an algorithm to solve B as a subroutine. • Example: "primality testing" reduces to "compute prime factorization". To see this, we need to see how to test n for primality, given an algorithm to compute the prime factorization of n. That's easy: we just compute the prime factorization of n and see if it consists of a single prime. • Example: "compute the median of a list" reduces to "sort a list". Again, this is easy: first, sort the list of n numbers; then look for the element in position ceil(n/2). • Example: The problem of determining the median reduces to the problem of computing the k-th smallest. Less obviously, the problem of determining the k-th smallest reduces to the problem of computing the median. (Why?)

7. Reduction continues • If problem A reduces to problem B, we say that "problem B is at least as hard as problem A“ (note: not time complexity). This is sensible, because knowing an algorithm for B allows us to solve A, but not necessarily the other way around. We sometimes write A ≤ B. This notation is very helpful, because the inequality goes from the "easier" problem to the "harder" problem. • There are two facts about reductions: • if A reduces to B, and B is solvable, then A is solvable. • if A reduces to B, and A is unsolvable, then B is unsolvable. • It suffices to prove the first, because the second is just the contrapositive. The proof is trivial: since B is solvable, there is an algorithm to solve it. Now A is solvable using an algorithm for B. So A is solvable.

8. One more example • Claim. Program-equivalence problem ("given two Java programs P1 and P2, do they have the same input-output behavior on all inputs"?) is unsolvable. • Proof. We reduce the halting problem to it. To show that, we must figure out a way to solve the halting problem given an algorithm for the program-equivalence problem. We let P1 be the program that ignores its input and runs P on input i, returning "1" if P halts on i (and not halting otherwise). We let P2 be the program that ignores its input and returns "1". Then P1 and P2 have the same input-output behavior on all inputs if and only if P halts on i. So we have reduced halting to the program-equivalence problem. It follows that program-equivalence is unsolvable.

9. Foolproof virus testing is impossible • A computer virus is a piece of code that, when you run it, it somehow causes the operating system of the computer to be altered. Obviously, computer viruses are undesirable, and millions of dollars are spent every year on testing software for viruses and removing them. We'd like to have a perfect virus tester. • Unfortunately, such a thing cannot exist. Suppose there were a perfect virus tester. Such a thing might be a function virusfree(P:program, I:input) that returns "false" iff program P run on input I alters the operating system. Of course the program "virusfree" must itself not be a virus --- not alter the operating system when it is run.

10. Two proofs Proof 1 (by reducing the halting problem to it). Given a Halting problem instance (M,x), construct new program P such that P is a virus iff M(x) halts: x M halt Alter the OS P

11. Direct proof Proof 2. Create a program S that on input W checks to see if running W on W is safe according to "virusfree". If it is safe, then S alters the operating system. Otherwise, S does nothing. What happens when we run S on input S? If running S on S is safe, then virusfree(S, S) returns "true". But then S alters the operating system, so running S on S is not safe. • If running S on S is not safe, then virusfree(S, S) returns "false". But then running S on S does nothing, so virusfree(S, S) should have returned "true". • Neither answer is correct, so a perfect virus tester cannot exist. QED