I am new to decidability. I read halting problem of halting problem but didn't get anything what it is actually implying. I am already screwed up with the explaination.
Can anyone provide me any sound explaination or atleast some details, it would be of much help ?
You can think of a Turing machine as a sort of theoretical computer that can execute programs. A program for a Turing machine consists of a set of states and transitions between these states. Programs running on Turing machines have access to a single input source, called the tape, which has some string (possibly empty) the program can process. All programs for Turing machines either return true (halt-accept), return false (halt-reject), or fail to ever return anything at all - while (true) ; return true;. Depending on your definition it may also be possible for the machine to throw an exception (crash); but typically crashing is thought of as something like try { /*crash*/ } catch (Exception) { return false; } so that crashing means halt-reject.
The halting problem, then, is whether you can write a program for a Turing machine, whose input is another program for a Turing machine and some string of input, which returns true or false (halt-accepts or halt-rejects) if the program it has been given halts on the input provided and returns false otherwise (i.e., if the program never halts).
It turns out the answer is that no such general program exists for Turing machines. Suppose one did exist, M. Given inputs m and i it accepts if m halts on i and rejects otherwise. We can make another program specifically designed to fool M:
N(i)
1. if M(N, i) then loop forever;
2. otherwise return true
Now continue whether M works on N:
Suppose M says that N halts on input i. Then N will loop forever, and M will have been wrong.
Suppose M says that N loops forever on input i. Then N will return true and halt, so M will have been wrong.
In either case, M comes up with the wrong answer for our N, and since we made no assumptions about M other than that it exists and solves the halting problem, we may safely conclude that no machine that solves the halting problem exists.
(M may be passed into the program N as input if it is preferred not to reference M directly).
Related
We know that the problem “Does this Turing machine take at least this finite number of steps on that input?” is decidable, because it will always answer yes or no, where it will say yes if the machine reaches the given number of steps and no if it halts before that.
Now here is my doubt: if it halts before reaching those many steps — i.e. the input either (1) got accepted or (2) got rejected or maybe (3)if it doesn’t halt but rather goes into an infinite loop — then, when we are in case (3), how can we be sure that it will always be in that loop?
What I mean to say is that if it doesn't run forever but comes out of the loop at some point of time then it might cross the asked number of steps and the decision can be made now which was earlier not possible. If so, then how can we conclude that it's decidable when we know that being stuck in a loop we won’t be able to say anything about the outcome?
(I already more or less answered your question when I edited it.)
The thing is, the decision system (a Turing machine, an algorithm or any other equivalent formalism) that takes as inputs a Turing machine M, a number N and a value X, and returns yes or no, has total control over how it executes M on X. It simulates it step by step. So it can run one step of M(X), increment an instruction counter, compare it to N and, as soon as the given number of steps is reached, it stops and returns yes. At that point, there is no need that the simulated machine M be in a final state, and actually the full computation M(X) could very well diverge. We don’t care, because we only run the first N steps.
Most likely the "conditional structures where not being debuged/developed enough so that multiple conditions often conflicted each other..the error reporting where not as definitive, so it where used semi abstract notions as "decidable" and "undecidable"
as a semi example i writen years ago in vbs a "64 bit rom memory" simulator, as i tried to manage the memory cells, where i/o read/write locations where atributed , using manny formulas and conditions to set conversions from decimal to binary and all the operations, indexing, etc.
I had allso run into bugs becouse that the conditons where not perfect.Why? becouse the program had some unresolved somewhat arbitrary results that could had ended up in :
print.debug "decidable"
On Error Resume h
h:
print.debug "undecidable"
this was a example with a clear scope and with a debatable result.
to resume to your question : > "so how do we conclude that it's decidable??"
wikipedia :
The Turing machine was invented in 1936 by Alan Turing, who called it an "a-machine" (automatic machine). With this model, Turing was able to answer two questions in the negative:
Does a machine exist that can determine whether any arbitrary machine on its tape is "circular" (e.g., freezes, or fails to continue its computational task)?
Does a machine exist that can determine whether any arbitrary machine on its tape ever prints a given symbol?
Thus by providing a mathematical description of a very simple device capable of arbitrary computations, he was able to prove properties of computation in general—and in particular, the uncomputability of the ('decision problem').
I recently came across the halting problem contradiction proof.
In the proof, we have to feed the Turing machine a copy of the program and a copy of the input to decide whether that program halts on the input. In the contradiction, why does it have to be the program as the program and the input? Sorry if it sounds confusing. I can simply feed the machine with a program and a random input and come to the same conclusion.
Can anyone tell me why? Is there a specific reason I didn't think of?
First let me come back on the proof itself.
HALT_TM is undecidable
Assume that any machine has a description which takes the form of a string. Let HALT_TM = {<M, w>| M is a TM and M halts on input w}, and A_TM = {<M,w>| M is a TM and accepts w}. Here I assume that we know that A_TM is undecidable (the proof can be done by diagonalization and realizing that as there are more languages than Turing Machines, and as a given TM only decide one language, then some language are not decided).
Assume by contradiction that HALT_TM is decidable, meaning that we dispose of a decider D for this language. Then we would be able to build a machine M which decides A_TM. On input <M', w>, M does the following:
Run D on input <M',w>
If D reject, reject, otherwise run M' on w (until it halts, which we know because D did not reject!)
If M' accepts, accept, if it rejects, reject.
There we see the contradiction with our assumption
Universal Turing Machines
Now the core of your question: you actually feed M any valid machine description M', not necessarily <M> itself. Remember that a TM and "a program" are actually equivalent: See this nice answer for more details. Quoting this same answer: "A Turing Machine is the formal analogue of an algorithm".
One power of Turing Machines is that they can be encoded as a string, allowing another Turing Machine (called an "Universal Turing Machine") to execute them. Because the given machine is an algorithm, you see that you are actually feeding your "top-level" TM a program, and a input of your choice.
The halting problem states that given an input and a program, there is no
algorithm that can decide weather the program will halt. This renders this problem undecidable.
My misunderstanding of the halting problem is that, can't we
just create another program that could check if the program has
infinite loops. I just mean that it may be possible to check the cases
where a loop will not stop and based on that decides if the program will halt
or not. Please could you let me know what's wrong of my understanding of this problem?
Well, you know, the proof of the halting problem is pretty trivial.
Let's assume you have a program that tells you whether a given program will halt or not (forget about inputs for simplicity). Let's call this program doesHalt(program).
Let's now write a new program called
myHalt()
if doesHalt(myHalt):
infinite loop
else
return
What should be the return value of
doesHalt(myHalt)
To answer your specific question: how does your program examining loops will know whether a given loop halt or not?
Does the loop
for (i = 1; i += 10; ) {
if (i == 7) break;
}
loop forever or not? How did your program figure that out?
Only language i cant think of, that does not belong in RE class is diagonal language, but unfortunately its complementary language is recursively enumerable. Does anyone have any ideas?
Consider the following set: all machines which fail to halt on some input. In other words, all machines M for which there exists an input X such that M does not halt on input X. This is not recursively enumerable, since there's no algorithmic way to determine that a given machine fails to halt on a given input. I mean, how would you do it? Simulate the machine running on the input? For how long?
The complement of this set is the following: all machines which halt on all inputs. In other words, all machines M which always halt on any input X. This is not recursively enumerable either, since there's no algorithmic way to determine that a given machine halts on all possible inputs. How would you do it? Check them all?
I'm going over the proof for The Halting Problem in Intro to the Theory of Computation by Sipser and my main concern is about the proof below:
If TM M doesn't know when it's looping (it can't accept or reject which is why a TM is Turing Recognizable for all strings), then how would could the decider H decide if M could possibly be in a loop? The same problem will carry through when TM D does its processing.
After reading this and trying to visualize the proof I came up with this code which is a simplified version of the code in this answer to a related question:
function halts(func) {
// Insert code here that returns "true" if "func" halts and "false" otherwise.
}
function deceiver() {
if(halts(deceiver))
while(true) { }
}
If halts(deceiver) returns true, deceiver will run forever, and if it returns false, deceiver will halt, which contradicts the definition of halts. Hence, the function halts is impossible.
This is a "proof by contradiction", a reductio ad absurdum. (Latin phrases are always good in theory classes... as long as they make sense, of course.)
This program H is just a program with two inputs: a string representing a program for some machine, and an input. For purposes of the proof, you simply assume the program H is correct: it simply will halt and accept if M accepts with w. You don't need to think about how it would do that; in fact, we're about to prove it can't, that no such program H can exist, ...
BECAUSE
if such a program existed, we could immediately construct another program H' that H couldn't decide. But, by the assumption, there is no such program: H can decide everything. So, we're forced to conclude that no program defined as we defined H is possible.
By the way, the reductio method of proof is more controversial than you might expect, considering how often its used, especially in Computer Science. You shouldn't be embarrassed to find it a little odd. The magic term is "non-constructive" and if you feel really ambitious, ask one of your professors about Errett Bishop's critique of non-constructive mathematics.