Section 3.1: Proof Strategy Now that we have a fair amount of experience with proofs, we will start to prove more difficult theorems. Our experience so far has been with theorems that require us only to apply the definitions and fit them together to reach the desired conclusion. Such proofs are definitional in nature and require little extra insight into the problem. Some of the more interesting theorems that we turn to now will require a bit more insight and often some less obvious way of combining our hypotheses to reach the desired conclusions. In the text, many of the tricks and general techniques that we will apply to prove more complicated theorems are discussed. I will point out such techniques during the course of proofs but discuss them less.

Ex: Consider a game played between two people. At the beginning of the game, there is a pile of 9 stones. The players take turns removing stones from the pile. On each turn a player can remove 1, 2, or 3 stones from the pile. The player who takes the last of the stones from the pile wins. Prove that the first player can always win this game. Proof: For the first player to win, he must be left with 1, 2, or 3 stones in the pile on one of his turns (then he would just grab the rest of them). He could achieve this by leaving his opponent with 4 stones in the pile. To be able to leave his opponent with 4 stones in the pile, the first player needs to be left with 5, 6, or 7 stones when his turn comes. He could force his opponent to leave him with 5, 6, or 7 stones if he leaves his opponent with 8 stones to choose from. To leave his opponent with 8 stones to choose from, the first player simply takes 1 stone on his first move of the game. So the first player can always win by following the strategy: take 1 stone, take enough to get down to 4, then take the remaining stones. 

Ex: What if the person who takes the last stone loses? Follow the same sort of reasoning. What we did in the last proof is called backward reasoning. Instead of starting at the beginning and moving forward to our goal, we started with the goal and moved backward to see how to derive it. Let’s use the same strategy. For a player to win, he must leave his opponent with 1 stone in the pile. To be able to leave his opponent with 1 stone in the pile, the player needs to be left with 2, 3, or 4 stones when his turn comes. He could force his opponent to leave him with 2, 3, or 4 stones if he leaves his opponent with 5 stones to choose from. To be able to leave his opponent with 5 stones to choose from, the player needs to be left with 6, 7, or 8 stones when his turn comes. But the first players move will leave the second player with 6, 7, or 8 stones to choose from. So in this case the second player has a winning strategy: After player 1 moves, take enough stones to get down to 5, then take all but the last stone.

Ex: Prove that n 3 - n is divisible by 3 for all integers n. Proof: Let n be an integer. Consider n 3 - n = n(n 2 - 1) = n(n - 1)(n + 1). Now n - 1, n, and n + 1 are three consecutive integers. If we could show that 3 divides one of these integers then we can conclude that 3 divides n 3 - n (because it is a multiple of each of these integers). So what we really want to prove is that 3 divides at least one of any three consecutive integers. Then 3 | n 3 - n is just a corollary of this. Lemma: Let n be an integer. Then 3 divides n - 1, n, or n + 1. Proof: Let n be an integer. Then by the FTOA when n is divided by 3 it leaves a remainder of 0, 1 or 2. Case 1: If n leaves a remainder of 0 when divided by 3, then 3 | n. Case 2: If n leaves a remainder of 1 when divided by 3, then n = 3q + 1 for some integer q. So n + 2 = 3q + 3 = 3(q + 1). So 3 | n + 2. Case 3: If n leaves a remainder of 2 when divided by 3, then n = 3r + 2 for some integer r. So n + 1 = 3r + 3 = 3(r + 1). So 3 | n + 1. 

The Halting Problem int factorial(int n) { int result = 1; for( int i = n; i != 0; i-- ) result = result * i; return result; } factorial(0) = 1 = 0!factorial(1) = 1 = 1!factorial(2) = 2 = 2! factorial(3) = 6 = 3!factorial(4) = 24 = 4!factorial(5) = 120 = 5! factorial(-1) = ???

It would be nice if we had a function bool Halts( program P, input I ); such that when we call this function Halts giving it a program P and an input to the program I, the function will return true if program P would halt when run with input I and will return false if program P would enter an infinite loop and never halt when run with input I. The question immediately arises, “Will the program Halt always terminate?”. Well, clearly, for Halt to be useful to us, we must be ensured that no matter what input we give to Halt (program and input for the program), Halt is always guaranteed to halt and give us an answer. That is, part of the design criteria for Halt is that it would never enter an infinite loop. Surely we would also like to impose some time constraint on Halt such as it can only take up to 10 minutes, but before we even consider this further improvement, we can rule out the possibility of Halt altogether.

Theorem (The Halting Problem): There does not exist a program which given an arbitrary program P and arbitrary input to the program I, will always halt and tell you correctly whether program P would halt or not when run with input I. First let’s consider the obvious attempt at Halt. What if we just had Halt simulate program P when run with input I. That is, all Halt does is to run the program you give it on the input you give it and then tell you the results of whether P terminated when run with input I. This implementation of Halt violates the criterion that Halt must always terminate. Surely if you give Halt a program and input that will terminate then Halt will finish simulating the program and tell you true. But if the input to Halt is a program and input that would not ever terminate, then Halt will never finish simulating the program. We don’t have the machinery to formally prove the halting problem, but we can discuss the proof in informal terms.

Let’s assume to the contrary that there does exist a program H(P, I) which solves the halting problem. (We will derive a contradiction). Then H(P, I) takes two inputs, P which is a program, and I which is an input to the program. And H always halts in a finite amount of time and tells us whether the program P when run with input I would have halted or not. Consider that a program P is simply the text of the source code. And the input to a program is also simply some text. Since the input is arbitrary, we could consider what a program P would do when we give it as input its own source code P. That is, what happens when we make the call H(P, P) for a program P. We are asking whether the program P halts when given its own source code as input. Since we have assumed the existence of the procedure H(P, I) we can use it as a subprocedure whenever we wish. Let us construct a new procedure K which will take advantage of the existence of H.

We construct the procedure K(P) which takes a program as input. K(P) works as follows: bool K(program P) { bool result = H(P, P);// run H with program P given input P if( result == false )// if P would loop forever on input P return true;// then K halts else// if P would halt on input P while(1){};// then K loops forever } So K(P) calls H(P, P) to see what P would do when given its own source code as input. Then K(P) does the opposite of what H(P, P) said P would do on its own input. K(P) loops forever if P would halt.

Now we ask the (extremely convoluted) question: “Would K halt if it were run with its own source as input?” That is, we what would happen if we run H(K, K)? There are two possibilities, K would halt when given input K or not. Case 1: What if the truth of the matter is that K would indeed halt when run with its own source code as input. That is K(K) halts. Then since H(K, K) always tells us the truth about whether K would halt given input K, then we would expect H(K, K) to tell us true. But if H(K, K) tells us true, then by the definition of procedure K, K(K) would loop forever. That is, when we run K with its own source as input it would not halt! This is a contradiction because we were considering the case that K halted when run with its own source as input. So Case 1 cannot be!

Case 2: We are left with the alternative that the truth of the matter is that K would loop forever when run with its own source code as input. That is K(K) does not halt. Then since H(K, K) always tells us the truth about whether K would halt given input K, then we would expect H(K, K) to tell us false. But if H(K, K) tells us false, then by the definition of procedure K, K(K) would halt. That is, when we run K with its own source as input it would halt! This is a contradiction because we were considering the case that K looped forever when run with its own source as input. So Case 2 cannot be! So in either case we run into a contradiction. K does not halt when run with its own source as input, nor does K loop forever. But it must do one of the two. So we conclude that K can not exist. But K was a perfectly legitimate procedure that only used procedure H. So the conclusion must be that H can’t exist. That is, we could never construct a procedure that solves the halting problem because the very existence of H allows us to construct a procedure K which can’t exist.