Can not understand reduction and turing machine - turing-machines

I am studying on reduction and undecidability, and i can not understand the concept it works.
So how doese M' on input z mean?
I can not understand where the 'z' come from?
Here is my understanding:
When R receive input <M,w>, it generates a <M'>, which M' will just simulate <M> on w.
M' is sth like M'{ run M on w}.
Runinng R on input <M'> will reveal if M' accept empty string or not.
but then here is where i stuck.
How is the outcome of R help reveal M with input w?

Related

Does this proof really prove undecidability of halting?

I want to ask a couple questions about the following proof. The proof originally came from a textbook and then a question on stackoverflow below.
How does this proof, that the halting problem‍​ is undecidable, work?
Question 1:
Does the proof below essentially make H a simulator for its input machine?
In other words, is there an important difference between saying H = M and the following description from the proof?
H([M,w]) = {accept if M accepts w}
= {reject if M does not accept w.}
Question 2:
How is my following comments correct or incorrect?
I thought the halting problem was the problem of deciding if a given machine will halt regardless of its output(accept/reject). If a solution exists for a halting problem, it has to be something that analyses source code like a compiler/decompiler/disassembler instead of actually running it. If it needed to run it, obviously it would never determine on a "no" answer.
Noticing that apparent problem in the proof, the whole proof seems not to show undecidability of the halting problem.
The proof instead seems to show this:
The following algorithm will not halt:
boolean D()
{
return not D();
}
Following is the proof in question retyped from Intro to the Theory of Computation by Sipser.
THE HALTING PROBLEM IS UNDECIDABLE
Now we are ready to prove Theorem 4.11, the undecidability of the language
ATM = {[M,w] | M is a TM and M accepts w}.
PROOF:
We assume that ATM is decidable and obtain a contradiction. Suppose that H is a decider for ATM. On input , where M is a TM and w is a string, H halts and accepts if M accepts w. Furthermore, H halts and rejects if M fails to accept w. In other words, we assume that H is a TM, where
H([M,w]) = {accept if M accepts w}
= {reject if M does not accept w.}
Now we construct a new Turing machine D with H as a subroutine. This new TM calls H to determine what M does when the input to M is its own description . Once D has determined this information, it does the opposite. That is, it rejects if M accepts and accepts if M does not accept. The following is a description of D.
D = "On input [M], where M is a TM:
1. Run H on input [M, [M]].
2. Output the opposite of what H outputs; that is, if H accepts, reject and if H rejects, accept."
Don't be confused by the idea of running a machine on its own description! That is similar to running a program with itself as input, something that does occasionally occer in practice. For example, a compiler is a program that translates other programs. A compiler for the language Pascal may itself be written in Pascal, so running that program on itself would make sense. In summary,
D([M]) = { accept if M does not accept [M]
= { reject if M accepts [M]
What happens when we run D with its own description as input> In that case we get:
D([D]) = {accept if D does not accept [D]
= {reject if D accepts [D]
No matter what D does, it is forces to do the opposite, which is obviously a contradiction. Thus neither TM D nor TM H can exist.
In other words, is there an important difference between saying H = M and the following description from the proof?
The H machine is called Universal Turing Machine (UTM) and is able to simulate any other Turing Machine, including itself.
If M is an Universal Turing Machine like H, it is ok to say H = M, otherwise this would be weird.
I thought the halting problem was the problem of deciding if a given machine will halt regardless of its output(accept/reject). If a solution exists for a halting problem, it has to be something that analyses source code like a compiler/decompiler/disassembler instead of actually running it. If it needed to run it, obviously it would never determine on a "no" answer.
That is why the proof works based on contradiction and it is kind hard to understand.
Basically it assumes first that exists such a machine that answers "yes" or "no" to any given input. [Hypothesis]
Let's call this machine Q.
Assuming Q is valid and it is an UTM, it can simulate another machine S that works following the steps below:
S reads an input (a program and its input)
S duplicates the input it just read
S calls Q passing the copied input
S waits for Q to answer (and based on our hypothesis it always will)
Let's imagine now the input Q(S, S). Q will receive the program S and the argument of S is S itself. This input will make S call Q indefinitely and will never stop.
Since Q and S were legal programs but there is a kind of input that makes Q never stop, Q is a machine impossible to built and therefore it is impossible to decide if a program S stops or not.
Therefore we have the proof that the halting problem is undecidable.
Sipser explains it well. Read it again now and see if you catch the idea :)
Now, on to your question again. The Turing Machine is our most powerful machine for representing problems. As a recognition machine, it has to go through the input and run the algorithm to determine if it is valid or not. It is impossible to know the output of an algorithm without running it.
The compiler is just a translator of syntax and little semantics. It cannot foresee how one will use the program and what the output will be.

Proving a decision is undecidable

I understand that HP is an undecidable problem because of the diagonalization argument.
In my book (kozen) the first example of a reduction to the halting problem is a machine that can decide whether or not the empty string ε is accepted.
from my book:
Suppose we could decide whether e. given machine a.ccepts E. We could then
decide the halting problem as folIows. Say we are given a Turing machine
M and string x, and we wish to determine whether M halts on X. Construct
from M and x a new machine M' that does the following on input y:
(i) erases its input y;
(ii) writes x on its tape (M' has x hard-wired in its finite control);
(iii) runs M on input x (M' also has a description of M hard-wired in its
finite control);
(iv) accepts if M halts on X.
Here already, numerous questions come to my mind. M' is not based (as far as the text tells at least) on the actual machine that decides whether ε is accepted or not.
Why do we erase the input y? Is x in M' arbitrary? And the biggest confusion comes from my question: Why can't I prove any decision problem this way: Make a machine M' that erases its input, writes x on the tape, runs M on the input x and accepts if M halts on x?
I'm trying to understand the relation between the decider for a machine to accept ε and the TM given by the book, but I can't seem to understand it, neither can my fellow students.
Erasing the input is just to show that it is irrelevant. You could as well leave it there and write behind it.
x in M' is not arbitrary but "M' has x hard-wired in its finite control" for deciding the problem "given a Turing machine M and string x, and we wish to determine whether M halts on x."
The new machine always does the same independent of its input. Therefore, it either accepts ALL inputs or NONE. So it accepts the empty string IFF M accepts x. It is important to note that we are talking about only one computation of M but all the computations of M'.

Coq eapply generates a goal with a question mark while proving existence of a function

I would like to prove that for every group there exists a minus function that takes an element of the group and returns its negative.
My Coq code is as follows:
Record Group:Type := {
G:Set;
plus: G->G->G;
O:G;
assoc: forall x y z:G, plus x (plus y z)=plus (plus x y) z;
neut: forall x:G, plus x O=x /\ plus O x=x;
neg: forall x:G, exists y:G, plus x y=O
}.
Lemma minus_exists(H:Group):exists minus_func:G H->G H, (forall x:G H, plus H x (minus_func(x))=O H).
eapply ex_intro.
The last tactic generates the following output:
H : Group
============================
forall x : G H, plus H x (?12 x) = O H
My first issue is the ?12 which I figure is probably a badly displayed character. What is the meaning of this and is there a way to make it readable.
My second question is how to complete the proof, which might become clearer after the first question is answered.
In my Coq version, I get instead:
forall x : G H, plus H x (?minus_func x) = O H
which is slightly better. In Coq, a term displayed of the form ?T is what we call a "meta" or an "existential variable" (evar).
The terminology comes from the field of logic programming and automated theorem proving, and it could be roughly interpreted as representing "an unknown term". Usually, evars play the role of variables in the unification process. The whole Coq proof engine is built around this notion of unknown or evar.
In your case, eapply ex_intro (or eexists) is missing the witness. Coq will create a new "evar" to stand for the missing function, and allows you to continue your proof. Note however that in order to complete the proof, you will need to provide a witness later on.
How are evars made into actual terms? The act of replacing an evar by an actual term is known as "instantiation". In many cases, instantiation will be performed by the unification algorithm. For instance, if we had a lemma:
Lemma f_plus x : plus H x (f x) = O H
we could do apply f_plus and ?minus_func would be replaced by f. Another way is to use the instantiate tactic, but it is obsolete these days. In our previous case, you could then write instantiate (1 := f) and that would replace ?minus_func by f. Due to technical reasons this approach is not well supported anymore, thus in practice you are bound to either instantiating evars by unification or providing the actual witness to tactics.
I suggest you read a bit more about unification and logic programming.
?12 is not a badly displayed character, it is a hole. The eapply tactics is a kind of "apply this lemma/hypothesis, but I don't have all the input at hand yet, so please insert holes instead, that I will fill later".
By entering eapply ex_intro (or eexists) you are just saying "There exists a function which I don't know yet, so please replace it by a hole, I will provide it later". However since the whole purpose of your lemma is to build this function, I'm not sure you are on the right path. Try proving your lemmas without any efoo tactics, you don't need them.

How to know if a Turing Machine is a decider?

Is there an easy way to approach this? Can I find if it is a decider by looking at the diagram of the Turing Machine?
A decider is a machine that halts on all inputs. There is no general way to prove whether a given machine halts on all inputs.
If you have a specific machine, you can try to formally prove that all paths of execution halt. For example, if your machine's read head always moves right on each transition (never left), and halts when there is no more input, then for all finite inputs the machine will halt. A simpler example would be a machine that has only one state: halt.
TM decides language L iff
1- the strings L put M into the Accept state
2- the strings NOT IN L put M into the Reject state
TM M recognizes language L iff
1- the strings L put M into the Accept state
2- the strings NOT IN L
- EITHER put M into the Reject state
- OR cause M to loop
#Wanhui Qiao
you are saying "TM changes between two states and both states are neither accepting nor rejecting states, is this Turing decidable?"
then it is definitely going infinitely i.e it is going into loop which is Turing recognizable.
You can prove in general that
DECIDER_tm = { <M> : TM M is a decider } is undecidable.
Prove by contradiction. Assume it is decidable and let R be a decider for DECIDER_tm.
Construct S decider for HALT_tm using R as a subroutine .
S = on input <M,w>
1. construct M_w = " on input x"
run M on w
if M accepts accept. if M rejects reject.
2. Run R on M_w
3. If R accept => accept, if R rejects => reject.
Note that if M accepts or rejects w, M_w halts on all input, R accepts since M_w is a decider. If M loops on w, M_w loops on all input, R rejects M_w.
We have built a decider for HALT_tm since we know HALT_tm is undecidable our assumption was wrong => DECIDER_tm is undecidable.

proving if a Turnig machine accept a string is undecidable

I have seen the proof of
ATM = {〈M,w〉 | M is a TM and M accepts w} is undecidable.
initially we build another Turing machine
H with input <M,w> it accept if M accept w otherwise reject
then we make another Turing machine
D which on input <M>
1.run H on <M,<M>>
2.output the opposite of what H outputs.
That is if H accepts reject and if H reject accept
I dont understand how is it possible that a Turing machine as input gets its own description and then reject it! Can you please explain it?
I'm not sure where exacltly you got stuck, so I'll more or less try to reiterate your question, hopefully filling any gaps.
The idea is, that we want to show that ATM is undecidable, i.e. that there is no TM H, that when given any another TM M and any other input w to this TM M as input can decide if the TM M will accept input w.
To show that such a TM H doesn't exist we make the ASSUMPTION such a machine H exists.
Which at least with enough phantasy might not seem to be a much too unreasonable guess.
The next Idea is to just by deducing the consequences the existence of such a TM H would have lead our argumentation the to a contradiction. Thus proving that our initial assumption such a TM H might exist must be wrong. Meaning there doesn't exist any TM H following our specification given above.
So now on to the tricky part: As we assumed there exists a TM H that when given ANY TM M and ANY input w to this TM M as input can decide wether M will accept w nobody can forbid us to just feed a description of the machine M itself als input w into M itself.
We even made the assumption we might use ANY input.
As you already stated above the idea of feeding any machine as input into another doesn't seem to bee too easy to accomplish, we will rather try to encode the description of the second TM on our first TM's tape.
At a first glance it might not seem to clear if it is really possible to be able to encode any TM on the tape, but in fact it is possible. One of the possible schemes to accomplish this goes by the name of Gödelisierung named after the mathematician Kurt Gödel.
The encoding itself is also often refered to as Gödelnumber.
Given our TM H that when given the description of ANY TM M and ANY input w to M as input decides wether M will accept w, using our freedom already mentioned above we will simply use TM M's description as input to itself.
Thus constructing a TM H' that when given any description of a TM M as input will decide if TM M working on its own description as input will accept or not.
As you hopefully see starting from our assumption a TM H as specified above we haven't done any "forbidden" move and we surely won't do, if we use our newly constructed TM H' to construct a TM D that when given ANY TM M as input wil just return the opposite output than our machine H'.
This new TM D, when given the description of ANY TM M as input will accept > if the M doesn't accept its own description as input and reject > if the TM M accepts its own description as input.
As you can see we still have the freedom to feed any (description of a) TM M as input into D, so happily using our freedom once again nobody can ever forbid to use the description of the TM D itself as input.
According to our construction D works on ANY TM M as input, so it surely has to be able to work on itself.
But exactly here comes the twist. As a matter of fact to determine the outcome ouf our run of D on its own description as input we just have to possibilities: D will either accept or reject.
Now let's examine both cases:
In case D accepts it's own description as input by our construction this would mean D would have to reject and vice versa. Remember it was the TM H' that acceptet ANY TM that accepted it's own description as input and we just inverted it in our construction.
Thus leading us to the odd fact that D would have to reject its own description as input if and only if it accepted it.
As this obviously can't be posssible you have to find the root of the error we made in our construction. Following the whole path we made up again this leads us our initial deduction that there was a TM H able to decide for ANY TM M and ANY input w if M will accept w, which was implied by our assumption that ATM was decidable.
The input to a machine has no special status, and doesn't impose any requirements. A machine is free to reject itself. :)
Cause i don't feel like building a Turing machine, here's an oversimplified example in Java (which is close enough to Turing completeness that it serves to illustrate):
class SelfReject {
public boolean equals(Object other) {
...
}
public boolean accepts(Object input) {
return (!this.equals(input));
}
}
An object of this type would accept any input but an object equal to itself.

Resources