CSE596
Problem Set 5 Answer Key
Fall 2015
(A) A program verification 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.
. . . [A]lso the following program P 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 p to be
the code of P and q to be the code of Q: so p compiles to P and q compiles to Q. (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?
Answer: (a) Two answers were fine: (i) If Q accepts p and we suppose the third line is
executed to completion (based on our saying P is total) when P is run on input p, then we
get the diagonal contradiction from P : P accepts p ⇐⇒ P rejects p. (ii) What actually
would happen if Q accepted p is that, since “M ” is literally P itself in the third line, P when
run on p would invoke itself on input p in that line. This causes an infinite recursion, which
formally means not halting (in practice it would “segfault” with a stack overflow). But that in
turn contradicts P being total and the given assumption that Q gives no false positives—since
now “Q(p) accepts” is a false positive. Either way, something’s gotta give—you can have the
assumptions of the problem but not with Q accepting p.
(b) Since Q, being total, must reject p by (a), P (p) rejects in that same second line.
(c) If Q accepts q, then P on input q runs Q(q) and gives the opposite answer. That’s fine
because it’s P (q) versus Q(q); it just means that P and Q cannot accept the same language.
In jargon terms, it means “P is diagonal for Q.” Actually it’s the language L(P ) of P that is
diagonal for Q, which takes us into the for-credit problem.
(1) Show that Q cannot accept the code of any program M such that L(M ) = L(P ). (12
pts.)
Answer: Suppose there were such a program M —since we are thinking of a specific one
now we can more helpfully call it P 0 since it is “like P .” Take p0 to stand for the code of
P 0 —then we are supposing that Q accepts p0 and L(P 0 ) = L(P ). We produce a contradiction
as follows: Run P on p0 . Then in the first step it compiles p0 to get a working copy of P 0 and
in the second step Q accepts p0 —which means P 0 is total by the assumption about Q. So the
third step runs to completion. We get:
P accepts p0
⇐⇒
⇐⇒
P 0 rejects p0
P rejects p’
(by third step)
(by L(P 0 ) = L(P )).
This is our old friend (or “fiend”) the diagonal contradiction, which completes the proof.
Remarks: Notice that the contradiction comes about because of the assumption that
languages are equal—so p0 ∈ L(P 0 ) ⇐⇒ p0 ∈ L(P ), so P 0 accepts p0 ⇐⇒ P accepts p0 .
It does not rely on any idea that P 0 must work like P does—assuming the program P 0 must
work like P is another issue of “intension vs. extension.” It comes down to the particular
language—call it just L now—that P accepts. The jargon term here is that L is diagonal for
Q. The language not just the program is diagonal.
The upshot is that Q not only cannot accept the code of P , it cannot accept the code of
any program that recognizes L. This is so even though L is a decidable language—since there
really are cases where programs like Q exist and are practically relevant, and then P really
exists as above and is total. The ulterior motives for this topic are:
• Any formal system F of logic that can analyze computations (technically the bar is
very low: F only needs to express and prove some basic identities of arithmetic and
induction on N) can give you a program verification system Q without false positives.
But then the statements “P is total” and “some total program P 0 accepts L” are true
but unprovable in F . This is a neat way to appreciate Gödel’s Theorem that for
every consistent formal system with implementable proofs there are true statements
that the system cannot prove. This is not on the course syllabus but is important to
the intellectual context of the course.
• When we hit Section 5.5 of the text we will see a diagonalization technique where the
fact that it applies to all programs for a diagonal language is essential. There will be
an extra component that will allow us to “morph” the diagonal language so that it fits
inside a slightly-higher complexity class. If you get this first, that—which is central to
the second-half syllabus—will be easier to follow.
(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 L1 , L2 , L3 of these problems using set notation, and then prove that all
three languages are undecidable. (39 pts. total, for 51 on the set)
Answer: To help visualize, I will use M 0 rather than M for the “dummy variable” in these
sets. (For L1 I could also “dummy” x0 instead of x, but since it’s the same x the visual help
is not so important.) There is nothing wrong with using “M ” for them though.
L1 = {hM 0 , xi : M 0 (x) overwrites a non-blank char by B}
L2 = {e(M 0 ) : for some x, M 0 (x) overwrites a non-blank char by B}
L3 = {e(M 0 ) : for all x, M 0 (x) overwrites a non-blank char by B}
Now to prove that these languages are undecidable, it suffices to reduce the Acceptance
Problem (or essentially equivalently the Halting Problem) to each of them. Given an instance
hM, xi of the APT M problem, we kill all three birds with one stone by defining a particular
Turing machine M 0 that operates as follows:
M 0 : On any input w, M 0 (w) first (writes down x on another tape or next to w on the
input tape, whatever—you don’t need to say this) starts up a simulation of M on input x.
Importantly, the simulation of M (x) operates without ever writing a literal blank—it can
use a special char ‘%’ (that is not used by any TM in the formalized instances of APT M ) as a
“virtual blank.” If and when M accepts x, M 0 (w) then proudly writes a literal blank B over
a non-blank char.
It is easy to stitch a given M and x into the code for M 0 , so the functions f1 (M, x) = hM, xi
and f2 (M, x) = e(M 0 ) are computable. We get this analysis:
hM, xi ∈ APT M
⇐⇒
⇐⇒
⇐⇒
⇐⇒
⇐⇒
⇐⇒
⇐⇒
M accepts x
M 0 (x) overwrites a non-blank char by B
hM 0 , xi ∈ L1
f1 (M, x) ∈ L1
(so APT M ≤m L1 )
0
(∃w)M (w) overwrites a non-blank char by B
e(M 0 ) ∈ L2
f2 (M, x) ∈ L2
(so APT M ≤m L2 ).
Finally, by the logic of the “all-or-nothing-switch,” the same function f2 also many-one
reduces APT M to L3 , because
hM, xi ∈ APT M
⇐⇒
⇐⇒
⇐⇒
⇐⇒
M accepts x
(∃w)M 0 (w) overwrites a non-blank char by B
(∀w)M 0 (w) overwrites a non-blank char by B
f2 (M, x) ∈ L3
(so APT M ≤m L3 ).