## How to know if a Turing Machine is a decider? - turing-machines

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.

## Related

### 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'.

### Why decider D behaves the opposite when it is using decider H as a subroutine?

Acoordind to paragraph shown, how decider D uses H as a subroutine and how it is behaving the opposite ? It would be very useful if someone clarify this ?

Turing machine is said to accept the input, if it ends in the accepting state(s) given that input. It rejects, if it ends in any other state. So, if we have a machine H that takes input <M, <M>>, we then can enhance it, by adding new starting point, taking as input <M>, constructing <M, <M>> and then feeding this to the rest of the H. This new machine H* will be same as H, but with different input. If we now switch accepting and rejecting states we will have machine, that takes as input <M> and returns result opposite to H, which coinsidentally is D.

### Prove that it is undecidable whether a Deterministic LBA accepts an infinite number of inputs

Deterministic Linear Bounded Automaton (LBA) is a single-tape TM that is not allowed to move its head past the right end of the input (but it can read and write on the portion of the tape that originally contained the input). How can I prove that it is undecidable whether a Deterministic LBA M accepts an infinite number of inputs?

Given a Turing machine M and a string w, you can show that the following language is accepted by some LBA: L = { x#y | x is a computation trace of M accepting w and y is any string } Intuitively, this can be checked by an LBA by having it do the following: Reject if x is not syntactically correct. Reject if x doesn't start off in a correct initial configuration. Reject if any step of the computation trace is incorrect. Reject if x is a trace showing M rejects w. Otherwise accept It's possible for a TM to construct a description of the LBA that does this. If M accepts w, then this language is infinite and so the LBA will accept infinitely many inputs. If M does not accept w, then this language is empty. Therefore, if a TM could decide whether the LBA had an infinite language, it could decide whether M accepts w, contradicting that this is impossible. Hope this helps!

### 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.

### 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.