What exactly is the halting problem?

Question

Whenever people ask about the halting problem as it pertains to programming, people respond with \"If you just add one loop, you\'ve got the halting program and therefore yo

Answer 1

How does your program resolve the Collatz conjecture ?

Answer 2

Here is a program that the halting problem will never be able to solve.

Assume that you have your magical program/method to determine that a program halts.

public bool DeterminesHalt(string filename, string[] args){
    //runs whatever program you tell it do, passing any args
    //returns true if the program halts, false if it doesn't
}

Now lets say we write a small piece of code such as...

public static void Main(string[] args){
    string filename = Console.ReadLine(); //read in file to run from user
    if(DeterminesHalt(filename, args))
        for(;;);
    else
        return;
}

So for this example, we can write a program to do the exact opposite of our magical halting method does. If we somehow determine that a given program will halt, we just hop into an infinite loop; otherwise if we determine that the program is in an infinite loop, we end the program.

No matter how many input checks you do, there is no possible solution to determine whether EVERY program written halts or not.

Answer 3

Assume that you write an algorithm that can check any arbitrary piece of code and tell if it halts.

Now give your algoritm itself to check.

Answer 4

There are lots of good answers already, but I haven't seen anyone address the fact that, in a sort of selective blending of theory and practicality, the Halting Problem really is solvable.

So first of all, the Halting Problem is basically the task of writing a program which takes any arbitrary second program and determines whether the secondary program will halt on an arbitrary input. So you say "Yes this program will halt on this input" or "No it won't". And in fact, it is unsolvable in the general case (other people seem to have provided proofs of this already) on a Turing Machine. The real problem is that you can kind of find out whether something is going to halt by running it (just wait until it halts), but you can't really find out whether something is going to NOT halt by running it (you'll just keep waiting forever).

This is a problem on a Turing Machine which, by definition, has an infinite amount of memory and thus infinitely many states. However, our computers have only a finite amount of memory. There are only so many bits on the computer. So if you could somehow keep track of all of the previous states (bit configurations) you've seen while running the program, you can guarantee that your checker will never go into an infinite loop. If the secondary program eventually halts, you say "Yes, this program will halt on this input". If you see the same bit configuration twice before it halts, you know "No it won't". Probably not of great technical importance, but it's good to know that a lot of times the really "hard" problems we face are harder in theory than in practice.

Answer 5

Yet another example. I recently ran into something called hailstone numbers. These numbers form a sequence with these rules

f(n) is odd  -  f(n+1) = 3*f(n)+1
f(n) is even -  f(n+1) = f(n)/2

Currently, it is assumed that all starting points will eventually arrive at 1, and then repeat 4,2,1,4,2,1,4,2,1... However there is no proof for this. So right now the only way to determine if a number terminates when fed into the hailstone sequence is to actually compute it until you arrive at 1.

This is the key to how I understand the halting problem. How I understand it is that you cannot for sure know a that a program will/will not halt unless you actually run the program. So any program that you write that could give you an answer for sure to the halting problem, would have to actually run the program.

Answer 6

Here is a simple explanation of the proof that the halting problem is undecidable.

Assume you have a program, H, which computes whether or not a program halts. H takes two parameters, the first is a description of a program, P, and the second is an input, I. H returns true if P halts on input I, and false otherwise.

Now write a program, p2, which takes as it's input the description of another program, p3. p2 calls H(p3, p3), then loops if H returns true and halts otherwise.

What happens when we run p2(p2)?

It must loop and halt at the same time, causing the universe to explode.