automatic synthesis of decision procedures: a case study...

Automatic Synthesis of Decision Procedures: a

Case Study of Ground and Linear Arithmetic∗

Predrag Janicic

Faculty of Mathematics, University of Belgrade

Studentski trg 16, 11000 Belgrade, Serbia and Montenegro

email: [email protected]

Alan Bundy

School of Informatics, University of Edinburgh

Appleton Tower, Crichton St, Edinburgh EH8 9LE, UK

email: [email protected]

Abstract

In this paper we address the problem of automatic synthesis of decisionprocedures. We evaluate our ideas on ground arithmetic and Fourier/Motzkindecision procedure for linear arithmetic, but the approach can be ap-plied to other domains as well. The approach is well-suited to the proof-planning paradigm. The synthesis mechanism consists of several stagesand sub-mechanisms. Some of these steps are performed automatically,while in some steps human assistance is necessary. Our system (adep-

tus), which we present in this paper, synthesized a decision procedurefor ground arithmetic completely automatically and it used some specificmethod generators in generating a decision procedure for linear arith-metic. We believe that this approach can lead to automated assistance inconstructing decision procedures and to more reliable implementations ofdecision procedures.

1 Introduction

Decision procedures are often vital in theorem proving [2, 11]. In order to havedecision procedures usable in a theorem prover it is often necessary to havethem implemented not only efficiently, but also flexibly. Also, it is often veryimportant to have decision procedures for new, user-defined theories. The im-plementation should also be such that it can be verified in some formal way. Forall these reasons, it would be fruitful if we can automate the process (or, at least,

∗The first author was supported by EPSRC grant GR/R52954/01. The second author wassupported in part by EPSRC grant GR/S01771.

1

all its routine steps) of synthesizing and implementing decision procedures. Itwould also help avoiding human mistakes in implementing decision procedures.In addition, since many steps in different decision procedures can be describedvia rewriting, object level proofs can often be also relatively easily derived froman application of a decision procedure.

Due to their importance in software and hardware verification and, therefore,in different schemes for combining and augmenting decision procedures, in thispaper we evaluate our techniques on ground arithmetic and linear arithmetic.As it is interesting and non-trivial, we focus on ideas from the Fourier/Motzkinprocedure for linear arithmetic [13].

In this paper we follow ideas from Bundy’s paper on proof plans for normal-isations [5]. As discussed in [5], most steps of many decision procedures can bedescribed via sets of rewrite rules. This observation prepares the way for auto-matic generation of new decision procedures (given the necessary rewrite rules),which is vital for user defined theories. Bundy’s programme (slightly modi-fied) and the synthesis process we present in this paper can be decomposed intoseveral subproblems:

• Make a method which is capable of doing the following: given two syn-tactical classes and some rewrite rules, select (if it is possible) a subset ofrewrite rules which is sufficient to transform (or normalise) any memberof the first syntactical class (described by Backus-Naur form (bnf) or,equivalently, by a context-free grammar) into a member of the second syn-tactical class. Given the input syntactical class, the kind of a method andits parameters, the output syntactical class can be automatically gener-ated in a number of special cases, i.e., for all kinds of methods discussed inthis paper.1 An algorithm which can generate such a method (on the basisof the given input class, available rewrite rules, the kind of the method,and the method’s parameters) we call a method generator.

• If the available set of rewrite rules is not sufficient for performing thetransformation from one syntactical class to another, then the methodgenerator has to report about missing rules; in a planned advanced version(which is not part of the work presented in this paper), it has to speculatethe remaining necessary rules and/or to redefine/relax the output class;

• there will be different kinds of normalisation methods, e.g., one for re-moving some function symbol, one for stratification, one for thinning etc.(see further text and [5] for explanation of these terms.); for each of them,there is a method generator.

• methods should be designed in such a way that their soundness, com-pleteness, and termination are guaranteed; the same holds for compoundmethods;

1In general, given the input bnf and a set of rewrite rules, the output language is not alwayscontext-free (i.e. it cannot be described via a bnf). Moreover, it is undecidable whether suchoutput language is context-free. The general problem of determining the output bnf (whenit exists), given the input bnf and a set of rewrite rules is the subject of our current research.

2

• given all necessary methods, it should be possible to combine them (au-tomatically) into a compound method or, sometimes, into a decision pro-cedure for some theory;

• since some transformations (required for some decision procedures) arevery complex, building some methods (or some method generators) mayrequire some human interaction and assistance.

We have implemented several method generators: generators for removemethods, stratify methods, thin methods, absorb methods and left-assoc meth-ods and several special-purpose method generators. These generators take agiven Backus-Naur form, transform it into another one, and build a methodwhich uses some available rewrite rules such that each input formula (which be-longs to the first bnf) will be transformed into a formula which belongs to thesecond bnf. On the set of all these generators, we can perform a (heuristicallyguided) search for a sequence of methods which goes from the starting bnf toa trivial bnf (consisting of only > and ⊥). If the final syntactical class is equalto ⊥,>, then the whole of the sequence yields a decision procedure for theunderlying theory (under some assumptions about available rewrite rules). Ifsuch a method can be built, soundness, termination, and completeness can beeasily proved (see §3.1).

The system consisting of the implemented method generators and searchengines we call adeptus (coming from Assembly of DEcision Procedures viaTransmUtation and Synthesis2).

Our first target theory was ground arithmetic over rationals. We had avail-able all the necessary rewrite rules. adeptus synthesized the decision proce-dures for this theory completely automatically in around 3 seconds of cpu time(see more details in §6).

While a decision procedure for ground arithmetic can be also obtained byexhaustive application of all rewrite rules, our system gives a procedure whichuses their subsets in stages and gives structured proofs (easily understandableto a human).

Our second target theory was (quantified) linear arithmetic. For this theorywe had to implement three more method generators: one for adjusting theinnermost quantifier, one for isolating a variable, and one for removing a variable(cross-multiply and add step). The search is performed in three stages andall three of them give sequences of methods. Combined, these sequences (thesecond one in a loop) give a decision procedure for linear arithmetic. adeptus

automatically performed these three stages and synthesized a decision procedurefor linear arithmetic in around 5 seconds of cpu time (see more details in §9).For some conditional rewrite rules, this decision procedure itself can be used toprove that their conditions cover all possible cases. We prove that both of thegenerated procedures are sound, complete and terminating.

2Also, Adeptus (Lat.) is “one with the alchemical knowledge to turn base metals intogold”.

3

For some theories this approach gives not only automatically generated de-cision procedures, but also a higher-level understanding of syntactical transfor-mations within the underlying theory. We believe that this approach can behelpful in both easier implementation of decision procedures and their deeperunderstanding. The approach can also be used just to construct normalisationprocedures.

Overview of the paper: In §2 we give some basic background and notationinformation. In §3 we introduce the notion of normalizers and discuss theirautomatic generation. In §4 we present several generic method generators and in§5 a search engine which uses them. In §6 we report on how we used that searchengine to synthesize a decision procedure for ground arithmetic. In §7 we presentseveral special-purpose method generators. In §8 we describe a compound searchengine and in §9 we report on how we used it to synthesize a decision procedurefor linear arithmetic. In §10 we present some additional examples. In §11we discuss some possibilities and limitations in automatic synthesis of decisionprocedures. In §12 we discuss related work. In §13 we discuss future work, andin §14 we draw final conclusions.

2 Background and Notation

2.1 Decidable theories and decision procedures

A theory T is decidable if there is an algorithm (which we call a decision pro-cedure) such that for an input T -sentence f , it returns yes if and only if T ` f

(and returns no otherwise).

2.2 Presburger arithmetic

Presburger Natural Arithmetic is (roughly speaking) a first-order theory builtup from the constant 0, variables, binary function symbol +, unary functionsymbol s and binary predicate symbols <, >, =, 6=, ≤, ≥. Note that nx (wheren is a numeral) can also be considered as in Presburger Natural Arithmetic: nx

is treated as x+· · ·+x, where x appears n times. We denote Presburger NaturalArithmetic as pna. By analogy we define Presburger arithmetic over integers(Presburger Integer Arithmetic, denoted pia) and over rationals (PresburgerRational Arithmetic, denoted pra); these two theories have the additional unaryfunction symbol −. pra is sometimes referred to as linear arithmetic [2].

There are several decision procedures for pia, including Cooper’s proce-dure [6]. The Fourier/Motzkin procedure [13] is a decision procedure for pra.Sometimes, it is referred to as Hodes’ procedure [9]. This procedure has veryimportant uses and it has been rediscovered a number of times. In theoremproving, because its worst case complexity is lower than of Cooper’s procedure,this procedure is often used for the universally quantified fragment of pia, as itis sound (although incomplete) for it [2].

4

2.3 Backus-Naur form

We can define a set of pia (pna, pra) formulae by a context-free grammar orin Backus-Naur Form (bnf).

Example 1 Using a bnf we can define pra formulae in the following way:

f := af |¬f |f ∨ f |f ∧ f |f ⇒ f |f ⇔ f |(∃var : sort)f |(∀var : sort)faf := >|⊥|t = t|t < t|t > t|t ≤ t|t ≥ t|t 6= t

t := var|rc|rc · t| − t|t + t

var := x1|x2|x3| . . .sort := rational

(1)where f denotes the syntactical class of formulae, af the class of atomic for-mulae, t denotes the class of terms, var variables, and rc denotes rational con-stants.

In representing some infinite syntactical classes (for instance, the classesrc and var in the above example) sometimes, for convenience, we use someadditional device and some meta-level conditions.

We will assume that each bnf definition has attached its top class (or startclass). While a bnf definition corresponds to a context-free grammar, this classcorresponds to the start symbol in formal grammars. The language of a bnf isa set of all expressions that can be derived from the top class. Normally, it is aclass that corresponds to the set of formulae (the class f in the above example).

2.4 Rewrite rules

In the rest of the paper we will assume that during the method generation thereare available some unconditional or conditional rewrite rules. Unconditionalrewrite rules are of the form:

RuleName : l −→ r .

Conditional rewrite rules are of the form:

RuleName : l −→ r if p1, p2, . . . , pn,

where p1, p2, . . ., pn are literals.3 These rewrite rules correspond to someunderlying (background) theory T and the conditions may rely on some theory-specific properties. For instance, we can have the rewrite rule (correspondingto pra):

n1x + n2x −→ nx if n = n1 + n2.

In the above rule, the condition n = n1 + n2 is not of a syntactical nature andhence, in general, we will have to use some semantic knowledge, i.e., we will

3Note that this form can be considered as a normal form of conditional rewrite rules witharbitrary propositional structure in their conditions.

5

have to use rewriting modulo the underlying theory. However, these conditionsare, usually, very simple and they usually involve only ground literals.

For a ruleRuleName : l −→ r if p1, p2, . . . , pn,

we say that it is sound with respect to theory T if for arbitrary T -formula Φand arbitrary substitution ϕ it holds that T ` Φ if T , p1ϕ, p2ϕ, . . . , pnϕ `Φ[lϕ 7→ rϕ] (where 7→ denotes substitution), and we say that it is complete withrespect to theory T if for arbitrary T -formula and arbitrary substitution ϕ itholds that T ` Φ only if T , p1ϕ, p2ϕ, . . . , pnϕ ` Φ[lϕ 7→ rϕ]. We say that arewrite rule is two-way rule w.r.t. T if it is sound and complete w.r.t. T .

2.5 Syntactical relations

We introduce two syntactical relations: ec (from element of class) and aec

(abstract element of class). ec(b, e, c) holds if and only if a syntactical elemente is an element of a class c in the bnf definition b. For instance, if we denoteby b1 the definition (1) (from Example 1, p5), then it holds that

ec(b1, (∃x : rational)0 = x, f)andec(b1, (0 = x) ∧ (1 = y), f ∧ f)The relation aec is defined by analogy, but its arguments can also include

some abstract components. For example, it holds:aec(b1, af ∧ (1 = y), f ∧ f).

2.6 Proof planning and methods

Proof-planning is a technique for guiding the search for a proof in automated the-orem proving. To prove a conjecture, within a proof-planning system, a methodconstructs the proof plan and this plan is then used to guide the constructionof the proof itself [4, 3]. These plans are made up of tactics, which representcommon patterns of reasoning. A tactic’s preconditions and effects are specifiedby a method, i.e., a method is a specification of a tactic. A method has severalslots: a name, input, preconditions, transformation, output, postconditions andthe name of the attached tactic.4

Definition 1 A method describes the preconditions for the use of a tactic, thetransformation that corresponds to it and the postconditions (conditions thathold for the conjecture after the application of the tactic). These conditions and

4In our implementation of the system presented in this paper, we have not implementedtactics yet. So, our procedures produce meta-level proof plans, not the object level proofs.However, for most of the methods, implementing tactics would not be difficult, as most of therequired tactics are based on applying given rewrite rules. For some steps (like cross multiply

and add for a decision procedure for linear arithmetic, see §7.4), tactics would be more involved.Also, for providing tactics and object level proofs, it would be suitable to incorporate adeptus

into some more general system with proof engine, able for running tactics on (e.g., IsaPlannerbuilt on top of Isabelle).

6

transformation are syntactic properties of the logical expressions manipulated bythe tactic and are expressed in a meta-logic.

A method cannot be applied if its preconditions are not met. Also, withthe transformation performed and the output computed, the postconditions arechecked and the method application fails if they fail.

2.7 Target language

The whole of adeptus is implemented in prolog as a stand-alone system.5 Allgenerated methods are built in the spirit of the proof planning paradigm (andimplemented in prolog).

2.8 Standardizing apart

For simplicity, in the rest of the paper and in all described normalisation meth-ods and decision procedures, we assume that, in formulae being transformed,variables are standardized apart, that is — there are no two quantifiers withthe same variable symbol in one formula.

3 Normalisation Methods

We will describe a number of steps of different decision procedures for groundarithmetic and for linear arithmetic in a purely syntactical way and in termsof rewriting (in the spirit of Bundy’s proof plans for normalisations [5]). Forinstance, one of the steps in different decision procedures is elimination of equiva-lence and that step can be described as an exhaustive application of the followingrewrite rule:

f1 ⇔ f2 −→ (f1 ⇒ f2) ∧ (f2 ⇒ f1)This rule links a pair of classes of formulae, which can be represented in

Backus-Naur Form (bnf) as shown in the following example.

Example 2 Each formula belonging to the following class (af denotes the classof atomic formulae):

f := af |¬f |f ∨ f |f ∧ f |f ⇒ f |f ⇔ f |(∃var : sort)f |(∀var : sort)fcan be transformed by using the rewrite rule

f1 ⇔ f2 −→ (f1 ⇒ f2) ∧ (f2 ⇒ f1)and the resulting formula belongs to the following class f :

f := af |¬f |f ∨ f |f ∧ f |f ⇒ f |(∃var : sort)f |(∀var : sort)f .

This way, a description of the effect of a certain normalisation can lead toan automated synthesis of that normalisation. Namely, given a set of rewriterules and bnf form of the input class of formulae, it is possible to automaticallygenerate certain normalization steps or sequences of normalization steps (and

5The presented system is available on-line from www.matf.bg.ac.yu/~janicic.

7

the corresponding output classes). In the above example, it can be easily shownthat any formula belonging to the first class can be transformed to a formulabelonging to the second class (by exhaustive application of the given rewriterule). As we will see, for some theories the whole decision procedure can begenerated on these bases (with a trivial output class, consisting of only twoformulae — > and ⊥).

Definition 2 A Method generator is a procedure with the input consisting of

• a bnf form b of the input expressions;

• a set of rewrite rules R;

• a kind t of the required method (e.g., remove, stratify, etc.)

that generates a method M and a bnf form b′ (of the output expressions). Themethod M has a kind t and, by using exhaustive application of rules from R, ittransforms any expression belonging to b to an expression belonging to b′.

We have implemented method generators for several kinds of methods: re-move, stratify, thin, absorb and left-assoc.

Method generators for most normalizers (normalisation methods) work, ina sense, in a uniform way: each of them takes the input bnf set (and givenparameters), searches for “problematic” bnf entries (for instance, bnf entrieswith occurrences of the symbol that should be eliminated — f := f ⇔ f inExample 2) and constructs the target output bnf set; after that, a commonalgorithm for searching over the set of available rewrite rules is invoked and itchecks if all “problematic” entries can be rewritten in such a way that any inputformula, when rewritten, falls in the target output top class. In addition, thissearch mechanism attaches rewrite rules to particular entries (because selectedrewrite rules cannot be applied arbitrarily, as will be illustrated in Example 8,(p15)). When we are discussing the properties of some method generators, weconsider both their properties and the properties of the generated methods.

3.1 Properties of Method Generators and of Generated

Methods

In this part of the paper we (preliminarily) discuss properties (termination,soundness and completeness) of method generators and of generated methods(i.e., normalization methods). We also briefly discuss properties of compoundmethods (of methods built from several generated methods).

3.1.1 Properties of method generators

For each method generator we present in this paper it is easy to show that it isterminating. Method generators are not complete, i.e., they are not guaranteedto produce the required methods — in some circumstances they fail, as theycannot find the necessary rewrite rules. Moreover, we don’t claim completeness

8

of all the method generators in a narrower sense — that they produce requiredmethods whenever it is possible. On the other hand, we can consider soundnessof the method generators, i.e., the issue whether, if a method is generated, thenit meets the given conditions. Soundness of method generators defined in thisway can actually be considered as a set of properties (soundness, completeness,termination) of the generated methods.

3.1.2 Properties of the generated methods

A normalisation method links two syntactical sets — these two sets shouldbe equivalent modulo the underlying theory T . In purely syntactical terms,each formula f1 that belongs to the top class of the input bnf set should betransformed (in a finite number of steps) into a formula f2 that belongs tothe top class of the output bnf set. Moreover, taking the properties of theunderlying theory T , it should hold that T ` f1 if (and only if) T ` f2. Ifthe “if” condition holds, then the method is sound (w.r.t. T ). If the “only if”condition holds then the method is complete (w.r.t. T ). If these properties arefulfilled, then the method is terminating, sound and complete.

Termination. For each generated method it must be shown that it is termi-nating (by considering properties of the rewrite rules used6). For some sorts ofmethods, their termination is guaranteed by the way they are generated.

Soundness. We distinguish soundness of a method w.r.t. syntactical restric-tions and soundness of a method w.r.t. the underlying theory T . If a methodtransforms one formula into another one, then it is ensured by the method’spostconditions that the second one does meet the required syntactical restric-tions (given by the method specification), so the method is sound w.r.t. syntac-tical restrictions. In addition, all available rewrite rules (all of them correspondto the underlying theory T ) are assumed to be sound. Thus, since a methodis (usually) based on exhaustive application of some (normally sound) rewriterules, it is trivially sound w.r.t. T .

Completeness. We distinguish completeness of a method w.r.t. syntacticalrestrictions and completeness of a method w.r.t. the underlying theory T . Itis not a priori guaranteed that a generated method can transform any inputformula (which meets the preconditions) into some other formula (that belongsto the output class), i.e., it is not guaranteed that the method is completew.r.t. syntactical restrictions. Namely, a method maybe uses some conditionalrewrite rules (which cannot be applied to all input formulae). If a method usesonly unconditional rewrite rules or if a method uses conditional rewrite ruleswhich cover all possible cases, then it can transform any input formula into aformula belonging to the output class. Completeness of a method w.r.t. T alsorelies on the completeness of the rewrite rules used. If a method can transformany input formula into a formula belonging to the output class and if all therewrite rules it uses are complete, then the method is complete w.r.t. T . Note

6Note that these sets of rewrite rules are not always confluent. Moreover, for certaintasks, such as, for instance, transforming a formula into disjunctive normal form, there is noconfluent and terminating rewrite system [16].

9

that both of these conditions are necessary: for instance, we can build a methodfor pia by using rewrite rules for pra; this method will be sound (w.r.t. pia) (foruniversally quantified fragment) and it could transform any input formula, butit will still be incomplete w.r.t. pia (see Example 3). However, such methodscan still be very useful.

Example 3 The formula (∀x)(1 ≥ x ∨ x ≥ 2) is a theorem of pia, but isnot a theorem of pra (i.e., it is valid if x ranges over integers, but is not if x

ranges over rationals). The Fourier/Motzkin decision procedure for pra wouldtransform (∀x)(1 ≥ x ∨ x ≥ 2) in the following way:

¬(∃x)¬(1 ≥ x ∨ x ≥ 2)¬(∃x)(1 < x ∧ x < 2)¬(1 < 2)1 ≥ 2⊥Thus, it is shown that the given formula is not a theorem of pra. This

example shows that Fourier/Motzkin procedure is not complete for pia.

3.1.3 Properties of compound methods

Given a set of generated methods for some underlying theory T , they can becombined (by a human, or — as we will see — automatically) into a compoundmethod (for that theory). Compound methods (in this context) can use prim-itive methods in a sequence or in a loop (but not conditional branching). Thepreconditions of a compound method are the preconditions of the first (prim-itive) method used, and the postconditions are the postconditions of the last(primitive) method used.7

Termination. If a compound method is based on using a sequence of ter-minating methods, then it is (trivially) terminating. If it includes a loop, thensome deeper argument is required.

Soundness. Since it relies on the soundness of the used primitive methods,every compound method is also sound (both w.r.t. syntactical restrictions andw.r.t. the underlying theory T ). Meeting the syntactical restrictions of thecompound method is also ensured by its postconditions.

Completeness. If all the used methods are complete and if the compoundmethod is terminating, then it is (trivially) complete. More precisely, if a com-pound method (i) is terminating; (ii) uses only (primitive) methods which neverfail (i.e., the methods which transform any input formula to a formula belong-ing to the output class) and which use only complete rewrite rules, then thatcompound method is complete (w.r.t. T ).

Based on the above considerations, we can make a crucial observation: ifa compound method for some theory T has an input bnf set correspondingto the whole of T and a trivial output bnf set consisting only of > and ⊥,

7This way of constructing the preconditions and postconditions of a compound method isnot adequate in general (for instance, when one has conditional branching) but suffices forthe examples we were working on.

10

then it is a decision procedure for T if it is terminating, sound (w.r.t. T ), andcomplete (w.r.t. T ), while these soundness and completeness properties relyonly on properties of the rewrite rules used. This way, we can, in some case8,trivially get a proof that some (automatically generated) compound method isa decision procedure for some theory.

3.2 Simplification of bnfs

Each method generator first tries to simplify the input bnf. By “simplifying”we mean elimination of non-recursive classes. Namely, if a class (different fromthe top class) is not recursive (i.e., it does not occur in its bnf entries) then itcan be eliminated by replacing all its derivations in all positions where elementsof this class occur.

Example 4 We can eliminate the class af from the following definitionf := af |f ∨ f |f ∧ f

af := t = t|t < tand get

f := t = t|t < t|f ∨ f |f ∧ f

The need for this step is illustrated in Example 5.

Example 5 Consider the following bnf classes:

f := af |¬af |f ∨ f |f ∧ f

af := >|⊥|t = t|t < t(2)

Let us suppose that there are available the following rewrite rules:rm_neg_less: ¬(t1 < t2) −→ t2 < t1 ∨ t1 = t2rm_neg_eq: ¬(t1 = t2) −→ (t1 < t2) ∨ (t2 < t1)rm_top: ¬> −→ ⊥rm_bottom: ¬⊥ −→ >

The above rules are sufficient to eliminate ¬ from any formula belonging tothe class f from (2), but it cannot be done within the class f (i.e., ¬ cannotbe removed from the bnf definition of the class f without taking into accountother classes, as in removing the symbol ⇒). However, if we first simplify (asdescribed above) the given bnf definition, we eliminate the class af and we getthe following bnf definition:

f := >|⊥|t = t|t < t|¬>|¬⊥|¬t = t|¬t < t|f ∨ f |f ∧ f

Now we can eliminate the symbol ¬ from the class f .

3.3 Search for the Necessary Rewrite Rules

Several method generators use the same algorithm for searching for the necessaryrewrite rules. This algorithm is given in Fig. 1.

8If we generate and use some methods which do something more than rewriting, the situ-ation can be more complicated (see §9 on linear arithmetic).

11

The algorithm tries to find rewrite rules that rewrite the given bnf entry insuch a way that it belongs to the given class of the given definition or to someof its predecessor classes. Thus, if b0 is an input and b an output bnf definition,if aec(b0, e, class) and if the bnf entry e is rewritten to e′ by some rewrite rule,then it has to hold that aec(b, e′, class′), where class′ is either class, or class′

has class as its entry, according to the given bnf (so any expression of class

also belongs to class′) . The need for condition about predecessor clauses isillustrated in Example 6.

Example 6 Consider the following bnf classes:f ′ := f |f ′ ∨ f ′

f := f ∧ f |t = t|t < t|¬(t = t)|¬(t < t)Let us suppose that there are available the following rewrite rules:rm_neg_less: ¬(t1 < t2) −→ t2 < t1 ∨ t1 = t2rm_neg_eq: ¬(t1 = t2) −→ (t1 < t2) ∨ (t2 < t1)

The above rules are sufficient to eliminate ¬ from any formula belonging tothe class f ′, but it cannot be done within the class f because the construction(t < t) ∨ (t < t) does not belong to the class f . However, this constructionbelongs to the class f ′ which has f as its entry (i.e., any expression of f alsobelongs to f ′, according to the given bnf).

Thus, when we remove a symbol from a bnf class c, we have to check whetherthe obtained construction belongs to c or to some other class from which a con-struction c can be derived. This example illustrates the purpose of checking thiscondition.

The convention about considering two or more subexpressions in the sameclass to be different objects is necessary in situations like the following. Let ussuppose that there is a rewrite rule

R : F ⇔ F −→ >and that we want to rewrite the abstract syntactical expression f ⇔ f ; twooccurrences of f generally do not represent the same formula, so we must notapply the above rewrite rule (i.e., we consider that it is not applicable; in otherwords, we consider f ⇔ f as f1 ⇔ f2).

Concerning the step with “checking syntactical conditions”, note that someof the rewrite rules that the algorithm browses can have conditions. Someof those conditions may be of a syntactical nature, while some can be of asemantical nature, i.e., such conditions should be checked modulo a backgroundtheory. The above algorithm (and the whole process of generating methods)works in a purely syntactical manner and does not reason with respect to anybackground theory. This sort of condition can be checked in the final stage,when the completeness of the generated methods is examined (see p28). SeeExample 7 that illustrates these restrictions.

Example 7 Let us suppose that the class f of ground formulae is given in thefollowing way:

f := f ∧ f |n = n|n < n|true|false

where n denotes the class of numbers. If the following rewrite rules are available

12

Algorithm: Search for rewrite rules

Input: goal bnf definition b, pair (class, bnf entry)

Output: triple (class, abstract element, the rewrite rule name)

• When applying rewrite rules to abstract syntactical elements,

consider subexpressions which are of the same class as different

objects.

• Apply the following steps for selecting appropriate rewrite rules

(for producing e from the given bnf entry such that aec(b, e, class′)(where class′ is a class such that class′ has class as its entry,

according to b (so any expression of class also belongs to class′):

– if there is one unconditional rewrite rule r which meets the

above condition, then take it and attach it to the current bnf

entry, i.e., make a triple (class, bnf entry, r) which will

serve in generating the required method;

– if there is no one unconditional rewrite rule which meets the

above condition, but there are conditional rewrite rules which

meet the above condition, then check just their syntactical

conditions and attach them all to the current bnf entry, i.e.,

make a triple (class, bnf entry, the names of the rewrite

rules) which will serve in generating the required method;

– if there are no rewrite rules which meet the above condition

for some of the selected bnf entries, then report that there

are some missing rewrite rules.

Figure 1: The algorithm for search over the set of available rewrite rules

rm_ls1: n1 < n2 −→ true if number(n1), number(n2), n1 < n2

rm_ls2: n1 < n2 −→ false if number(n1), number(n2), ¬n1 < n2

then one can eliminate the symbol < from any formula from the class f. The al-gorithm 1 would find and take the above two rules when trying to build a methodthat eliminates <. However, it would only check the conditions number(n1),number(n2) and not the conditions n1 < n2 and ¬n1 < n2. Namely, the condi-tions number(n1), number(n2) are of syntactical nature and it suffices to checkthat the entity of the class n from the above bnf meets the syntactical restric-tions given by the predicate number (see p5). On the other hand, during themethod generation, concrete expressions that will be the subject of rewriting can-not be known in advance, so it is not possible to check semantical conditions,conditions modulo a background theory (such as n1 < n2) that are sensible onlyfor concrete elements.

In Example 7, for any two numbers n1 and n2, it holds that n1 < n2 or itholds that ¬n1 < n2. So, the rules rm ls1 and rm ls2 cover all possible cases,i.e., they have the coverage property, and, therefore, each expression of the formn < n can be rewritten (to true or false). However, one has to be careful withthe coverage property. Consider, for instance, the following rules:

r1: a −→ b if f(c)r2: a −→ b if ¬f(c)

13

Although it always holds that f(c)∨¬f(c), it might be the case that neitherf(c) nor ¬f(c) can be proved, and, hence, neither r1 nor r2 can be applied.

It is not difficult to see that the given algorithm for search over the set ofavailable rewrite rules is complete, i.e., if there are necessary rewrite rules fortransforming expression from one bnf into an expression of the second bnf,then the algorithm finds those rules.

3.4 General Form of the Normalisation Methods

We have two groups of method generators: generic method generators andspecial-purpose method generators. Special-purpose method generators are de-signed for use in generating some special kinds of compound methods (say quan-tifier elimination procedures). Each normalization method has the general formgiven in Fig. 2.

name: methodname;

input: f ;

preconditions: ec(b, f, top class) (where b is the input bnf definition);

transformation: exhaustive application of the set of rewrite rules (but only ap-plying to positions that correspond to the attached syntactical classes); ittransforms f to f ′;

output: f ′;

postconditions: ec(b′, f ′, top class) (where b′ is the output bnf definition).

Figure 2: General form of normalisation methods

4 Generic Method Generators

In this section we describe several kinds of normalisation methods and proce-dures which can automatically generate them. Most of these methods are basedon ideas from [5]. However, there are some differences in specification of someof them. In addition, we haven’t used and implemented some kinds of methodsfrom [5] (reorder, collect, isolate), but we introduced one new kind of method— absorb. Descriptions of method generators are somewhat simplified.

4.1 Remove Method Generator

Remove is a normalization method used to eliminate a certain function sym-bol, predicate symbol, logical connective, or a quantifier from a formula. Themethod uses sets of appropriate rewrite rules and applies them exhaustively tothe current formula until no occurrences of the specific symbol remain.

For instance, as shown in Example 2 (p7), the bnf definition (1) can betransformed to the corresponding bnf definition without the symbol ⇔.

14

Example 8 Consider the following class:f := h(a)|h(b)|g1(a)|g2(b)

where a and b are some (recursive) classes and suppose there are available thefollowing rewrite rules:

R1 : h(x) −→ g1(x)R2 : h(x) −→ g2(x)

The above rules are sufficient for eliminating the symbol h and for trans-forming the above class into the class:

f := g1(a)|g2(b)However, it cannot be reached by arbitrary use of exhaustive applications of

the given rewrite rules. Indeed, the term h(a) belongs to the class f and it canbe rewritten to g2(a) by R2, but g2(a) does not belong to the class f . Instead, therule R1 should have been used and it would give g1(a), which does belong to theclass f . The lesson is that we have to take care about which rule we use in whichsituation (i.e., for each construction of syntactical classes). This informationhas also to be built into the remove method that we want to construct (but similarconsideration holds for other kinds of methods as well).

The remove method generator is given in Fig. 3.9

The given remove method generator relies on the correctness of the algorithmfor search over the set of available rewrite rules (given in Fig. 1) and on thecorrectness of the construction of the output bnf (within the algorithm itself).This construction is simple and it is not difficult to prove that it succeeds if(and only if) there is an entry involving the given symbol, while the output bnf

has fewer classes that involve it. Termination of a generated remove method isguaranteed, as each rewrite applied reduces the number of occurrences of thegiven symbol. If all available rewrite rules are sound, the generated methodis also sound. However, recall that we still cannot claim that each generatedmethod is complete (w.r.t. its underlying theory). Namely, for some steps theremight be some conditional rewrite rules used that do not cover all possible casesor there might be some rewrite rules used that are not complete w.r.t. thisunderlying theory (see 3.1). For instance, if all required rules are found andall of them are unconditional (and complete w.r.t. the underlying theory), thenthe generated method can transform any input formula and it is also completew.r.t. the underlying theory.

When checking rewrite rules during the generation of the list of rewrite rules,note that the full check on conditions is not (and cannot be) performed (becausethe generation mechanism works in a purely syntactical way; see Example 7,p12). That is why the remove method constructed in this way may fail (i.e.,

9While generating remove methods, we could consider only rewrite rules such that theirleft hand side include and that their right hand side does not include the given symbol (thesymbol that should be removed). Instead, however, we use the general method for searchingfor appropriate rewrite rules (given in Fig. 1) with the same result. We believe that gainsfrom generality in this context outweigh the losses in efficiency. Anyway, since the generatedoutput bnf set does not include the critical symbol, it is obvious that all selected rules mustbe such that their right hand side does not include the given symbol (so recursively definedsymbols obviously cannot be eliminated this way).

15

Algorithm: Remove method generator

Input: bnf definition b, the symbol to be deleted, the set of available

rewrite rules

Output: remove method, or report on the missing rewrite rules

• Generate the output bnf set in the following way: take the input

bnf definition, find one class that has entries involving the given

symbol (let us call it the target class) delete all bnf entries

(of that class) that include the given symbol (the symbol to be

removed);

• make a set of all deleted bnf entries from the input bnf set (with

the target class), i.e., all bnf entries (of the target class) that

include the symbol to be removed;

• for each such pair ((target class, bnf entry)) call the algorithm

for searching for rewrite rules (the algorithm given in Fig. 1).

If it succeeds

– then construct a method based on exhaustive application of

selected rewrite rules;

– else report on the missing rules.

Figure 3: The algorithm for generating remove methods

its postconditions may fail) even if its preconditions are fulfilled. However,during the generation process, all relevant rewrite rules are collected and if theirconditions cover all possible cases (i.e., if they meet the coverage property), thegenerated method never fails. This holds for other kinds of methods as well.

If the given algorithm succeeds, the selected set of the rewrite rules is termi-nating (so is the constructed method). Indeed, each application of these rewriterules decreases the number of occurrences of the given symbol in the currentformula. Since this number is non-negative, this process will stop after a finitenumber of steps.

Example 9 For our example 8, the algorithm would work as follows: the setof pairs is (f, h(a)), (f, h(b)) and the goal bnf is: f := g1(a)|g2(b)

When the search algorithm is called for the pair (f, h(a)), it returns (f, h(a), R1),when it is called for (f, h(b)), it returns (f, h(b), R2). These two triples are usedfor guiding rewriting in the method generator.

Example 10 Given the following bnf definition:f := af | af |f ∨ f |f ∧ f |f ⇒ f |f ⇔ f |(∃var : sort)f |(∀var : sort)f

af := >|⊥|t = t|t < t

t := var|rc|rc · t| − t|t + t

var := x1|x2|x3| . . .sort := rational

the algorithm from Fig. 3 (implemented in prolog) generates automatically theremove method (given in Fig. 4) which removes the symbol ¬ from the class f

(sclass defines bnf classes (defined in pure syntactical terms), and inf_class

16

defines infinite classes (see §2.3); two element_of_sclass predicates definepreconditions and postconditions of the method).

——————————————————————————————–method(rm_neg,la,F,FF) :-

element_of_sclass(

[sclass(f, [f#f, f\f, f=>f, f<=>f, ~false, ~true, ~t<t, ~t=t, false,

true, t<t, t=t, var:rational##f, var:rational\\f]),

sclass(t, [var, re, -t, t+t, re*t]),

sclass(re, [rc, re+re, re*re, -re]),

sclass(var, []),

sclass(rc, []),

inf_sclass(var, _G965, [variable(_G965)]),

inf_sclass(rc, _G977, [number(_G977)])],f,F),

rewrite_wrt_bnf(la,

[sclass(f, [f#f, f\f, f=>f, f<=>f, ~false, ~true, ~t<t, ~t=t, false,

true, t<t, t=t, var:rational##f, var:rational\\f]),

sclass(t, [var, re, -t, t+t, re*t]), sclass(re, [rc, re+re, re*re, -re]),

sclass(var, []),

sclass(rc, []),


inf_sclass(rc, _G977, [number(_G977)])],

[[f, ~false, rm_bottom],

[f, ~true, rm_top],

[f, ~t<t, rm_neg_less],

[f, ~t=t, rm_neg_eq]],F,FF),

element_of_sclass(

[sclass(f, [f#f, f\f, f=>f, f<=>f, false, true, t<t, t=t,

var:rational##f, var:rational\\f]),

sclass(t, [var, re, -t, t+t, re*t]),

sclass(re, [rc, re+re, re*re, -re]),

sclass(var, []),

sclass(rc, []),


inf_sclass(rc, _G977, [number(_G977)])],f,FF).

Figure 4: Example of generated remove method (see Example 10)——————————————————————————————–

The method rewrites the input formula by using rewrite_wrt_bnf, whichdoes rewriting with respect to the given bnf. For instance, rewrite_wrt_bnfrewrites subexpressions which are of the class f (w.r.t. given bnf) and of theform ~false by using the rewrite rule rm_bottom.

Note that if some elements of the set of pairs cannot be deleted, then arequired remove method cannot be constructed. In that case, the algorithmreports such pairs, so the user could try to provide missing rewrite rules. Forinstance, if, in the above example, the rule rm_top was not available, the gener-ation mechanism would issue a report given in Fig. 5 (~ stands for ¬). It reportson the entry for which it failed to find the necessary rewrite rules (and on theother entries it still has not transformed).

As said before, we don’t claim that the given remove method generator is

17

Failed to find a rewrite rule for: [f, ~true]

Cannot synthesize required method.

Hint: try to provide required rewrite rules for the following syntactical

elements: [[f, ~true], [f, ~t<t], [f, ~t=t]]

Figure 5: Output of remove method generator when it fails

complete (i.e., that it can construct the required remove method whenever itis possible). However, this algorithm is powerful enough for the case studypresented in this paper.

4.2 Stratify Methods Generator

Stratify is a normalization method used to stratify one syntactical class intotwo syntactical classes containing some predicate or function symbols, logicalconnectives or quantifiers.

Example 11 A stratify method for moving disjunctions beneath conjunctionscan be constructed if the following rewrite rules are available:

st_conj_disj1: f1 ∧ (f2 ∨ f3) −→ (f1 ∧ f2) ∨ (f1 ∧ f3)st_conj_disj2: (f2 ∨ f3) ∧ f1 −→ (f2 ∧ f1) ∨ (f3 ∧ f1)

Given the above rewrite rules, a stratify method can be constructed such thatit can transform each formula of the class

f := af |f ∨ f |f ∧ f

into a formula of the (new) class f :f := f1|f ∨ f

f1 := af |f1 ∧ f1

Stratification methods separate one class into two classes, and in this examplethe symbol ∨ is a symbol which stays in the “upper” class (from which the newone is derived) and is a parameter for the method generator.

The algorithm for constructing stratify methods is given in Fig. 6.The given stratify method generator correctly constructs possible output

bnfs, i.e., it constructs an output bnf such that one input class is separated intotwo classes, one involving symbols from the given set, and the other involving(only) the remaining symbol from the input class. Termination of the generatedstratify method is guaranteed, as each rewrite applied reduces the number ofthe given symbols occurring “below” other symbols (in the expression beingrewritten). Soundness and completeness features of generated stratify methodsare similar to generated remove methods (see also 3.1).

Example 12 Stratify methods can also serve for reordering elements within anexpression. For instance, a stratify method can use the following rule (togetherwith other necessary rules):

18

Algorithm: Stratify method generator

Input: bnf definition b; rewrite rules; the set of symbols s (the

symbols from s will be in the upper class)

Output: the method in standard form (using the set of triples (class,

abstract element, the rule name)) or fail

• Generate the output bnf set in the following way:

– find a class c in b such that it involves all symbols from s.

– introduce a new class c1

– from the input set take only those entries for c which involve

symbols from s; also add the entry c1;

– all entries for c that weren’t used above, use as entries for

c1, but with all occurrences of c renamed to c1.

• Make a set of ‘‘problematic’’ bnf constructions in the following

way:

– make a set of all bnf entries for c1 that include c1; in each

such bnf entry replace one occurrence of c′ by one entry for

c (different from c1) and then replace all occurrences of c by

c1; do that in all possible ways and make a list of pairs (c, e)of all for all such syntactic constructions e.

• For each element in the list, call the search algorithm with that

element and the output bnf set as parameters.

• If the search algorithm succeeds, then it returns the triple (head

class, bnf entry, the name of the rewrite rule); delete that

element from the current list and add the obtained triple to the

output list.

Figure 6: The algorithm for generating stratify methods

reorder_plus8: c0 · x0 + c · v −→ c · v + c0 · x0 if v is a variabledifferent from x0

in order to stratify x0 and rearrange a polynomial in such a way that its sum-mands involving x0 will be at the end of the expression.

4.3 Thin Method Generator

Thin is a normalization method that eliminates multiple occurrences of a unarylogical connective or a unary function symbol. For instance, we can use thefollowing rewrite rule:

¬¬f −→ f

in order to transform each formula belonging tof := af |¬f

to a formula belonging tof := af |¬af

The algorithm for constructing thin methods is given in Fig. 7.

19

Algorithm: Thinning method generator

Input: bnf definition b; rewrite rules; the symbol F to be ‘‘thinned’’



• Select a bnf class c such that it has the entry F (c) and that it

does not have any other entry that involves c

• Generate the output bnf set in the following way: delete the entry

F (c), and for each other entry e add the entry F (e)

• Check if there is a rewrite rule R of the form:

F (F (x)) −→ x

If there are such rewrite rule, then form the triple (c, F(F(c)),

R) (it is of the form (head class, bnf entry, the name of the

rewrite rule)) and use it for building the method in a standard

form; otherwise fail.

Figure 7: Generator for thinning methods

The given thin method generator correctly constructs output bnf: it con-struct an output bnf by eliminating an entry F (c) and replacing it by (orkeeping) an entry F (e) (as denoted in the algorithm). If the method generatorsucceeds, the selected rewrite rule is obviously terminating (each applicationof the rule decreases the number of occurrences of symbol F by 2), and so isthe constructed method. Soundness and completeness (w.r.t. the underlyingtheory) rely on the properties of the rewrite rules available/used (see also 3.1).

4.4 Absorb Method Generator

Absorb is a normalization method that can eliminate some recursion rules. Forinstance, we can use the following rewrite rule:

rm_mult c1 · c2 −→ c3 if c3 = c1 · c2

in order to transform each term belonging tot := t · rc|rc (where rc denotes rational constants) to a term belonging

tot := rc

The algorithm for constructing absorb methods is given in Fig. 8.

Example 13 Consider the following class:t := t · rc|rc|var

Using the notation from the given algorithm, A = t · rc, B = rc, C =rc, var. According to the algorithm, the new definition of the class t will be:

t := var · rc|rc|var

while the necessary rewrite rules are of the form:rc · rc −→ rc

(t · rc) · rc −→ t · rc

20

Algorithm: Absorb method generator

Input: bnf definition b; rewrite rules; a function symbol of connective

F.



• Select a bnf class c such that all its entries are either of the

form F (c, ci), F (ci, c) (for some function symbol or a connective F;

ci are not equal to c) or does not have c. Let: A be the set of

all F (c, ci) and F (ci, c) entries (for that class); B the set of all

ci, C the set of all entries apart from those in A.

• Generate the output bnf set such that its set of entries for c is

equal to

C ∪⋃

e∈A,g∈C\B

e[c 7→ g]

• Check if there are the following rewrite rules:

– for all ci ∈ B, cj ∈ B:

F (ci, cj) −→ ck

such that ck ∈ B.

– if the set C \ B is nonempty, for all ci ∈ B, cj ∈ B:

F (F (c, ci), cj) −→ F (c, ck)

such that F (c, ci), F (c, cj), F (c, ck) ∈ A and ck ∈ B

– if the set C \ B is nonempty, for all ci ∈ B, cj ∈ B:

F (cj , F (ci, c)) −→ F (ck, c)

such that F (ci, c), F (cj , c), F (ck, c) ∈ A and ck ∈ B

If there are such rewrite rules, then form the rewrite triples

and use them for building the method in a standard form; otherwise

fail.

Figure 8: Generator for absorb methods

The given absorb method generator constructs an output bnf with fewerrecursive rules (than the input bnf). Termination of the generated absorbmethod is guaranteed, as each application of the selected rewrite rules decreases(by 1) the number of occurrences of the symbol F (as denoted in the algorithm).Soundness and completeness features of generated absorb methods are similarto the generated remove and stratify methods, i.e., they rely on the propertiesof the selected rewrite rules (see also 3.1).

4.5 Left − assoc Method Generator

Left-assoc is one of the normalization methods for reorganising within a class.If a syntactical class contains only one function symbol or a connective and ifthat symbol is both binary and associative, then members of this class can beput into left associative form using the method left-assoc. For instance, we willneed the left association of addition and the left association of conjunction.

21

Example 14 We can transform the following classf := f ∧ f |>|⊥

into the following classf := f ∧ >|f ∧ ⊥|>|⊥

by the use of the following rewrite rule:left_assoc_conj: f1 ∧ (f2 ∧ f3) −→ (f1 ∧ f2) ∧ f3

The algorithm for constructing left-assoc methods is given in Fig. 9.

Algorithm: Left-assoc method generator

Input: bnf definition b; rewrite rules; the symbol F to be processed



• Select a bnf class c such that it has the entry F (c, c)

• Generate the output bnf set in the following way: delete the entry

F (c, c), and for each other entry e add the entry F (c, e)

• Check if there is a rewrite rule R of the form:

F (x, F (y, z)) −→ F (F (x, y), z)

If there are such rewrite rule, then form the triple (c,

F(c,F(y,z)), R) (it is of the form (head class, bnf entry, the

name of the rewrite rule)) and use it for building the method in a

standard form; otherwise fail.

Figure 9: Generator for left-assoc methods

The given left-assoc method generator simply constructs an output bnf witha symbol F (as denoted in the algorithm) put in left associative form. If themethod generator succeeds, the constructed method is terminating (as the se-lected rewrite rule is terminating). Soundness and completeness w.r.t. the un-derlying theory rely on the properties of the rewrite rules available/used (seealso 3.1).

5 Search Engine for Synthesizing Decision Pro-

cedure

Given some method generators, a bnf description of a theory T and a set ofcorresponding rewrite rules, a user can go step by step and try to combinedifferent generated methods. Moreover, an automatic search for compoundmethods or for a decision procedure for T can be performed. The goal of thesearch process is to generate a sequence of methods such that:

• the output bnf class of the non-final method is the input bnf class of thenext method in the sequence;

22

• the output bnf class of the last method in the sequence is a goal bnf, forinstance, the trivial bnf — consisting of only two entries (> and ⊥ forthe top bnf class).

We will define the search procedure, which is based on a size of bnf andon a heuristic which controls it. The search procedure tries to find a sequenceof methods that consists of subsequences, such that each of them is of lengthless than or equal to a given value M and such that each of them decreasesthe measure of the current bnf. The motivation for this heuristic is as follows:we (normally) look for a sequence of methods that reduces the (appropriatelydefined) size of the input bnf. Within that sequence, it might be the case thatsome steps do not decrease the size of the current bnf. However, as the wholeof the required procedure decreases the size of bnf, there must be subsequencessuch that their last element has lower bnf size than the first one (i.e., each ofthese subsequences decreases the size of the current bnf). The maximal allowedlength of these subsequences is controlled by the value M . So, in the generatedprocedure there might be some bnf size increasing steps, but the whole of theprocedure would be built from subsequences of length less or equal to M , andeach of them will be bnf size decreasing. It is not likely that M = 1 is a goodchoice (i.e., usually not all steps decrease bnf size). The value M = 3 can begood.

The size of bnf definition is a heuristic measure and we define it as follows:

• the size of a bnf definition is equal to the sum of sizes of all its entries;

• the size of the entry c := c′ is defined as follows:

– each symbol c in c′ adds 100 to the size of c;

– each symbol c′′ (where c′′ is some other class than bnf) adds 10 tothe size of c;

– each other symbol adds 1 to the size of c.

As said, this is a heuristic measure and it can be defined in some otherway. Defined this way, it forces the search engine to try to get rid of recursiveclasses,10 and then of the classes which involve some other classes. The trivial,goal bnf class (consisting of only f := >|⊥) has the size 2.

Example 15 The size of the following bnf definition (corresponding to groundarithmetic):

f := af |¬f |f ∨ f |f ∧ f |f ⇒ f |f ⇔ f

af := >|⊥|t = t|t < t|t > t|t ≤ t|t ≥ t|t 6= t

t := rc| − t|t · t|t + tis 1556.

The size of bnf definition 1 is 2233.

The search algorithm (in a somewhat simplified form) is given in Fig. 10.

10Note that, within the current scope of our system, we don’t deal with mutual recursion(that can be problematic in many aspects).

23

Algorithm: Search engine for compound methodsInput:

starting bnf definition b,goal bnf definition b′,maximal length a sequence M,maximal length of a current subsequence m,goal bnf size S for a current subsequence,prefix sequence of methods p,rewrite rules,method generators

Output:

sequence of generated methods (the input bnf class of the first method isb, the output bnf class of the last method is b′)

• if m = 0, then return with failure;

• for all possible and successful applications of all available methodgenerators (with the input bnf for methods equal to b)

– let nb be equal to the output bnf of the newly generated method;

– let q be p concatenated by the newly generated method;

– if nb is equal to b′ then report success and return the currentsequence of methods (q);

– let S′ is the size of nb; if S′ < S

∗ then call recursively this algorithm with starting bnf definitionnb, goal bnf definition b′, numbers M and M, q, rewrite rules,and method generators as input parameters; if it succeeds, thenattach its resulting sequence of methods at the end of q;

∗ else call recursively this algorithm with starting bnf definitionnb, goal bnf definition b′, numbers M and m − 1, q, rewriterules, and method generators as input parameters; if it succeeds,then attach its resulting sequence of methods at the end of q;

• return and report no more solutions.

Figure 10: The algorithm for search over the set of available methodgenerators

The search algorithm is initially invoked with the starting bnf definitionwhich corresponds to the whole of the theory T , the trivial goal bnf (consistingonly of > and ⊥), a value M (M is a chosen value, say, 3), the size of the startingbnf, the empty sequence of methods, and with the set of available (or chosen)rewrite rules and method generators. The given algorithm can be modified insuch a way that it stops when it finds the first sequence of methods which meetsthe given conditions. Also, the algorithm can be modified in such a way thatinstead of a specific target bnf b′, the input parameter is some condition on thegoal bnf definition (e.g., “target bnf does not have variables”).

The ordering of method generators is not important for termination andcorrectness of the given search algorithm, but it is important for its efficiency.We used the following ordering: remove, thin, absorb, stratify, left_assoc.This ordering is based on the nature of these methods (and how they changethe bnf size) and on different tests. When generating all possible methods,

24

all acceptable parameters for method generators have to be generated too. Allpossible parameters are generated from the list of all connectives, function andpredicate symbols used in the given bnf. For generators that take sets of sym-bols, these sets are made as subsets of all symbols.11

Given a finite number of method generators and a finite number of rewriterules, at each step a finite number of methods can be generated (there is alsoa finite number of possible parameters). Thus, since the algorithm producessubsequences (of maximal length M) of decreasing sizes (natural numbers) ofcorresponding bnf definitions, the given algorithm obviously terminates. Ifmethod generators can generate all methods necessary for building the requiredcompound method, then the given algorithm can build one such compoundmethod (for M large enough). If we iterate the given algorithm (for M =1, 2, 3, . . .), then it will eventually build the required compound method (if it ispossible to build it using the method generators), so that the iterated algorithmis also complete. However, we can also use it only with particular values for M

(then the procedure is not complete, but it obviously gives much better resultsif it used only for an appropriate value for M).

6 Ground Arithmetic

We ran the algorithm given in Fig. 10 (p24), on the bnf definition given inExample 15 (p23), with M = 3, with the described method generators, andwith rewrite rules available in Appendix A. We set the goal bnf definition tobe the trivial one (f := >|⊥), thus aiming at synthesizing a decision proceduresfor ground arithmetic.

The search algorithm took 3.22 seconds of cpu time12 and during the searchthere were 48 methods successfully generated (while there are 22 of them in thefinal sequence). The search algorithm produced the sequence of methods DP_GAwith the following “overview” (# denotes conjunction and \ denotes disjunction;the symbol (*) denotes the end of a bnf size decreasing sequence):

——————————————————————————————–

1 remove <=>; Target class: f;

Rules:[[f, f<=>f, rm_equiv]];

Input size: 1556 Output size : 1345 (*)

2 remove =>; Target class: f;

Rules:[[f, f=>f, rm_impl]];


3 remove leq; Target class: f;

Rules:[[f, leq(t, t), rm_leq]];


4 remove geq; Target class: f;

Rules:[[f, geq(t, t), rm_qeq]];

11One of the specific method generators renames the innermost variable of the input formulato x0. This distinguished variable name is also used as a possible parameter for generatedmethods.

12The system is implemented in swi Prolog; experiments were run on a 256Mb PC 2.4Ghz.

25


5 remove neq; Target class: f;

Rules:[[f, neq(t, t), rm_neq]];


6 remove >; Target class: f;

Rules:[[f, t>t, rm_gr]];


7 remove -; Target class: t;

Rules:[[t, -t, rm_minus]];


8 stratify [#, \]; Target class: f;

Rules:[[f, ~(f#f), st_neg_conj], [f, ~(f\f), st_neg_disj]];

Input size: 959 Output size : 969

9 thin ~; Target class: f1;

Rules:[[f1, ~(~f1), thin_neg]];


10 remove ~; Target class: f;

Rules:[[f, ~false, rm_bottom], [f, ~true, rm_top],

[f, ~t<t, rm_neg_less], [f, ~t=t, rm_neg_eq]];


11 stratify [\]; Target class: f;

Rules:[[f, f#f\f, st_conj_disj1], [f, (f\f)#f, st_conj_disj2]];


12 stratify [+]; Target class: t;

Rules:[[t, t*(t+t), st_mult_plus1], [t, (t+t)*t, st_mult_plus2]];


13 left_assoc \; Target class: f;

Rules:[[f, f\f, left_assoc_disj]];


14 left_assoc +; Target class: t;

Rules:[[t, t+t, left_assoc_plus]];


15 left_assoc *; Target class: t1;

Rules:[[t1, t1*t1, left_assoc_mult]];


16 absorbe *; Target class: t1;

Rules:[[t1, rc*rc, rm_mult]];


17 absorbe +; Target class: t;

Rules:[[t, rc+rc, reduce_plus]];


18 remove <; Target class: f1;

Rules:[[f1, rc<rc, rm_ls1], [f1, rc<rc, rm_ls2]];


19 remove =; Target class: f1;

Rules:[[f1, rc=rc, rm_eq1], [f1, rc=rc, rm_eq2]];


20 left_assoc #; Target class: f1;

Rules:[[f1, f1#f1, left_assoc_conj]];


21 remove #; Target class: f1;

Rules:[[f1, f1#false, reduce_bool3], [f1, f1#true, reduce_bool1]];


22 remove \; Target class: f;

Rules:[[f, f\false, reduce_bool4], [f, f\true, reduce_bool2]];


——————————————————————————————–

26

In the presented overview we give the kind, parameters, target class, thetriples with selected rewrite rules, and input and output size. Note that weshow the input bnf size after and not before simplification (so the output sizeis not necessarily equal to the input size of the next one.

In Fig. 11 we illustrate work of the given procedure DP_GA on one example —we give a sequence of formulae produced by the methods for the input formula¬(7 ≤ 5) ⇒ ¬(2 · (1 + 3) ≥ 3).

——————————————————————————————–

1 ~leq(7, 5)=> ~geq(2*(1+3), 3)

2 ~(~leq(7, 5))\ ~geq(2*(1+3), 3)

3 ~(~(7<5\7=5))\ ~geq(2*(1+3), 3)

4 ~(~(7<5\7=5))\ ~(3<2*(1+3)\2*(1+3)=3)

5 ~(~(7<5\7=5))\ ~(3<2*(1+3)\2*(1+3)=3)

6 ~(~(7<5\7=5))\ ~(3<2*(1+3)\2*(1+3)=3)

7 ~(~(7<5\7=5))\ ~(3<2*(1+3)\2*(1+3)=3)

8 (~(~7<5)\ ~(~7=5))\ ~3<2*(1+3)# ~2*(1+3)=3

9 (7<5\7=5)\ ~3<2*(1+3)# ~2*(1+3)=3

10 (7<5\7=5)\(2*(1+3)<3\3=2*(1+3))#2*(1+3)<3\3<2*(1+3)

11 (7<5\7=5)\((2*(1+3)<3#2*(1+3)<3)\3=2*(1+3)#2*(1+3)<3)\

(2*(1+3)<3#3<2*(1+3))\3=2*(1+3)#3<2*(1+3)

12 (7<5\7=5)\((2*1+2*3<3#2*1+2*3<3)\3=2*1+2*3#2*1+2*3<3)\

(2*1+2*3<3#3<2*1+2*3)\3=2*1+2*3#3<2*1+2*3

13 ((((7<5\7=5)\2*1+2*3<3#2*1+2*3<3)\3=2*1+2*3#2*1+2*3<3)\

2*1+2*3<3#3<2*1+2*3)\3=2*1+2*3#3<2*1+2*3

14 ((((7<5\7=5)\2*1+2*3<3#2*1+2*3<3)\3=2*1+2*3#2*1+2*3<3)\

2*1+2*3<3#3<2*1+2*3)\3=2*1+2*3#3<2*1+2*3

15 ((((7<5\7=5)\2*1+2*3<3#2*1+2*3<3)\3=2*1+2*3#2*1+2*3<3)\

2*1+2*3<3#3<2*1+2*3)\3=2*1+2*3#3<2*1+2*3

16 ((((7<5\7=5)\2+6<3#2+6<3)\3=2+6#2+6<3)\2+6<3#3<2+6)\3=2+6#3<2+6

17 ((((7<5\7=5)\8<3#8<3)\3=8#8<3)\8<3#3<8)\3=8#3<8

18 ((((false\7=5)\false#false)\3=8#false)\false#true)\3=8#true

19 ((((false\false)\false#false)\false#false)\false#true)\false#true

20 ((((false\false)\false#false)\false#false)\false#true)\false#true

21 ((((false\false)\false)\false)\false)\false

22 false

Figure 11: Sequence of formulae produced by the methods in a decision proce-dure for ground arithmetic (DP GA)

——————————————————————————————–

The procedure DP_GA is sound and terminating (as all generated methodsare sound and terminating and there is no loop). Note, however, that we don’tclaim that it is complete as there are some conditional rewrite rules used. Forinstance, in step 16 of the procedure DP_GA, the conditional rule rm_mult isused, but it is still not shown that its condition covers all possible cases, whichthe user can show by proving:

(∀c1 : rational)(∀c2 : rational)(∃c3 : rational)(c3 = c1 · c2)

In step 17 of the procedure DP_GA, the conditional rule reduce_plus is used,

27

but it is still not shown that its condition covers all possible cases, which theuser can show by proving:

(∀c1 : rational)(∀c2 : rational)(∃c3 : rational)(c3 = c1 + c2)

It is very easy to prove that the above conjectures are theorems of pra.Moreover, the second one can be proved by the decision procedure DP_LA forlinear arithmetic (which we also automatically generated and we report on thatin the subsequent text).

As another example, in step 19, the conditional rewrite rules rm_eq1 andrm_eq2 are used, but it is not shown that their conditions cover all possiblecases, which the user can show by proving that for any two rational numbersc1 and c2, either c1 = c2 or ¬(c1 = c2) can be proved as a theorem of lineararithmetic (i.e., there always holds one of them, and one can decide which).Notice that this is not equivalent to a conjecture:

(∀c1 : rational)(∀c2 : rational)(c1 = c2 ∨ ¬(c1 = c2))

but is rather a metha-theorem of linear arithmetic. However, for all these con-jectures (concerning the coverage property) the user can easily ensure they arevalid.

This leads us to conclude that the procedure DP_GA is correct.

Theorem 1 The procedure DP_GA for ground arithmetic is terminating, soundand complete, i.e., it is a decision procedure for ground arithmetic.

Proof sketch. Since all methods in DP_GA use only sound and completerewrite rules, all of them are sound and complete, and hence, the whole of theprocedure is sound and complete. In each method, either unconditional rulesare used or conditional rules that cover all possible cases. Thus, all methodsalways succeed. As discussed in the previous text, each of the used methodsis terminating. There are no loops, so termination of individual methods issufficient for termination of DP_GA. All in all, the procedure DP_GA terminates,it transforms an arbitrary input (ground arithmetic) formula Φ into the resultingformula > or ⊥, while the resulting formula is > if and only if Φ is a theoremin ground arithmetic.

7 Special-Purpose Method Generators

In this section we describe four special-purpose method generators. The firstone of them (adjusting the innermost quantifier) can be used for a quantifierelimination procedure for any theory, while the remaining three are specific forlinear arithmetic. Note, however, that it is essential to have these generators(despite they are theory-specific): they can be used in an automatic searchprocess and generate the required methods with the given preconditions (whichare not known in advance).

28

7.1 Method Generator for Adjusting the Innermost Quan-

tifier

This generator generates a method which transforms a formula in prenex normalform (and with variables) in the following way: if its innermost quantifier isexistential, then keep it unchanged; if its innermost quantifier is universal, thenrewrite the formula

(Qx1)(Qx2) . . . (Qxn)(∀x)f

to a formula

(Qx1)(Qx2) . . . (Qxn)¬(∃x)¬f

by using the following rewrite rule:rm_univ: (∀x)f −→ ¬(∃x)¬f

The motive of this method is to deal only with elimination of existentialquantifiers.

This method is generated in such a way that it also always (both when the in-nermost quantifier is universal and when the innermost quantifier is existential)renames the innermost variable to x0, assuming that there was no a variable x0

already (if there is, then that variable will be renamed). That way it is alwayseasily known what variable is the innermost one.

7.2 One-side Method Generator

This generator generates (if the input bnf admits that) a method which trans-forms all (linear arithmetic) literals (with given predicate symbols) in such away that each of them has 0 as its second argument. For instance, if we takesymbols <, >, ≤, 6=, ≥, = as parameters, then after applying that generatedmethod each literal (that had one of these predicate symbols) will have one ofthe following forms: t < 0, t > 0, t ≤ 0, t 6= 0, t ≥ 0, t = 0.

Example 16 The following rulesone_side1: t1 = t2 −→ t1 + (−1) · t2 = 0 if t2 6= 0one_side2: t1 < t2 −→ t1 + (−1) · t2 < 0 if t2 6= 0

are sufficient to transform all literals to one-side form if they have only predicatesymbols = and <.

7.3 Method Generator for Isolating a Variable

This generator generates (if the input bnf admits that) a method which isolatesa distinguished variable x0 in all (linear arithmetic) literals (that distinguishedname is normally introduced by the method that adjust the innermost quanti-fier). After applying that method, each of the literals either does not involve x0

or has one of the forms: νx0 = γ, x0 = γ, λx0 < α, x0 < α (where x0 is theinnermost quantifier). This method will use such rewrite rules as:

isolate2: t + x0 = 0 −→ x0 = −t

isolate3: t + c · x0 < 0 −→ c · x0 < −t

29

7.4 Method Generator for Removing a Variable

The, so-called, cross multiply and add step is an essential step of the Fourier/Motzkinstyle procedure. It is applied in situations where the current formula is in prenexnormal form (while ¬ can precede the innermost quantifier if it is an existentialone), its quantifier free part is in disjunctive normal form (or negation of dis-junctive normal form) and in each disjunct, each of the literals either does notinvolve x0 or has one of the forms: νx0 = γ, x0 = γ, λx0 < α, x0 < α (where x0

is the innermost quantifier). It consists of the following steps for each disjunct:

• if there is an equality of the form νx0 = γ where ν 6= 0 (or x0 = γ

for ν = 1), then rewrite each atomic formulae of the form νix0 = γi

to νiγ = νγi, rewrite each atomic formulae of the form λix0 < αi toλiγ < ναi (if ν > 0) and to λiγ > ναi (if ν < 0), and then delete theliteral νx0 = γ; that is, rewrite

νx0 = γ ∧∧

k

νkx0 = γk ∧∧

i

λix0 < αi ∧∧

l

φl

(where φl are literals not involving x0) to (if ν > 0):

∧

k

νkγ = νγk ∧∧

i

λiγ < ναi ∧∧

l

φl

or to (if ν < 0):

∧

k

νkγ = νγk ∧∧

i

λiγ > ναi ∧∧

l

φl

• if there is no equality of the form νx0 = γ, then for each pair of literalsλix0 < αi, µjx0 < βj (where λi > 0 and µj < 0) add the new literalλiβj > µjαi, and then delete all literals of the form λix0 < αi, µjx0 < βj ;that is, rewrite

∧

i

λix0 < αi ∧∧

j

µjx0 < βj ∧∧

l

φl

(where λi > 0, µj < 0, and φl are literals not involving x0) to

∧

i,j

λiβj > µjαi ∧∧

l

φl

After performing this step, the variable x0 does not occur in the currentformula and so the corresponding quantifier can be deleted.

It is not very difficult to prove that this transformation is both sound andcomplete for pra [9].

We have implemented the generator which takes a given bnf and tries tobuild a method which performs the cross multiply and add step to formulaebelonging to that bnf.

30

8 Compound Search Engine for Synthesising De-

cision Procedures

The search for a decision procedure based on quantifier elimination is performedin three stages:

• the first stage is reaching the bnf for which the method for adjusting theinnermost quantifier (changing the innermost universal quantifier into anexistential one) is applicable (i.e., reaching a formula in prenex normalform that has quantifiers);

• the second stage continues while the variable elimination method is appli-cable (in each loop one variable is being eliminated); note that the outputbnf of this stage has to be a subset of its input bnf;

• the third stage starts with the output bnf of the first stage, but withall entries involving variables and quantifiers deleted (it is the bnf of thecurrent formula after the loop described as the second stage); its goal bnf

definition is the trivial one (i.e., consisting only of > and ⊥).

For each of these stages we use the algorithm given in Fig. 10 (p24) (modifiedin order to accept not only a fixed goal bnf definition, but also weaker specifiedbnf).

In this search procedure we use all method generators with priority given tothe special-purpose method generators.

This compound search is aimed at synthesizing decision procedures basedon quantifier elimination. For other underlying techniques or domains, newcompound search mechanisms should be defined.

9 Linear Arithmetic

We used the approach described in the previous section on the bnf definitiongiven in Example 1 (p5), with M = 3 for the first and the third stage, withM = 5 for the second stage13, with all described method generators, and withthe rewrite rules given in Appendix A.

The search algorithm took 5.4 seconds of cpu time and during the searchthere were 89 methods successfully generated (while there are 51 of them in thefinal sequence). The search algorithm produced a sequence of methods, i.e., aprocedure DP_LA, with the “overview” given in Appendix B (p41) (dashed linesdivides three stages; ## denotes universal quantifier and \\ denotes existentialquantifier).

In Appendix C, we illustrate the work of the generated procedure DP_LA onone example — we give a sequence of formulae produced by the methods forthe input formula (∃x : rational)(x > 0).

13For lower values of M the system failed to generate the required procedure.

31

Theorem 2 The procedure DP_LA for linear arithmetic (given in Appendix B(p41) is terminating, sound and complete, i.e., it is a decision procedure forlinear arithmetic.

Proof sketch. Each of individual methods used in the generated procedureDP_LA is terminating. Since each loop eliminates one variable and since there area finite number of variables in the input formula, the loop terminates. Hence,the procedure DP_LA is terminating.

Since all methods in DP_LA use only sound rewrite rules, all of them aresound, and hence, the whole of the procedure is sound.

The completeness relies on completeness of the rewrite rules used, but alsoon coverage property for the methods that use conditional rewrite rules. It iseasy to see (similarly as in the generated procedure for DP_LA) that all requiredcoverage properties are fulfilled. (moreover, some of the coverage properties canbe proved by the generated procedure itself, which is, of course, acceptable,as we know that the procedure is sound). Therefore, in each method, eitherunconditional rules are used or conditional rules that cover all possible cases.Thus, all methods always succeed and all methods are complete. Hence, theprocedure DP_LA is complete (see also subsection 3.1).

All in all, the procedure DP_LA terminates, it transforms an arbitrary in-put (linear arithmetic) formula Φ into the resulting formula > or ⊥, while theresulting formula is > if and only if Φ is a theorem in linear arithmetic.

We don’t claim that the generated procedure DP_LA is the shortest or themost efficient one. However, we doubt that a decision procedure for linear arith-metic can be described correctly in some much shorter way. It also shows thatit might be non-trivial for a human programmer to implement this procedurewithout flaws and bugs (even with provided the code for the key step: crossmultiply and add). Namely, we believe that any implementation (at least, anyunderstandable implementation) of Fourier/Motzkin’s procedure has around 50steps, and, despite the fact that the step cross multiply and add is the mostcomplex one, the probable flaws are rather in correctly combining the remain-ing steps.

10 Additional Examples

The proposed approach can be used for extensions of linear arithmetic with userdefined facts.

Example 17 A “positive difference” function p(x, y) is defined in the followingway:

p(x, y)def=

x − y, if x ≥ y

0, if x < y(3)

By using the conditional rewrite rules:

p(x, y) −→ x − y if x ≥ y

p(x, y) −→ 0 if x < y(4)

32

we can synthesize a decision procedure for linear arithmetic augmented by thefunction p.

The system presented in this paper can be used not only for producing deci-sion procedures, but also different normalisation procedures (and help in imple-menting routine procedures, but procedures still very much subject to makingimplementation flaws). The following example illustrates one such normalisa-tion for the theory of lists.

Example 18 Let us consider the following bnf:

t := nil|var|append(t, t)|rev(t)|qrev(t, t)var := x1|x2|x3| . . .

(5)

and the set of rewrite rules:

qrev(x, y) −→ append(y, rev(x))rev(append(x, y)) −→ append(rev(y), rev(x))

rev(rev(x)) −→ x

append(x, append(y, z)) −→ append(append(x, y), z)

(6)

Our system can be used to produce the following normal form:

t := nil|var|rev(nil)|rev(var)|append(t, nil)|append(t, var)|append(t, rev(nil))|append(t, rev(nil))

var := x1|x2|x3| . . .(7)

The normalisation consists of the following steps:1. remove qrev

2. stratify append

3. thin rev

4. left-assoc append

The approach can be also used for constructing procedures for computingderivations, differentials and other similar operations over elementary functions.

In a similar manner, we believe that it will be possible to construct a cut-elimination procedure for Gentzen’s sequent calculus [8] or, at least, fragments(e.g., propositional fragment) of such a procedure (that is a nice example ofplausible normalisation). That application of our system is the subject of ourcurrent investigation.

11 Realm of the Approach and Further Automa-

tion

In §5 and §7 we presented a range of method generators. In each of them, weuse a method kind, input bnf and some set of rewrite rules, and used them

33

to generate a required method (with some output bnf). However, it would befruitful if we could start with an input bnf and look at bnfs (and also methods)which could be obtained by subsets of the available rewrite rules. Thus, it isinteresting to consider whether for a given bnf and a set of (terminating) rewriterules we can always compute the output bnf. This general problem is thesubject of our current research and there are techniques that cover many cases.However, the answer for the general case is negative, since, in a general case,the resulting set of expressions (obtained from the initial set of expressions byexhaustive rewriting) is not necessarily definable by a bnfs (i.e., by a context-free grammar).

Given a terminating set of unconditional rewrite rules R, let R(x) denotethe result of exhaustive application of rules from R to the expression x.

Example 19 Let T be a bnf class defined in the following way:

T := f(a, f(c, b))|f(f(a, T ), f(c, b))

Let R be a set consisting of the following rewrite rules:

r1 : f(x, f(y, z)) −→ f(f(x, y), z)

r2 : f(f(x, c), b) −→ f(f(x, b), c).

The above set of rewrite rules is, obviously, terminating. Let L′ be the set ofnormal forms of instances of T under the exhaustive application of the set R.L′ is not context-free.

If t is derived from T , then t was generated by applying the second productionrule m times (m ≥ 0) and then the first production rule once. It can be easilyproved that t has 3m + 2 occurrences of the symbol f and m + 1 occurrences ofeach of symbols a, b and c. Also, all occurrences of the symbols a precede alloccurrences of symbols b and c.

The exhaustive application of r1 transforms t into t′, while t′ is in left-associative normal form (while all occurrences of the symbols a still precede alloccurrences of the symbols b and c). So, the term t′ is of the form:

f(f(f(. . . (f︸︷︷︸

3m+2

(a, a), a), . . . , a)︸︷︷︸

m+1

, c), b), c), b), . . . , c), b)︸︷︷︸

2m+2

The exhaustive application of r2 “moves” all occurrences of the symbol b

leftwards, “through” occurrences of the symbol c and the term t is of the form:

f(f(f(. . . (f︸︷︷︸

3m+2

(a, a), a), . . . , a)︸︷︷︸

m+1

, b), b), . . .), b︸︷︷︸

m+1

), c), c) . . . , c︸︷︷︸

m+1

)

However, the set of such terms is not context-free (which can be easily provedby the pumping lemma for context-free languages [7]).

The above example shows that given a bnf and a terminating set of rewriterules, the resulting (normalised) language might not be definable by a bnf.

34

Hence, since the output is not always definable by a bnf, there is no algorithmwhich always construct the resulting bnf.

Even if there is an algorithm that (given a bnf and a terminating set ofrewrite rules) constructs an output bnf whenever it is possible, it would stillnot ensure further automation of our programme. Indeed, even if we have suchan algorithm it might still not be of operational use. For instance, if want tosynthesize a decision procedure, we would generate a sequence of bnfs lookingfor a trivial one (consisting of only > and ⊥) and, so, we would need to checkwhether two bnfs give the same language, but that problem is undecidable ingeneral. Therefore, it is likely that we cannot have a complete procedure forsynthesizing decision procedures. On the other hand, extensions of our systemalong the discussed lines, might improve our current heuristic solutions andhence are the subject of our future research.

As said above, there is no system that can always produce the output bnf

(since at some situations there is no one). So, the proposed system cannotbe extended by some new additional method generators in order to becomecomplete. Of course, the realm of the approach extends as the number of methodgenerators extends. The current set of method generators defines the currentrealm of the proposed system. The system is heuristic, so it is difficult to makea formal characterisation of its realm. It is likely and expected that it cansynthesize procedures that are based on rewriting and that consist of methodsof the available kinds.

In synthesizing decision procedures, the approach does not distinguish if thetheory is a combination of some simpler theories or not. Thus, the problemof combining decision procedures (for combination of decidable theories) is notaddressed: if there are synthesized decision procedures for component theories,these cannot be combined. A decision procedure for a combination theory canbe synthesized only if it as a whole can be described in terms of normalisationmethods.

12 Related Work

Our approach is based on ideas from [5] and apart from that strong link, as weare aware of, it can be considered basically original.

The work presented is related to Knuth-Bendix completion procedure [12]and its variants in a sense that it performs automatic construction of decisionprocedures. However, there are significant differences. While the completionprocedure produces a confluent and terminating set of rewrite rules, and hencea way how to reach a normal form, it does not give a description of the wholeof the normal forms. In contrast, our system does not necessarily producea decision procedure (or a normalisation procedure) whenever the completionprocedure does, but when it produces a decision procedure, it also providesthe finite description of the output (normalised) language (something that thecompletion procedure does not give). In addition, the completion procedureproduces procedures that are based on exhaustive applications of rewrite rules,

35

while our system produces procedures that are based successive rule sets and,can generate a procedure for conjunctive normal form, which cannot be doneby a single rule set. Also, a procedure divided into a number of steps is moreeasy understandable to a human then a single step procedure. We believe thatit would be worthwhile to combine our work with the Knuth-Bendix completionprocedure in the following way: the completion procedure can be used to finda confluent and terminating rule set and then use adeptus to describe thenormal form it produces; on that basis one can build methods with before andafter bnfs as the preconditions and post-conditions of a new method describingthe rewrite rule set.

As it addresses the automatic construction of decision procedures our workis also related to work presented in [1]. That work is aimed at deriving decisionprocedures using superposition-based inference system for clausal equationallogic. The approach is an alternative for congruence closure algorithm and forthe Knuth-Bendix completion procedure. It can handle not only pure equality,but also some other axiomatic equational theories such as theories of lists, arraysand extensional arrays.

Our work is related to [10] which performs automatic learning of proofmethods. The system LearnΩmatic described in [10] learns proof methods(e.g. decision procedures) from proof traces obtained by brute force applicationof available primitive methods. LearnΩmatic can help in building efficientimplementation of proof procedures, however does not give simple opportuni-ties for proving termination or completeness of learnt methods. On the otherhand, within the system presented in this paper, the correctness of synthesizedprocedures is obtained automatically because they are composed only of theapplication of sound rules.

Automatic generation of decision procedures (especially for user-defined the-ories) can be very fruitful for using decision procedures in theorem proving. Forinstance, we believe that the system presented in this paper fit nicely as anadditional module to the system presented in [11].

13 Future Work

For future work we are planning the following lines of research:

• we will be looking for other suitable domains for our techniques (for in-stance, we will look at other quantifier elimination procedures and at au-tomation of constructing solvers required in Shostak’s schemes for usingdecision procedures [15, 14]);

• we will try to further automate our system (along the lines discussed in§11);

• we will try to extend the set of our method generators and search enginesand will try to further improve their efficiency;

36

• we will implement mechanisms which generate not only necessary meth-ods, but also the corresponding tactics;

• we will try to automate the process of proving completeness (i.e., whetherconditions in the rewrite rules used cover all possible cases); we will try todo it whenever possible by using the “self-reflection” principle mentionedin §9.

• we will apply the proposed approach to other problems (e.g., cut-eliminationin sequent calculus);

• we will combine our system with Knuth-Bendix completion procedure (asdiscussed in §12).

• the realm of tactics is the theory object level. Methods are meta-levelrepresentation of tactics. Their object level is a meta-level of the theorywe deal with. Method generators are meta-level representation of methods.They also have preconditions, postconditions, and transformations (whileone of the side-effects is a generated method). They can be seen as meta-methods. Their object level is a meta-meta-level of the theory we dealwith. Our search engine works with method generators and its objectlevel is the method generators level, or a meta-meta-meta-level of thetheory we deal with. We will try to automatically generate some methodgenerators (similarly as methods). Our goal would be to consider all theselayers in a uniform way.

14 Conclusions

In this paper we presented a system (adeptus) for synthesising decision proce-dures. It is based on ideas from [5].

adeptus consists of several method generators and mechanisms for searchingover them and combining them. We have implemented the system and used it forgenerating decision procedures for ground arithmetic and for linear arithmetic.These procedures ensure correct implementation which is not quite easy for ahuman programmer to achieve (as these procedures consist of dozens of steps).We believe that our approach can be used in other domains as well and can leadto automation of some routine steps in different types of programming tasks.Moreover, the presented approach is such that it provides a framework for easyproving of termination, soundness and completeness of generated procedures.Also, the approach can give a deeper insight into the nature of some decisionprocedures.

References

[1] Armando, A., S. Ranise, and M. Rusinowitch: 2001, ‘Uniform Derivationof Decision Procedures by Superposition’. In: Computer Science Logic,

37

15th International Workshop, CSL 2001. 10th Annual Conference of theEACSL, Paris, France, September 10-13, 2001, Proceedings, Vol. 2142 ofLNCS. pp. 513–527.

[2] Boyer, R. S. and J. S. Moore: 1988, ‘Integrating Decision Procedures intoHeuristic Theorem Provers: A Case Study of Linear Arithmetic’. In: J. E.Hayes, J. Richards, and D. Michie (eds.): Machine Intelligence 11. pp.83–124.

[3] Bundy, A.: 1988, ‘The Use of Explicit Plans to Guide Inductive Proofs’. In:R. Lusk and R. Overbeek (eds.): 9th Conference on Automated Deduction.pp. 111–120. Longer version available from Edinburgh as DAI ResearchPaper No. 349.

[4] Bundy, A.: 1991a, ‘A Science of Reasoning’. In: J.-L. Lassez and G. Plotkin(eds.): Computational Logic: Essays in Honor of Alan Robinson. pp. 178–198. Also available from Edinburgh as DAI Research Paper 445.

[5] Bundy, A.: 1991b, ‘The Use of Proof Plans for Normalization’. In: R. S.Boyer (ed.): Essays in Honor of Woody Bledsoe. pp. 149–166. Also availablefrom Edinburgh as DAI Research Paper No. 513.

[6] Cooper, D. C.: 1972, ‘Theorem Proving in Arithmetic Without Multipli-cation’. In: B. Meltzer and D. Michie (eds.): Machine Intelligence 7. pp.91–99.

[7] Davis, M., R. Sigal, and E. Weyuker: 1994, Computability, Complexity,and Languages (Fundamentals of Theoretical Computer Science). MorganKaufmann/Academic Press.

[8] Gentzen, G.: 1935, ‘Untersuchungen uber das logische Schliessen, I, II’.Mathematische Zeitschrift 39, 176–210, 405–431. English translation in”The Collected Papers of Gerhard Gentzen”, North-Holland Publ.Co, 1969.

[9] Hodes, L.: 1971, ‘Solving Problems by Formula Manipulation in Logicand Linear Inequalities’. In: Proceedings of the 2nd International JointConference on Artificial Intelligence. Imperial College, London, England.

[10] Jamnik, M., M. Kerber, M. Pollet, and C. Benzmuller: 2002, ‘AutomaticLearning of Proof Methods in Proof Planning’. Submitted to Journal of Ar-tificial Intelligence. Also available as Technical Report CSRP-02-5, Schoolof Computer Science, University of Birmingham.

[11] Janicic, P. and A. Bundy: 2002, ‘A General Setting for the Flexible Com-bining and Augmenting Decision Procedures’. Journal of Automated Rea-soning 28(3), 257–305.

[12] Knuth, D. E. and P. B. Bendix: 1970, ‘Simple word problems in universalalgebra’. In: J. Leech (ed.): Computational problems in abstract algebra.Pergamon Press, pp. 263–297.

38

[13] Lassez, J.-L. and M. Maher: 1992, ‘On Fourier’s algorithm for linear arith-metic constraints’. Journal of Automated Reasoning 9, 373–379.

[14] Shostak, R. E.: 1979, ‘A practical decision procedure for arithmetic withfunction symbols’. JACM 26(2), 351–360.

[15] Shostak, R. E.: 1984, ‘Deciding combinations of theories’. Journal of theACM 31(1), 1–12. Also: Proceedings of the 6th International Conference onAutomated Deduction, volume 138 of Lecture Notes in Computer Science,pp. 209–222. Springer-Verlag, June 1982.

[16] Socher-Ambosius, R.: 1991, ‘Boolean algebra admits no convergent rewrit-ing system’. In: Proceedings of the 4th International Conference on rewrit-ing techniques and applications, Vol. 488 of LNCS.

A Appendix: List of Rewrite Rules

rewrite_rule(la, ’rm_univ’, (V:Sort##F), ~(V:Sort\\(~F)),

[quantifier_free(F)], two_way).

rewrite_rule(la, ’rm_redundant’, (V:_Sort\\F), F,

[not(occurs(V,F))], two_way).

rewrite_rule(la, ’rm_impl’, (F1=>F2), (~F1\F2), [], two_way).

rewrite_rule(la, ’rm_equiv’, (F1<=>F2), (F1=>F2)#(F2=>F1), [], two_way).

rewrite_rule(la, ’rm_gr’, (T1>T2), (T2<T1), [], two_way).

rewrite_rule(la, ’rm_leq’, leq(T1,T2), (T1<T2)\(T1=T2), [], two_way).

rewrite_rule(la, ’rm_qeq’, geq(T1,T2), (T2<T1)\(T1=T2), [], two_way).

rewrite_rule(la, ’rm_neq’, neq(T1,T2), (T1<T2)\(T2<T1), [], two_way).

rewrite_rule(la, ’rm_neg_eq’, ~(T1=T2), (T1<T2)\(T2<T1), [], two_way).

rewrite_rule(la, ’rm_neg_less’, ~(T1<T2), (T2<T1)\(T1=T2), [], two_way).

rewrite_rule(la, ’rm_top’, ~(true), false, [], two_way).

rewrite_rule(la, ’rm_bottom’, ~(false), true, [], two_way).

rewrite_rule(la, ’rm_minus’, -T, (-1)*T, [], two_way).

rewrite_rule(la, ’rm_eq1’, C1=C2, true,

[number(C1),number(C2),(C1=C2)], two_way).

rewrite_rule(la, ’rm_eq2’, C1=C2, false,

[number(C1),number(C2),not(C1=C2)], two_way).

rewrite_rule(la, ’rm_ls1’, C1<C2, true,

[number(C1),number(C2),(C1<C2)], two_way).

rewrite_rule(la, ’rm_ls2’, C1<C2, false,

[number(C1),number(C2),not(C1<C2)], two_way).

rewrite_rule(la, ’rm_mult’, C1*C2, C3,

[number(C1),number(C2),(C3 is C1*C2)], two_way).

rewrite_rule(la, ’st_neg_univ’, (~(V##F)), (V\\(~F)),

[], two_way).

rewrite_rule(la, ’st_neg_exi’, (~(V\\F)), (V##(~F)),

[], two_way).

rewrite_rule(la, ’st_conj_univ1’, (F1#(V##F2)), (V##(F1#F2)),

[], two_way).

rewrite_rule(la, ’st_conj_univ2’, ((V##F2)#F1), (V##(F2#F1)),

[], two_way).

rewrite_rule(la, ’st_conj_exi1’, (F1#(V\\F2)), (V\\(F1#F2)),

[], two_way).

39

rewrite_rule(la, ’st_conj_exi2’, ((V\\F2)#F1), (V\\(F2#F1)),

[], two_way).

rewrite_rule(la, ’st_disj_univ1’, (F1\(V##F2)), (V##(F1\F2)),

[], two_way).

rewrite_rule(la, ’st_disj_univ2’, ((V##F2)\F1), (V##(F2\F1)),

[], two_way).

rewrite_rule(la, ’st_disj_exi1’, (F1\(V\\F2)), (V\\(F1\F2)),

[], two_way).

rewrite_rule(la, ’st_disj_exi2’, ((V\\F2)\F1), (V\\(F2\F1)),

[], two_way).

rewrite_rule(la, ’st_neg_conj’, (~(F1#F2)), ((~F1)\ (~F2)),

[], two_way).

rewrite_rule(la, ’st_neg_disj’, (~(F1\ F2)), ((~F1)# (~F2)),

[], two_way).

rewrite_rule(la, ’st_conj_disj1’, (F1#(F2\F3)), (F1#F2)\ (F1#F3),

[], two_way).

rewrite_rule(la, ’st_conj_disj2’, ((F2\F3)#F1), (F2#F1)\ (F3#F1),

[], two_way).

rewrite_rule(la, ’st_mult_plus1’, (T1*(T2+T3)), (T1*T2)+(T1*T3),

[], two_way).

rewrite_rule(la, ’st_mult_plus2’, ((T2+T3)*T1), (T2*T1)+(T3*T1),

[], two_way).

rewrite_rule(la, ’thin_neg’, (~(~(F))), F, [], two_way).

rewrite_rule(la, ’left_assoc_conj’, (F1#(F2#F3)), ((F1#F2)#F3),

[], two_way).

rewrite_rule(la, ’left_assoc_disj’, (F1\(F2\F3)), ((F1\F2)\F3),

[], two_way).

rewrite_rule(la, ’left_assoc_plus’, (T1+(T2+T3)), ((T1+T2)+T3),

[], two_way).

rewrite_rule(la, ’left_assoc_mult’, (T1*(T2*T3)), ((T1*T2)*T3),

[], two_way).

rewrite_rule(la, ’reduce_plus’, (T1+T2), T3,

[number(T1),number(T2),T3 is T1+T2 ], two_way).

rewrite_rule(la, ’absorbe_mult’, (C1*(C2*T)), C3*T,

[number(C1),number(C2),C3 is C1*C2 ], two_way).

rewrite_rule(la, ’reorder_plus1’, (C*V+T1),(T1+C*V),

[variable(V),number(T1)], two_way).

rewrite_rule(la, ’reorder_plus2’, (V+T1),(T1+V),


rewrite_rule(la, ’reorder_plus3’, ((T+(C*V))+T1), ((T+T1)+(C*V)),


rewrite_rule(la, ’reorder_plus4’, ((T+(V))+T1), ((T+T1)+(V)),


rewrite_rule(la, ’reorder_plus5’, (x0+V),(V+x0),

[variable(V),not(V=x0)], two_way).

rewrite_rule(la, ’reorder_plus6’, (x0+C*V), (C*V+x0),


rewrite_rule(la, ’reorder_plus7’, (C*x0+V),(V+C*x0),


rewrite_rule(la, ’reorder_plus8’, (C0*x0+C*V), (C*V+C0*x0),


rewrite_rule(la, ’reorder_plus9’, (T+x0)+V, (T+V)+x0,

40


rewrite_rule(la, ’reorder_plus10’, (T+x0)+C*V, (T+C*V)+x0,


rewrite_rule(la, ’reorder_plus11’, (T+C*x0)+V, (T+V)+C*x0,


rewrite_rule(la, ’reorder_plus12’, (T+C0*x0)+C*V, (T+C*V)+C0*x0,


rewrite_rule(la, ’reorder_plus13’, (T+x0)+x0, T+C*x0,

[number(C), C is 2], two_way).

rewrite_rule(la, ’reorder_plus14’, (T+x0)+C*x0, T+C1*x0,

[number(C1),C1 is C+1], two_way).

rewrite_rule(la, ’reorder_plus15’, (T+C*x0)+x0, T+C1*x0,


rewrite_rule(la, ’reorder_plus16’, (T+C0*x0)+C1*x0, T+C*x0,

[number(C1),C is C0+C1], two_way).

rewrite_rule(la, ’reduce_bool1’, (F1#true), (F1), [], two_way).

rewrite_rule(la, ’reduce_bool2’, (_F1\true), (true), [], two_way).

rewrite_rule(la, ’reduce_bool3’, (_F#false), false, [], two_way).

rewrite_rule(la, ’reduce_bool4’, (F1\false), (F1), [], two_way).

rewrite_rule(la, ’collect1’, x0+x0, C*x0,

[C is 2], two_way).

rewrite_rule(la, ’collect2’, x0+C*x0, C1*x0,


rewrite_rule(la, ’collect3’, C*x0+x0, C1*x0,


rewrite_rule(la, ’collect4’, C0*x0+C1*x0, C*x0,

[number(C1),C is C0+C1], two_way).

rewrite_rule(la, ’one_side1’, (T1=T2), (T1+(-1)*T2=0),

[not(T2=0)], two_way).

rewrite_rule(la, ’one_side2’, (T1<T2), (T1+(-1)*T2<0),

[not(T2=0)], two_way).

rewrite_rule(la, ’isolate1’, T+C*x0=0, C*x0= (-(T)),

[number(C)], two_way).

rewrite_rule(la, ’isolate2’, T+x0=0, x0=(-(T)),

[], two_way).

rewrite_rule(la, ’isolate3’, T+C*x0<0, C*x0<(-(T)),

[number(C)], two_way).

rewrite_rule(la, ’isolate4’, T+x0<0, x0<(-(T)),

[], two_way).

B Appendix: Generated Procedure for Linear

Arithmetic

1 remove <=>; Target class: f;

Rules:[[f, f<=>f, rm_equiv]];


2 remove =>; Target class: f;

Rules:[[f, f=>f, rm_impl]];


3 remove leq; Target class: f;

Rules:[[f, leq(t, t), rm_leq]];

41


4 remove geq; Target class: f;

Rules:[[f, geq(t, t), rm_qeq]];


5 remove neq; Target class: f;

Rules:[[f, neq(t, t), rm_neq]];


6 remove >; Target class: f;

Rules:[[f, t>t, rm_gr]];


7 remove -; Target class: t;

Rules:[[t, -t, rm_minus]];


8 remove -; Target class: re;

Rules:[[re, -re, rm_minus]];


9 stratify [##, \\]; Target class: f;

Rules:[[f, f#var:rational##f, st_conj_univ1],

[f, f#var:rational\\f, st_conj_exi1],

[f, var:rational##f#f, st_conj_univ2],

[f, var:rational\\f#f, st_conj_exi2],

[f, f\var:rational##f, st_disj_univ1],

[f, f\var:rational\\f, st_disj_exi1],

[f, var:rational##f\f, st_disj_univ2],

[f, var:rational\\f\f, st_disj_exi2],

[f, ~var:rational##f, st_neg_univ],

[f, ~var:rational\\f, st_neg_exi]];


----------------------------------------------------------------------------

10 adjust_innermost x0; Target class: f;

Rules:[[f, x0:rational##f1, rm_univ]];


11 stratify [#, \]; Target class: f1;

Rules:[[f1, ~(f1#f1), st_neg_conj], [f1, ~(f1\f1), st_neg_disj]];





13 remove ~; Target class: f1;

Rules:[[f1, ~false, rm_bottom], [f1, ~true, rm_top],

[f1, ~t<t, rm_neg_less], [f1, ~t=t, rm_neg_eq]];


14 one_side [0, [<, >, leq, neq, geq, =]]; Target class: f1;

Rules:[[f1, t<t, one_side2], [f1, t=t, one_side1]];


15 stratify [\]; Target class: f1;

Rules:[[f1, f1#f1\f1, st_conj_disj1],

[f1, (f1\f1)#f1, st_conj_disj2]];



Rules:[[t, re*(t+t), st_mult_plus1]];


17 stratify [+]; Target class: re;

Rules:[[re, re*(re+re), st_mult_plus1],

[re, (re+re)*re, st_mult_plus2]];


18 left_assoc \; Target class: f1;

42

Rules:[[f1, f1\f1, left_assoc_disj]];





20 stratify [<, =]; Target class: f11;

Rules:[[f11, (f11#t<0)#false, reduce_bool3],

[f11, (f11#t<0)#true, reduce_bool1],

[f11, (f11#t=0)#false, reduce_bool3],

[f11, (f11#t=0)#true, reduce_bool1],

[f11, t<0#false, reduce_bool3],

[f11, t<0#true, reduce_bool1],

[f11, t=0#false, reduce_bool3],

[f11, t=0#true, reduce_bool1]];



Rules:[[f111, f111#false, reduce_bool3],

[f111, f111#true, reduce_bool1]];


22 left_assoc +; Target class: re;

Rules:[[re, re+re, left_assoc_plus]];





24 left_assoc *; Target class: re1;

Rules:[[re1, re1*re1, left_assoc_mult]];


25 absorbe *; Target class: re1;

Rules:[[re1, rc*rc, rm_mult]];


26 absorbe +; Target class: re;

Rules:[[re, rc+rc, reduce_plus]];



Rules:[[t1, rc*(rc*t1), absorbe_mult], [t1, rc*rc, rm_mult]];


28 stratify [x0]; Target class: t;

Rules:[[t, x0+rc, reorder_plus2],

[t, x0+var, reorder_plus5],

[t, x0+rc*var, reorder_plus6],

[t, rc*x0+rc, reorder_plus1],

[t, rc*x0+var, reorder_plus7],

[t, rc*x0+rc*var, reorder_plus8],

[t, t+x0+rc, reorder_plus4],

[t, t+x0+var, reorder_plus9],

[t, t+x0+rc*var, reorder_plus10],

[t, t+rc*x0+rc, reorder_plus3],

[t, t+rc*x0+var, reorder_plus11],

[t, t+rc*x0+rc*var, reorder_plus12]];



Rules:[[t, t+x0+x0, reorder_plus13],

[t, t+rc*x0+x0, reorder_plus15],

[t, x0+x0, collect1],

[t, rc*x0+x0, collect3],

[t, t+x0+rc*x0, reorder_plus14],

43

[t, t+rc*x0+rc*x0, reorder_plus16],

[t, x0+rc*x0, collect2],

[t, rc*x0+rc*x0, collect4]];


30 isolate [[x0, rc*x0], [<, >, leq, neq, geq, =]]; Target class: f11;

Rules:[[f11, f11#t1+x0<0, isolate4],

[f11, f11#t1+rc*x0<0, isolate3],

[f11, f11#t1+x0=0, isolate2],

[f11, f11#t1+rc*x0=0, isolate1],

[f11, t1+x0<0, isolate4],

[f11, t1+rc*x0<0, isolate3],

[f11, t1+x0=0, isolate2],

[f11, t1+rc*x0=0, isolate1]];


31 eliminate [[x0, rc*x0], [<, >, leq, neq, geq, =]]; Target class: f;

Rules:[[f, x0:_G18107\\_G18104, rm_redundant]];


---------------------------------------------------------------------

32 stratify [#, \]; Target class: f1;

Rules:[[f1, ~(f1#f1), st_neg_conj], [f1, ~(f1\f1), st_neg_disj]];





34 remove ~; Target class: f1;

Rules:[[f1, ~false, rm_bottom], [f1, ~true, rm_top],

[f1, ~t<t, rm_neg_less], [f1, ~t=t, rm_neg_eq]];


35 stratify [\]; Target class: f1;

Rules:[[f1, f1#f1\f1, st_conj_disj1],

[f1, (f1\f1)#f1, st_conj_disj2]];



Rules:[[t, re*(t+t), st_mult_plus1]];


37 left_assoc \; Target class: f1;

Rules:[[f1, f1\f1, left_assoc_disj]];


38 stratify [+]; Target class: re;

Rules:[[re, re*(re+re), st_mult_plus1],

[re, (re+re)*re, st_mult_plus2]];


39 left_assoc +; Target class: re;

Rules:[[re, re+re, left_assoc_plus]];





41 left_assoc *; Target class: re1;

Rules:[[re1, re1*re1, left_assoc_mult]];


42 absorbe *; Target class: re1;

Rules:[[re1, rc*rc, rm_mult]];


43 absorbe +; Target class: re;

Rules:[[re, rc+rc, reduce_plus]];


44


Rules:[[t1, rc*rc, rm_mult]];



Rules:[[t, rc+rc, reduce_plus]];


46 remove <; Target class: f11;

Rules:[[f11, rc<rc, rm_ls1], [f11, rc<rc, rm_ls2]];


47 remove =; Target class: f11;

Rules:[[f11, rc=rc, rm_eq1], [f11, rc=rc, rm_eq2]];






Rules:[[f11, f11#false, reduce_bool3],

[f11, f11#true, reduce_bool1]];


50 remove \; Target class: f1;

Rules:[[f1, f1\false, reduce_bool4],

[f1, f1\true, reduce_bool2]];


51 remove ~; Target class: f;

Rules:[[f, ~false, rm_bottom], [f, ~true, rm_top]];


C Appendix: Example of a Linear Arithmetic

Solved Formula

1 x:rational##(x>0)

2 x:rational##(x>0)

3 x:rational##(x>0)

4 x:rational##(x>0)

5 x:rational##(x>0)

6 x:rational##(0<x)

7 x:rational##(0<x)

8 x:rational##(0<x)

9 x:rational##(0<x)

10 ~x0:rational\\(~0<x0)



13 ~x0:rational\\(x0<0\0=x0)

14 ~x0:rational\\(x0<0\0+-1*x0=0)

15 ~x0:rational\\(x0<0\0+-1*x0=0)

16 ~x0:rational\\(x0<0\0+-1*x0=0)

17 ~x0:rational\\(x0<0\0+-1*x0=0)

18 ~x0:rational\\(x0<0\0+-1*x0=0)

19 ~x0:rational\\(x0<0\0+-1*x0=0)

20 ~x0:rational\\(x0<0\0+-1*x0=0)

21 ~x0:rational\\(x0<0\0+-1*x0=0)

22 ~x0:rational\\(x0<0\0+-1*x0=0)

23 ~x0:rational\\(x0<0\0+-1*x0=0)

24 ~x0:rational\\(x0<0\0+-1*x0=0)

25 ~x0:rational\\(x0<0\0+-1*x0=0)

45

26 ~x0:rational\\(x0<0\0+-1*x0=0)

27 ~x0:rational\\(x0<0\0+-1*x0=0)

28 ~x0:rational\\(x0<0\0+-1*x0=0)

29 ~x0:rational\\(x0<0\0+-1*x0=0)

30 ~x0:rational\\(x0<0\-1*x0= -0)

31 ~(0*1<1*1\-1*0=-1*0)

32 ~0*1<1*1# ~-1*0=-1*0

33 ~0*1<1*1# ~-1*0=-1*0

34 (1*1<0*1\0*1=1*1)#-1*0<-1*0\-1*0<-1*0

35 ((1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0)\

(1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0

36 ((1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0)\

(1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0

37 (((1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0)\

1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0

38 (((1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0)\

1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0

39 (((1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0)\

1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0

40 (((1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0)\

1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0

41 (((1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0)\

1*1<0*1#-1*0<-1*0)\0*1=1*1#-1*0<-1*0

42 (((1<0#0<0)\0=1#0<0)\1<0#0<0)\0=1#0<0

43 (((1<0#0<0)\0=1#0<0)\1<0#0<0)\0=1#0<0

44 (((1<0#0<0)\0=1#0<0)\1<0#0<0)\0=1#0<0

45 (((1<0#0<0)\0=1#0<0)\1<0#0<0)\0=1#0<0

46 (((false#false)\0=1#false)\false#false)\0=1#false

47 (((false#false)\false#false)\false#false)\false#false

48 (((false#false)\false#false)\false#false)\false#false

49 ((false\false)\false)\false

50 false

51 false

46

automatic synthesis of decision procedures: a case study...

Documents