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 you can't automate task"

Makes sense. If your program has an infinite loop, then when your program is running, you have no way of knowing whether the program is still crunching input, or if it is just looping infinitely.

But some of this seems counter intuitive. What if I was writing a halting problem solver, which takes source code as its input. rascher@localhost$ ./haltingSolver source.c

If my code (source.c) looks like this:

for (;;) {  /* infinite loop */  }

It seems like it'd be pretty easy for my program to see this. "Look the loop, and look at the condition. If the condition is just based on literals, and no variables, then you always know the outcome of the loop. If there are variables (eg while (x < 10)), see if those variables are ever modified. If not, then you always know the outcome of the loop."

Granted, these checks would not be trivial (calculating pointer arithmetics, etc) but it does not seem impossible. eg:

int x = 0
while (x < 10) {}

could be detected. along with - albeit not trivially:

int x = 0
while (x < 10)
{
   x++;
   if (x == 10)
   {
      x = 0
   }
}

Now what about user input? That is the kicker, that is what makes a program unpredictable.

int x = 0;
while (x < 10) 
{
   scanf("%d", &x); /* ignoring infinite scanf loop oddities */
}

Now my program can say: "If the user enters a 10 or greater, the program will halt. On all other input, it will loop again."

Which means that, even with hundreds of inputs, one ought to be able to list the conditions on which the program will stop. Indeed, when I write a program, I always make sure someone has the ability to terminate it! I am not saying that the resulting list of conditions is trivial to create, but it doesn't seem impossible to me. You could take input from the user, use them to calculate pointer indexes, etc - but that just adds to the number of conditions to ensure the program will terminate, doesn't make it impossible to enumerate them.

So what exactly is the halting problem? What am I not understanding about the idea that we cannot write a problem to detect infinite loops? Or, why are "loops" such an oft-cited example?

UPDATE

So, let me change the question a little bit: what is the halting problem as it applies to computers? And then I will respond to some of the comments:

Many people have said that the program must be able to deal with "any arbitrary input." But in computers, there isn't ever any arbitrary input. If I only input a single byte of data, than I only have 2^8 possible inputs. So, as an example:

int c = getchar()

switch (c) {
   case 'q':
      /* quit the program */
}

All of the sudden, I have just accounted for all of the possibilities. If c has the bit pattern 0x71, it does one thing. For all other patterns, it does something else. Even a program that accepts arbitrary string input is never really "arbitrary", since resources are finite, which means that while the theory of "arbitrary" applies... it isn't exactly one-to-one with the practice.

The other example people cited is this:

while (n != 1)
    if (n & 1 == 1) 
        n = 3 * n + 1;
    else 
        n /= 2;

If n is a 32-bit integer... then I can visually tell you whether or not this will halt.

I guess this edit isn't asking anything, but the most convincing example I've seen is this one:

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.

Then again, if you intentionally write a program which contains an infinite loop... "solving the halting problem" is kind of moot, isn't it?

Answer 1

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 2

How does your program resolve the Collatz conjecture ?

Answer 3

There's an OK proof the Halting Problem on wikipedia.

To illustrate, exactly, why just applying some technique to loops is insufficient, consider the following program (pseudocode):

int main()
{
  //Unbounded length integer
  Number i = 3;

  while(true)
  {
    //example: GetUniquePositiveDivisiors(6) = [1, 2, 3], ...(5) = 1, ...(10) = 1, 2, 5, etc.
    Number[] divisiors = GetUniquePositiveDivisiors(i);
    Number sum = 0;
    foreach(Number divisor in divisiors) sum += divisor;

    if(sum == i) break;

    i+=2;
  }
}

Can you think of an approach that will return true if this code halts, and false otherwise?

Think Carefully.

If by chance you're in serious contention for a Fields medal, imagine some code for these problems in place of the above.

Answer 4

In reference to the sub-point "people respond with "If you just add one loop, you've got the halting program and therefore you can't automate task"", I'll add this detail:

The posts that say that you cannot algorithmically compute whether an arbitrary program will halt are absolutely correct for a Turing Machine.

The thing is, not all programs require Turing Machines. These are programs that can be computed with a conceptually "weaker" machine --- for example, regular expressions can be embodied entirely by a Finite State Machine, which always halts on input. Isn't that nice?

I wager that when the people say "add one loop", they're trying to express the idea that, when a program is complex enough, it requires a Turing Machine, and thus the Halting Problem (as an idea) applies.

This may be slightly tangential to the question, but I believe, given that detail in the question, this was worth pointing out. :)

Answer 5

The precise definition of the problem is that you need to write a program that does the following: - takes an arbitrary program - determines if the program halts given any arbitrary finite input into the program

However, this is a really high bar. There are many partial solutions to the halting problem, but no general solution. Even worse, even finding programs that partially solve the halting problem is known to be difficult:

BBC h2g2 article on the halting problem

If you have truly solved the halting problem, there work on sites like rentacoder.com for you. A few months ago there was a post on one of them from a user named ATuring who offered a contract to solve the halting problem. :)

Answer 6

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.