Hipótesis General

OTTER(Organized Techniques for Theorem-proving and Effective Research) was the product of many years of theorem prover development at the Argonne National Laboratory and the Northern Illinois University (NIU).

Many of the features and inference rules included in OTTERwere developed as part of earlier theorem provers.

5.2.1 The Development of OTTER

The first phase of theorem prover development at Argonne started in 1963, approximately two years before Robinson published his pioneering paper defining the resolution inference mechanism (see Section 2.3.2). By 1970 two major systems (P1 and RW1) had been developed that contained the first attempts to implement and experiment with resolution (Lusk 1992).

Daniel Carson and Larry Wos built the first resolution theorem prover called P1 (for “Program 1”). P1 implemented binary resolution with factoring as well as forward subsumption . The set-of-support strategy and demodulation were developed during experimentation with P1 (Wos et al. 1967).

Wos, in collaboration with George Robinson, continued experimentation with demodulation. They also for-mulated the paramodulation inference mechanism in their 1968 article Paramodulation and Theorem-proving in First-order Theories with Equality(G. A. Robinson and Wos 2000). Together they built RW1 (for “Robinson-Wos 1”) in the late 1960’s which was capable of performing equality proofs of the problems P1 could solve.

In 1971 Ross Overbeek independently built the theorem prover FTP (for “Functionless Theorem Prover”

since it did not make use of functions). He introduced a number of features that remained important components of the Argonne family of theorem provers for years to come (Lusk 1992). For example, Overbeek introduced hyperresolution, forward and backward subsumption, and weighting.

The algorithm for the basic loop of Overbeek’s prover remained unchanged for several generations of Argonne provers. The search for a proof starts with a set of clauses divided into two sets: the axioms and the set-of-support. The algorithm is as follows:

While (the null clause has not been produced and the set of support is not empty) Choose a clause from the set of support,

call it the given clause, and move it to the axioms

Generate all clauses that can be deduced from the given clause and other clauses in the axiom set

For each new generated clause

Process it (rewrite to canonical form, merge literals, etc.) Test whether it is subsumed by any existing clause Perform any other desired filtering (e.g., weighting) If the new clause survives

Add it to the set of support end if

Perform back subsumption with new clause

Rewrite existing clauses with [new clause] if it is a demodulator end for

end while

Table 5.3: The closure algorithm (Lusk 1992, p. 99)

Lusk (1992, p. 99) refers to Overbeek’s algorithm as the closure algorithm. The algorithm computes the closure of a set of clauses under the operation of a set of inference rules. Two characteristics of the algorithm are significant:

• At each execution of the while loop, all consequences of the given clause are generated; and

• All generated clauses are stored to avoid having to repeat processing clauses.

The behaviour of the algorithm could be altered through user control options and heuristics, for example by

• Specifying the initial set-of-support;

• Specifying the set of inference rules;

• Specifying the given clause at the start of each iteration; and

• Specifying the choice of kept clauses during post-processing.

In 1971, Overbeek joined Northern Illinois University and met Wos. They merged the functionality and features of RW1 and FTP to produce WOS1 which was also based on the closure algorithm. Features and inference rules included function symbols, paramodulation, hyperresolution and weighting. A paper containing the results of experiments carried out with WOS1 was presented at the Argonne Workshop on Automated Theorem Proving. The workshop was later renamed CADE-1, i.e. the first CADE³(Lusk 1992).

3See Section 5.1.

By the late 1970’s Ewing Lusk, William (Bill) McCune and Overbeek created LMA (Logic Machine Archi-tecture) to incorporate new insights from computer science regarding the structuring of large computer systems and to provide some support for the interactive use of the prover. LMA was still powerful enough to solve all problems that the earlier Argonne and Northern Illinois University theorem provers could solve, but it was significantly slower.

McCune joined Argonne in 1984 and he created OTTERduring 1987-1988. Developed in ANSI C, OTTER’s first release (starting at version 0.9) was at CADE-9 in May 1988 (see Section 5.1.1). OTTER is a general-purpose, resolution-based automated reasoner for first-order logic with equality (McCune 2003; McCune and Wos 1997; Wos 1998). One of the primary objectives was to regain the speed of the systems preceding the LMA theorem prover. A secondary goal was to create a flexible tool that could easily absorb new techniques and inference rules for experimentation (by recompiling the application from modified source code).

OTTER was applied successfully to solve numerous problems in mathematics and logic. Of particular interest was the open conjecture regarding Robbins algebras (McCune 1997; Wos 1998). Many additional examples are discussed in (McCune and Wos 1997). In 2004 development of OTTERwas suspended in favour of Prover9 (McCune 2005; McCune 2013).

This concludes our overview of the development of OTTER. In the remaining sections we discuss OTTER’s input and syntax, and implementation of resolution.

5.2.2 Input

5.2.2.1 Parts of the Input File

OTTER input files consist of lists of commands. A command is either a flag or a parameter. Flags (boolean-valued options) are changed with the set and clear commands. Parameters (integer-(boolean-valued options) are changed with the assign command. Table 5.4 shows the commands accepted by OTTER.

include(file name). % read input from another file

op(precedence, type, name(s)). % declare operator(s) make_evaluable(sym, eval-sym). % make a symbol evaluable

set(flag name). % set a flag

clear(flag name). % clear a flag

assign(parameter name, integer). % assign to a parameter

list(list name). % read a list of clauses

formula_list(list name). % read a list formulas weight_list(weight list name). % read weight templates

(symbol list).

lrpo_multiset_status(symbol list). % status for LRPO

Table 5.4: OTTER’s Input Commands (McCune 2003, p. 12)

The list and formula_list commands are discussed below in Section 5.2.2.2 . This section is con-cluded with Example 5.1: an excerpt from an input file showing the commands set, clear and assign.

Example 5.1 (OTTERCommands). The list of commands below instructs OTTERto apply unit-resulting resolution, perform no arity checks on symbols and to terminate the search once 1000 clauses were gen-erated (McCune 2003, p. 13):

set(ur_res). % Apply UR-resolution

% to all generated clauses clear(check_arity). % Do not warn if symbols

% have variable arities assign(max_gen, 1000). % Terminate search after

% generating 1000 clauses



5.2.2.2 Formula lists

Formulas can be divided into several lists in the input file. Four types of lists can be specified: usable, set-of-support (sos), demodulators and passive. The usable list contains clauses that are actively used to make inferences. The clauses in the set-of-support list are not used to make inferences, but are used during the search. Clauses in the passive list are used for forward subsumption and unit conflict resolution. The passive list remains unchanged during search. Finally, the list of demodulators are used to rewrite newly inferred clauses (McCune 2003, p. 3).

Example 5.2 (Usable List). The following list of formulas is an example of a usable list in OTTER

input. Usable clauses are actively used to make inferences (McCune 2003, p. 3).

list(usable).

x = x. % reflexivity

f(e, x) = x. % left identity f(x, e) = x. % right identity end of list.



5.2.3 Syntax

OTTERaccepts two types of statements in first-order logic:

• Clauses - disjunctions of terms and literals with implicitly universally quantified variables; and

• Formulas - with all variables explicitly quantified.

All formulas in the input are converted to clauses when not already in clausal form, since OTTER’s search mechanism only operates on clauses (McCune 2003, p. 5).

5.2.4 Implementation of Resolution in OTTER

OTTER implements the general resolution rule discussed in Section 3.3.2 and allows the user to set flags in the input that result in the application of various extensions to the binary resolution rule⁴. OTTERattempts to derive the empty clause (“$F” in the output) from the input when the input contains a non-empty goal list and a possibly empty set-of-support as follows:

1. The formulas in the sos list are clausified;

2. The formulas in the goal list are negated and clausified;

3. All resulting clauses are included in the initial internal sos (as opposed to the set-of-support list in the input);

4. While the sos is not empty and $F has not been derived:

(a) The lightest clause is selected from the set-of-support;

(b) The clause is moved to the usable list;

(c) OTTER then attempts to generate and process new clauses based on the inference rule (all new clauses must have the selected clause and clauses from the usable list as parents);

(d) Clauses that pass various tests (Van der Poll (2000, p. 66) refers to retention tests such as paramod-ulation, subsumption and weighting) are appended to the set-of-support.

The process terminates when a refutation is found, the set-of-support list is empty, or the user interrupts the proof attempt (Van der Poll 2000, p. 67).

The set-of-support list in OTTERinput is related to the set-of-support strategy. The strategy involves par-titioning of the set S of input clauses, by taking a subset T that contains one or more clauses to be the set-of-support. The reasoning process then progresses by requiring one of the parent clauses of a resolvent to come from the set-of-support (in this case, T) and the other parent(s) from S − T (Van der Poll 2000).