## Turing Machine Configuration - turing-machines

I'm fairly new to Turing Machines and I'm stumped on a question. I'm given a Turing machine: M = (Q,Σ,Γ,δ,q) such that Q={q,r,s,t}, Σ={a.b.c}, Γ={B,a,b,c} and δ is defined by the following: [q,a,r,b,R], [q,b,r,a,R], q,c,t,c,R], [t,a,t,a,R], [t,b,t,b,R], [t,B,s,B,R]
And I'm asked if M halts on the input abba, and if so write the configuration in which M halts. The answer is suppose to be brbba, which I don't understand how this can be the configuration. How does a state symbol become apart of the configuration? Any help will be appreciated!

A configuration consists of:
the current state
the position of the read/write head
the tape content
brbba indicates all three as the r shows the current state and the head's position. A less compact way to write it in two lines would be:
r
bbba
or b[rb]ba if you like.

## Related

### Why is this an invalid Turing machine?

Whilst doing exam revision I am having trouble answering the following question from the book, "An Introduction to the Theory of Computation" by Sipser. Unfortunately there's no solution to this question in the book. Explain why the following is not a legitimate Turing machine. M = { The input is a polynomial p over variables x1, ..., xn Try all possible settings of x1, ..., xn to integer values Evaluate p on all of these settings If any of these settings evaluates to 0, accept; otherwise reject. } This is driving me crazy! I suspect it is because the set of integers is infinite? Does this somehow exceed the alphabet's allowable size?

Although this is quite an informal way of describing a Turing machine, I'd say the problem is one of the following: otherwise reject - i agree with Welbog on that. Since you have a countably infinite set of possible settings, the machine can never know whether a setting on which it evaluates to 0 is still to come, and will loop forever if it doesn't find any - only when such a setting is encountered, the machine may stop. That last statement is useless and will never be true, unless of course you limit the machine to a finite set of integers. The code order: I would read this pseudocode as "first write all possible settings down, then evaluate p on each one" and there's your problem: Again, by having an infinite set of possible settings, not even the first part will ever terminate, because there never is a last setting to write down and continue with the next step. In this case, not even can the machine never say "there is no 0 setting", but it can never even start evaluating to find one. This, too, would be solved by limiting the integer set. Anyway, i don't think the problem is the alphabet's size. You wouldn't use an infinite alphabet since your integers can be written in decimal / binary / etc, and those only use a (very) finite alphabet.

I'm a bit rusty on turing machines, but I believe your reasoning is correct, ie the set of integers is infinite therefore you cannot compute them all. I am not sure how to prove this theoretically though. However, the easiest way to get your head around Turing machines is to remember "Anything a real computer can compute, a Turing machine can also compute.". So, if you can write a program that given a polynomial can solve your 3 questions, you will be able to find a Turing machine which can also do it.

I think the problem is with the very last part: otherwise reject. According to countable set basics, any vector space over a countable set is countable itself. In your case, you have a vector space over the integers of size n, which is countable. So your set of integers is countable and therefore it is possible to try every combination of them. (That is to say without missing any combination.) Also, computing the result of p on a given set of inputs is also possible. And entering an accepting state when p evaluates to 0 is also possible. However, since there is an infinite number of input vectors, you can never reject the input. Therefore no Turing machine can follow all of the rules defined in the question. Without that last rule, it is possible.

### Turing machine that erase its input

I have got this question : Consider a Turing machine Cw which erases its input, writes w on the tape, and halts while scanning the leftmost character of w. Design the Turing machine C011 I need explanation what is actual the question is and what Cw does. I kind of understand it writes empty symbol on every input it gets but the rest is unclear to me. Hope someone can help me understand the question and what is required me to do.

In your case w = 011. Indeed, the TM should first overwrite the entire input. I think we can assume that the input does not have gaps. So as soon as the TM reads an empty space on the input tape, it should begin writing 011. When writing the second 1, enter into a state for which there do not exist any transitions. This way you ensure that the machine halts on that position. Nothing is said explicitely about whether this state should be accepting, but it would make sense to have it as the unique accepting state.

### How to prove a Turing Machine property is trivial [closed]

Imagine I have a Turing Machine Property that looks like this: P = {M | L(M) is accepted by a Turing machine that does not halt in an even number of steps for any input} How can I prove that this property is trivial? Or, more generally, are there good ways to prove this sort of thing?

As a hint: you can make any TM always halt within an odd number of steps by making two copies of the states - an "odd" copy and an "even" copy - and toggling back and forth between them when transitions occur. Once you've done this, how would you modify this machine so that it never halts in an even number of steps? Given that this construction works for any arbitrary TM, do you see why the above property is trivial? Hope this helps!

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

### Turing machine diagram for enumerator

I am supposed to draw an enumerator for the language 0^k1^k (k>=0). I am not sure how that is different from building a Turing machine state diagram for this language: the way I understand it is that I need to build an enumerator that recognizes the aforementioned language given all strings above {0,1} by simulating the Turing machine that recognizes this language on string i for i steps, which I couldn't think how to do using a state diagram, but my teacher has pointed out that this is how we prove the equivalence between an enumerator and a Turing machine, so I thought that what we have to do is use the transition function defined for enumerators which makes the diagram look similar to the Turing machine that recognizes 0^k1^k, only instead of moving to qaccept we move to qprint for inputs in the language, and then for inputs that must be rejected we print epsilon? But how do we go about producing an infinite number of strings above the alphabet {0,1}? At the initial state the work tape and the print tape are empty. Can someone clarify these points for me? Maybe I misunderstand.

I think I finally have the enumerator notion clear, an enumerator is not supposed to read an input, it creates words in the language for which it is built: here's the algorithm: print epsilon on the output tape write 01 on the work tape go back to the front of the tape and copy its contents to the output tape go back to the leftmost 0, replace it with 1, go to the rightmost 1 and add two 1's at the end. go back to stage 3

i thought of another slightly different algorithm that produces a smaller number of states, and uses only {0,blank} on its work tape:

i think you might have an error there. in stage 4, you wrote "go back to the leftmost 0, replace it with 1, go to the rightmost 1 and add two 1's at the end" i think it should be: "go back to the leftmost 1, replace it with 0, go to the rightmost 1 and add two 1's at the end"