advertisement

. We are dwelling on section 3.5 then going back to pages 48–50 while reductions “sink in.” We will cover Rice’s Theorem from section 3.8

as an example of reductions. Read 3.6 but skip 3.7 and 3.10; if we cover 3.9 it will be in tandem with the “Polynomial Hierarchy” from chapter 7 at the end of the course. Skim 3.9 just to get the idea that in the same sense that RE corresponds to one unbounded ∃ quantifier on page 48, so also co RE corresponds to ∀ . And you can define more highly complex languages by combining quantifiers. For instance: M e is total iff ( ∀ x )( ∃ t )[ M e ( x ) halts within t steps]. As with “solid boxes” in flowcharts, the intent is that predicates expressed within square brackets are decidable.

The discussion problem is not for separate credit and the answers to (a–c) are intended to be revealed—but they should be part of your essay answer to the for-credit problem (1).

(A) A program verification system attempts to prove certain properties of programs Generally we’ll stick to the triad of properties described in Friday’s lecture: P .

1. Does P halt on (or accept) a given input x ?

2. Is there some input x such that P ( x ) halts (or accepts)?

3. Does P ( x ) halt on (or accept) all inputs x ?

An example of an actual and pretty successful system for the third—which is the Program Termination (PT) property—was the Microsoft “Terminator” project (see the section on it at https://rjlipton.wordpress.com/2014/10/01/the-busy-beaver-problem/) which cleared up a lot of bugs caused by device drivers in Windows XP. Focusing on PT, the system gives us a program Q —itself total—such that if Q accepts a program P , then P is total. The limitation—but which also enables Q to be real code—is that we don’t always get the converse: Q is allowed to reject some programs that really are total. In general terms, Q is allowed to give false negatives but not false positives .

As with MS Terminator, program P Q is real code—not quixotic (yet). Hence also the following is real code—not “paradoxical”: bool P(string z) { if (z fails to compile to a valid program M) { reject; } //else we have M if (Q rejects z) { reject; } //now we know M is total if (M accepts z) { reject; } else { accept; } } This program P is total—crucially because Q is total and Q never gives a false positive.

We humans can see that. The question is, can our verification system “see” it? Take the code of P and q to be the code of Q : so p compiles to P and q compiles to Q p to be . (If you like the e ( · ) function, p = e ( P ) and q = e ( Q ).) (a) Show that Q cannot accept p .

(b) What actually happens when P is run on input p ?

(c) If Q accepts q , does that cause a contradiction when P is run on q ?

(1) Show that pts.) Q cannot accept the code of

program M such that L ( M ) = L ( P ). (12 (2) Consider the triad of problems you get from the program behavior that a single-tape Turing machine M overwrites a non-blank character by the blank B . (A basic fact you need to know is that Turing machines can always be programmed to treat a char like ‘%’ as a “virtual blank” and avoid writing the actual blank B , unless. . . ) Stated as decision problems, their questions are: 1. Given M and x , does M ( x ) ever overwrite a non-blank char by B ?

2. Given M , is there some x such that M ( x ) does that behavior?

3. Given M , does M ( x ) do that behavior for all x ?

State the languages L 1 , L 2 , L 3 of these problems using set notation, and then prove that all three languages are undecidable. (39 pts. total, for 51 on the set)