deff(n):whilen>1:ifn%2==0:n=n/2else:n=3*n+1 |
| As of 2025[update], it is still unknown whether thisPython program terminates for every input; seeCollatz conjecture. |
Incomputer science,termination analysis isprogram analysis which attempts to determine whether the evaluation of a givenprogram halts foreach input. This means to determine whether the input program computes atotal function.
It is closely related to thehalting problem, which is to determine whether a given program halts for agiven input and which isundecidable. The termination analysis is even more difficult than the halting problem: the termination analysis in the model ofTuring machines as the model of programs implementing computable functions would have the goal of deciding whether a given Turing machine is atotal Turing machine, and this problem is at level of thearithmetical hierarchy and thus is strictly more difficult than the halting problem.
Now as the question whether a computable function is total is notsemi-decidable,[1] eachsound termination analyzer (i.e. an affirmative answer is never given for a non-terminating program) isincomplete, i.e. must fail in determining termination for infinitely many terminating programs, either by running forever or halting with an indefinite answer.
Atermination proof is a type ofmathematical proof that plays a critical role informal verification becausetotal correctness of analgorithm depends on termination.
A simple, general method for constructing termination proofs involves associating ameasure with each step of an algorithm. The measure is taken from the domain of awell-founded relation, such as from theordinal numbers. If the measure "decreases" according to the relation along every possible step of the algorithm, it must terminate, because there are noinfinite descending chains with respect to a well-founded relation.
Some types of termination analysis can automatically generate or imply the existence of a termination proof.
An example of aprogramming language construct which may or may not terminate is aloop, as they can be run repeatedly. Loops implemented using acounter variable as typically found indata processingalgorithms will usually terminate, demonstrated by thepseudocode example below:
i := 0loop until i = SIZE_OF_DATA process_data(data[i]))// process the data chunk at position i i := i + 1// move to the next chunk of data to be processed
If the value ofSIZE_OF_DATA is non-negative, fixed and finite, the loop will eventually terminate, assumingprocess_data terminates too.
Some loops can be shown to always terminate or never terminate through human inspection. For example, the following loop will, in theory, never stop. However, it may halt when executed on a physical machine due toarithmetic overflow: either leading to anexception or causing the counter to wrap to a negative value and enabling the loop condition to be fulfilled.
i := 1loop until i = 0 i := i + 1
In termination analysis one may also try to determine the termination behaviour of some program depending on some unknown input. The following example illustrates this problem.
i := 1loop until i = UNKNOWN i := i + 1
Here the loop condition is defined using some value UNKNOWN, where the value of UNKNOWN is not known (e.g. defined by the user's input when the program is executed). Here the termination analysis must take into account all possible values of UNKNOWN and find out that in the possible case of UNKNOWN = 0 (as in the original example) the termination cannot be shown.
There is, however, no general procedure for determining whether an expression involving looping instructions will halt, even when humans are tasked with the inspection. The theoretical reason for this is the undecidability of the halting problem: there cannot exist some algorithm which determines whether any given program stops after finitely many computation steps.
In practice one fails to show termination (or non-termination) because every algorithm works with a finite set of methods being able to extract relevant information out of a given program. A method might look at how variables change with respect to some loop condition (possibly showing termination for that loop), other methods might try to transform the program's calculation to some mathematical construct and work on that, possibly getting information about the termination behaviour out of some properties of this mathematical model. But because each method is only able to "see" some specific reasons for (non)termination, even through combination of such methods one cannot cover all possible reasons for (non)termination.[citation needed]
Recursive functions and loops are equivalent in expression; any expression involving loops can be written using recursion, and vice versa. Thus thetermination of recursive expressions is also undecidable in general. Most recursive expressions found in common usage (i.e. notpathological) can be shown to terminate through various means, usually depending on the definition of the expression itself. As an example, thefunction argument in the recursive expression for thefactorial function below will always decrease by 1; by thewell-ordering property ofnatural numbers, the argument will eventually reach 1 and the recursion will terminate.
function factorial (argumentas natural number)if argument = 0or argument = 1return 1otherwisereturn argument * factorial(argument - 1)
Termination check is very important independently typed programming language and theorem proving systems likeCoq andAgda. These systems useCurry-Howard isomorphism between programs and proofs. Proofs over inductively defined data types were traditionally described using induction principles. However, it was found later that describing a program via a recursively defined function with pattern matching is a more natural way of proving than using induction principles directly. Unfortunately, allowing non-terminating definitions leads to logical inconsistency in type theories[citation needed], which is why Agda and Coq have termination checkers built-in.
One of the approaches to termination checking in dependently typed programming languages are sized types. The main idea is to annotate the types over which we can recurse with size annotations and allow recursive calls only on smaller arguments. Sized types are implemented in Agda as a syntactic extension.
There are several research teams that work on new methods that can show (non)termination. Many researchers include these methods into programs[2] that try to analyze the termination behavior automatically (so without human interaction). An ongoing aspect of research is to allow the existing methods to be used to analyze termination behavior of programs written in "real world" programming languages. For declarative languages likeHaskell,Mercury andProlog, many results exist[3][4][5] (mainly because of the strong mathematical background of these languages). The research community also works on new methods to analyze termination behavior of programs written in imperative languages like C and Java.
Research papers on automated program termination analysis include:
System descriptions of automated termination analysis tools include: