patternMajor
Proof of the undecidability of the Halting Problem
Viewed 0 times
problemtheundecidabilityhaltingproof
Problem
I'm having trouble understanding the proof of the undecidability of the Halting Problem.
If $H(a,b)$ returns whether or not the program $a$ halts on input $b$, why do we have to pass the code of $P$ for both $a$ and $b$?
Why can't we feed $H()$ with $P$ and some arbitrary input, say, $x$?
If $H(a,b)$ returns whether or not the program $a$ halts on input $b$, why do we have to pass the code of $P$ for both $a$ and $b$?
Why can't we feed $H()$ with $P$ and some arbitrary input, say, $x$?
Solution
Ignore the picture for a moment; we'll get to it shortly. The program $H(a, b)$ is supposed to be a halt tester: when we give $H$ an input of a program $a$ (think of $a$ as the listing of a program) and anything at all for $b$, $H(a, b)$ acts as follows
The argument that $H$ is impossible to build relies on the action of a particular "perverse" program, $P$, one which uses $H$ as a subroutine. $P$ takes as its input a listing of any program, $x$, and does the following:
It's not hard to see that
$P(x)$ will halt if and only if the program $x$ will run forever when given its own description as an input.
So far so good: $P$ will certainly be a program as long as its subroutine $H$ is a program.
Now return to the picture. What happens if $P$ is given its own description as input? The picture describes just that scenario: Let $p$ be the description of program $P$, then, substituting into the highlighted part above, we'll have
$P(p)$ will halt if and only if the program $P(p)$ will run forever.
Clearly, this paradoxical behavior is impossible, so we're forced to the conclusion that the subroutine $H$ cannot be a halt tester, since it fails in the one case, where it's given $(p, p)$ as input. There might be other cases where $H$ works as it should, but since $H$ fails in at least one situation, it cannot be a complete halt tester, as required.
- If the program represented by $a$ halts when given $b$ as input, $H(a, b)$ will answer "yes". On the other hand, if the program described by $a$ runs forever when given input $b$ then $H(a, b)$ will answer "no".
- Importantly, program $H$ will always halt and give the correct answer for any pairs $(a, b)$.
The argument that $H$ is impossible to build relies on the action of a particular "perverse" program, $P$, one which uses $H$ as a subroutine. $P$ takes as its input a listing of any program, $x$, and does the following:
P(x) =
run H(x, x)
if H(x, x) answers "yes"
loop forever
else
haltIt's not hard to see that
$P(x)$ will halt if and only if the program $x$ will run forever when given its own description as an input.
So far so good: $P$ will certainly be a program as long as its subroutine $H$ is a program.
Now return to the picture. What happens if $P$ is given its own description as input? The picture describes just that scenario: Let $p$ be the description of program $P$, then, substituting into the highlighted part above, we'll have
$P(p)$ will halt if and only if the program $P(p)$ will run forever.
Clearly, this paradoxical behavior is impossible, so we're forced to the conclusion that the subroutine $H$ cannot be a halt tester, since it fails in the one case, where it's given $(p, p)$ as input. There might be other cases where $H$ works as it should, but since $H$ fails in at least one situation, it cannot be a complete halt tester, as required.
Code Snippets
P(x) =
run H(x, x)
if H(x, x) answers "yes"
loop forever
else
haltContext
StackExchange Computer Science Q#65401, answer score: 44
Revisions (0)
No revisions yet.