Results 1 
5 of
5
Mechanizing and Improving Dependency Pairs
 Journal of Automated Reasoning
, 2006
"... Abstract. The dependency pair technique [1, 11, 12] is a powerful method for automated termination and innermost termination proofs of term rewrite systems (TRSs). For any TRS, it generates inequality constraints that have to be satisfied by wellfounded orders. We improve the dependency pair techni ..."
Abstract

Cited by 67 (33 self)
 Add to MetaCart
Abstract. The dependency pair technique [1, 11, 12] is a powerful method for automated termination and innermost termination proofs of term rewrite systems (TRSs). For any TRS, it generates inequality constraints that have to be satisfied by wellfounded orders. We improve the dependency pair technique by considerably reducing the number of constraints produced for (innermost) termination proofs. Moreover, we extend transformation techniques to manipulate dependency pairs which simplify (innermost) termination proofs significantly. In order to fully mechanize the approach, we show how transformations and the search for suitable orders can be mechanized efficiently. We implemented our results in the automated termination prover AProVE and evaluated them on large collections of examples.
Program termination and well partial orderings
, 2006
"... The following known observation is useful in establishing program termination: if a transitive relation R is covered by finitely many wellfounded relations U1,..., Un then R is wellfounded. A question arises how to bound the ordinal height R  of the relation R in terms of the ordinals αi = Ui. ..."
Abstract

Cited by 11 (0 self)
 Add to MetaCart
The following known observation is useful in establishing program termination: if a transitive relation R is covered by finitely many wellfounded relations U1,..., Un then R is wellfounded. A question arises how to bound the ordinal height R  of the relation R in terms of the ordinals αi = Ui. We introduce the notion of the stature ‖P ‖ of a well partial ordering P and show that R  ≤ ‖α1 × · · · × αn ‖ and that this bound is tight. The notion of stature is of considerable independent interest. We define ‖P ‖ as the ordinal height of the forest of nonempty bad sequences of P, but it has many other natural and equivalent definitions. In particular, ‖P ‖ is the supremum, and in fact the maximum, of the lengths of linearizations of P. And ‖α1 × · · · × αn ‖ is equal to the natural product α1 ⊗ · · · ⊗ αn.
Adapting Functional Programs to HigherOrder Logic
"... Abstract. Higherorder logic proof systems combine functional programming with logic, providing functional programmers with a comfortable setting for the formalization of programs, specifications, and proofs. However, a possibly unfamiliar aspect of working in such an environment is that formally es ..."
Abstract

Cited by 2 (1 self)
 Add to MetaCart
Abstract. Higherorder logic proof systems combine functional programming with logic, providing functional programmers with a comfortable setting for the formalization of programs, specifications, and proofs. However, a possibly unfamiliar aspect of working in such an environment is that formally establishing program termination is necessary. In many cases, termination can be automatically proved, but there are useful programs that diverge and others that always terminate but have difficult termination proofs. We discuss techniques that support the expression of such programs as logical functions. 1.
Complexity Analysis of SizeChange Terminating Programs (extended abstract: work in progress)
"... Central to the field of Implicit Computational Complexity (ICC) is the idea of restricting a programming language syntactically so that the admitted programs possess a certain complexity, e.g., polynomial time. Since programmers want their programs to have wellbehaved complexity, this appears at fi ..."
Abstract
 Add to MetaCart
Central to the field of Implicit Computational Complexity (ICC) is the idea of restricting a programming language syntactically so that the admitted programs possess a certain complexity, e.g., polynomial time. Since programmers want their programs to have wellbehaved complexity, this appears at first to be a useful approach. However, languages designed to capture a complexity class tend to be too restrictive or