Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I am trying to understand why is it impossible to write a program H that can check whether another program P on a specific input I will halt or not (Halting problem), but i am unable to get a clear idea of it.
Though intuition says that if this program H tries to run a program P which is not going to halt, then H itself will go into a loop. But i dont think this is the idea behind the proof.
Can anybody explain the proof in simple layman terms?
The idea behind the proof is by contradiction.
Assume there is a Halting Problem Machine M that solves the Halting problem, and yields 0 if some input program won't finish, and 1 if it will. M is guaranteed to finish.
Create a new machine H.
H runs M with the input of H (itself), and if M answers 1 - get into endless loop, otherwise - stop.
Now, what will happen if you run M on input H?
If the answer is 1 - than it is wrong, since H runs M, and will get to infinite loop.
If the answer is 0 - it is also wrong, since H will stop.
So, it is contradicting the assumption that M is correct - and thus there is no such M.
Intuitively - it is like saying there is no such thing as an oracle, because if "you" tell me you're an oracle, I ask you - which arm am I going to raise?
Then, I will wait for your answer - and do the opposite - which contradicts the claim that the oracle is indeed an oracle.
Turing used proof by contradiction for this (aka reduction to absurdity):
The idea is to assume there is actually such a machine H that given any program p and an input i will tell us weather p stops.
Given such H, we can modify it and create a new machine.
We'll add another part after H's output such that if H outputs yes, our machine will loop infinitely,
and if H outputs no, our new machine will halt.
We'll call our new machine H+.
Now, the paradox occurs when we feed H+ to itself (as both program p and input i).
That's because if H+ does halt, we get a yes answer (from the H part), but then it loops forever.
However, if H+ doesn't halt, we get a no answer (from the H part), but then it halts.
This is explained very nicely in this computerphile episode.
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').
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
We are given a variable that have some constraints over its range of value, we have to overall find out a set that denotes it overall range.
For example and conditions are as follows
x< 10
x> -6
x>= 0
I can do it on real number line and mark the intersection but how to do it logically in programming.
Note : Only > , >= , < , <= are allowed.
ANSWER=[0, 10)
You have to figure out the logic of your solution, then implement that logic in C++. You say you "can do it", which I assume means you find it "easy" to solve as a humain being. What makes it so easy? Identify the method you're using, then write that method in C++.
There are two types of inequalities: > and <. Well, there are also <= and >=, but I suggest leaving those aside until you've written a program that handles < and > correctly.
Imagine you have:
x > 5
x > 7
x > 6
x < 11
x < 10
x < 12.
What is the solution in this case? Try to find the solution without drawing the number line. Then try to describe with words the way you arrived to this solution.
Then try to write pseudo-code that describes the algorithm more formally.
Finally, you're ready to write C++ code that performs the same steps. I suggest not trying to write C++ until you have written pseudo-code. When writing C++ you'll encounter a few cumbersome details; for instance, how to parse each expression, such as x < 5, to find out what inequality it is and which number it's comparing x to. These "details" are not uninteresting but they will get in the way of your logic so it's best to keep them for last.
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.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
In my software engineering course, I encountered the following characteristic of a stack, condensed by me: What you push is what you pop. The fully axiomatic version I Uled here.
Being a natural-born troll, I immediately invented the Troll Stack. If it has more than 1 element already on it, pushing results in a random permutation of those elements. Promptly I got into an argument with the lecturers whether this nonsense implementation actually violates the axioms. I said no, the top element stays where it is. They said yes, somehow you can recursively apply the push-pop-axiom to get "deeper". Which I don't see. Who is right?
The violated axiom is pop(push(s,x)) = s. Take a stack s with n > 1 distinct entries. If you implement push such that push(s,x) is s'x with s' being a random permutation of s, then since pop is a function, you have a problem: how do you reverse random_permutation() such that pop(push(s,x)) = s? The preimage of s' might have been any of the n! > 1 permutations of s, and no matter which one you map to, there are n! - 1 > 0 other original permutations s'' for which pop(push(s'',x)) != s''.
In cases like this, which might be very easy to see for everybody but not for you (hence your usage of the "troll" word), it always helps to simply run the "program" on a piece of paper.
Write down what happens when you push and pop a few times, and you will see.
You should also be able to see how those axioms correspond very closely to the actual behaviour of your stack; they are not just there for fun, but they deeply (in multiple meanings of the word) specify the data structure with its methods. You could even view them as a "formal system" describing the ins and outs of stacks.
Note that it is still good for you to be sceptic; this leads to a) better insight and b) detection of errors your superiours make. In this case they are right, but there are cases where it can save you a lot of time (e.g. while searching the solution for the "MU" riddle in "Gödel, Escher, Bach", which would be an excellent read for you, I think).
I have a homework assignment, and i am finished other then one question (see title)
For the life of my, i cannot figure this out... so i started to think it was a trick question.
the current answer that i will submit is:
L1 = {a^n b^n: n>=1} is deterministic. And the reverse,
L2 = {b^n a^n: n>=1} is also deterministic.
However, since all deterministic languages are a subset of Non-deterministic languages, L2 can be considered non-deterministic.
On a side note, the only other example i was trying to make work is:
L3= {{a,b}a}
This seems possible because forward there is non-determinism, since the input could be either a, or b as long as its followed by an a.
and in reverse there is determinism since it will accept only an 'a'. But, it introduces new non-determinism since the second input could be either a or b.
any help / guidance would be great.
I know the deadline has passed, but somebody might find this useful in the future.
(a+b+c)*WcW^R, where W is in (a+b)+; this is non-deterministic because you don't know where the "WcW" bit starts.
W^RcW(a+b+c)*, where W is in (a+b)+; this is deterministic because you can write a deterministic PDA to accept simple palindromes of the form "W^RcW" and modify the accepting state to loop to itself on any of a, b and c.
The trick here is that PDAs have to read input from left to right.