Lably
Skip to content

Halting problem

Problem in computer science

  • 23 min read
  • 5 chapters

Related on Lably

Through Computer program, Alan Turing and Algorithm

A key part of the formal statement of the problem is a mathematical definition of a computer and program, usually via a Turing machine. The proof then shows, for any program f that might determine whether programs halt, that a "pathological" program g exists for which f makes an incorrect determination. Specifically, g is the program that, when called with some input, passes its own source and its input to f and does the opposite of what f predicts g will do. The behavior of f on g shows undecidability as it means no program f will solve the halting problem in every possible case.

Background

The halting problem is a decision problem about properties of computer programs on a fixed Turing-complete model of computation. This model of computation includes all programs in Turing-equivalent programming languages. Given a program and an input, the question is whether the program will eventually halt when run with that particular input. In this abstract framework, there are no limitations on the memory or time required for the program's execution; the program may run arbitrarily long and consume arbitrarily large amounts of storage before halting.

For example, in pseudocode, the program

while (true) continue

never halts; rather, it goes on forever in an infinite loop. By contrast,

print "Hello, world!"

halts immediately after printing.

Simple cases like these are easy to decide, but more complex programs are not. Turing proved no algorithm exists that always correctly decides whether, for a given arbitrary program and input, the program halts when run with that input. The essence of Turing's proof is that any such algorithm can be made to produce contradictory output and therefore cannot be correct.

Programming consequences

Most subroutines are intended to finish. The fact that the halting problem is undecidable is often naively taken to mean that establishing whether a program halts is impossible. However, programs such as the T2 Temporal Prover could automatically establish that certain Windows device-driver dispatch routines will always eventually return. It appears feasible that "future program-termination proof tools [may] work 99.9% of the time on programs written by humans."

Some infinite loops can be quite useful. For instance, event loops are typically coded as infinite loops. In total functional programming languages these are often encoded using corecursion, as functions that process and produce infinite coinductive data types such as streams. This formalism allows proving a dual termination property known as productivity.

In hard real-time computing, subroutines must not only finish, but finish before a given deadline. In order to meet these requirements, programmers apply the rule of least power and use restricted styles, not quite fully Turing-complete, that make it easy to prove that the resulting subroutines finish before the given deadline. These include languages such as MISRA C, SPARK, and Rocq.

Common pitfalls

The halting problem requires a decision procedure that works for all programs and inputs. But for any specific program and input, the answer is simply "halts" or "does not halt". Consider two simple decision procedures, one that always answers "halts" and another that always answers "does not halt". For any given case, one of these two algorithms answers correctly, yet neither algorithm solves the halting problem.

Interpreters are programs that simulate the execution of programs whatever source code they are given. Such programs can demonstrate that a program does halt, by running the program for some number of steps. However, an interpreter will not halt if its input program does not halt, so this approach cannot solve the halting problem as stated; it does not successfully answer "does not halt" for programs that do not halt, or determine whether a program will eventually halt or run forever.

The halting problem is decidable for linear bounded automata (LBAs) or deterministic machines with finite memory. Such a machine has finitely many possible configurations, so any deterministic program on it must eventually either halt or repeat a previous configuration:

...any finite-state machine, if left completely to itself, will fall eventually into a perfectly periodic repetitive pattern. The duration of this repeating pattern cannot exceed the number of internal states of the machine...

However, Minsky notes:

...the magnitudes involved should lead one to suspect that theorems and arguments based chiefly on the mere finiteness [of] the state diagram may not carry a great deal of significance.

For example, a computer with a million two-state components would have at least 21,000,000 possible states:

This is a 1 followed by about three hundred thousand zeroes ... Even if such a machine were to operate at the frequencies of cosmic rays, the aeons of galactic evolution would be as nothing compared to the time of a journey through such a cycle.

For nondeterministic finite automata (restricted to finite memory), it is also decidable whether the machine halts on none, some, or all of the possible sequences of nondeterministic decisions, by enumerating states after each possible decision.

Sign in to keep reading

4 more chapters are free with a Lably account.

More in Foundations