Inequality Reasoning forQualitative Models using

Constraint Handling Rules

T.W.D. Jongstra0447536

Bachelor thesisCredits: 9 EC

Bachelor Opleiding Kunstmatige Intelligentie

University of AmsterdamFaculty of ScienceScience Park 904

1098 XH Amsterdam

Supervisors

Dr. B. BredewegMSc J. Liem

Theory of Computer ScienceFaculty of Science

University of AmsterdamScience Park 904

1098 XH Amsterdam

December 2, 2011

Abstract

Inequality reasoning comprises the handling of transitivity andalgebraic simpli�cation given a set of inequalities. In QualitativeReasoning (QR), this method is used to in order to simulate scenario'sin a system by deriving new facts. Due to combinatorics, inequalityreasoning can pose a computational bottleneck in QR applications. Thispaper shows how constraint handling rules (CHR) can be used toperform QR inequality reasoning in an e�cient way, and how thisimpacts performance and speed in existing QR simulation software.

Keywords: Qualitative reasoning, Inequality reasoning, Constraint logicprogramming, Constraint handling rules

Contents

1 Introduction 21.1 Research Question . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Qualitative Reasoning 3

3 Inequality Reasoning within QR 4

4 Constraint Handling Rules 54.1 Logic Programming . . . . . . . . . . . . . . . . . . . . . . . . . . 54.2 Constraint Logic Programming Languages . . . . . . . . . . . . . 5

5 Constraint Handling Rules 65.1 Overview of CHR . . . . . . . . . . . . . . . . . . . . . . . . . . . 65.2 Semantics and Syntax . . . . . . . . . . . . . . . . . . . . . . . . 7

5.2.1 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . 75.2.2 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

5.3 Code Con�uence . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

6 Inequality Reasoning using CHR 96.1 Representation of Relational Statements . . . . . . . . . . . . . . 96.2 Processing Constraints . . . . . . . . . . . . . . . . . . . . . . . . 10

7 Inequality Reasoning for QR using CHR 137.1 CHR Inequality Reasoning Framework . . . . . . . . . . . . . . . 137.2 Module: QR Interface Rules . . . . . . . . . . . . . . . . . . . . . 147.3 Module: CHR Adding Rules . . . . . . . . . . . . . . . . . . . . . 167.4 Module: CHR Mutation Rules . . . . . . . . . . . . . . . . . . . 177.5 Module: QR Ouptut Translation Rules . . . . . . . . . . . . . . . 17

8 Evaluation 178.1 Evaluation: Non-QR Models . . . . . . . . . . . . . . . . . . . . . 178.2 Evaluation: Hand-Generated QR Models . . . . . . . . . . . . . . 178.3 Evaluation: Computer-Generated QR Models . . . . . . . . . . . 17

9 Conclusion & Future Work 18

1 Introduction

Qualitative Reasoning (QR) is a research area in arti�cial intelligenceaiming to capture fundamental system behaviour using abstract andincomplete terminology to model systems [BLBL09]. Incomplete terminologyis often su�cient for the representation of a model, and sometimes it is evenpreferable. To illustrate this, consider the following example: if you are �llingup bath with water, then exact information about the amount of water in thebath is often unnecessary. It is enough to know whether the bath is empty (inwhich case you have to turn on the water), containing a small amount ofwater (in which case you have to keep the water running), containing a largeamount of water (in which case you take a bath), or whether it is full andover�owing (in which case you have to turn o� the water and clean thebathroom).

In order to reason about these kind of incomplete but useful notions, QRreasoners use inequality reasoning as an important inference step. InGarp3, and supposedly most other QR software, inequality reasoning isimplemented with imperative algorithms. Inequality reasoning is subject tocombinatorial explosion, so it becomes time consuming for complex problems.The questions arises whether more advanced technology is available to handlethis issue. Implementing inequality reasoning with Constraint HandlingRules (CHR)1, a relatively new declarative programming language, mighthelp to solve this issue.

In this paper, a CHR-based framework for inequality reasoning is described.CHR is a computationally optimized declarative language extension with asophisticated syntax. This enables the framework to have a leanimplementation which still provides fast working speed. The framework is alsoadaptable due to its declarative representation. CHR implementations areextensible and require a limited amount of rules to provide new functionality.This framework could be used as a module for inequality reasoning inprograms requiring this capability.

This paper shows how the framework can be used to work within a QRapplication, the Garp3 workbench, and shows the di�erences compared to theinequality reasoning methods which are currently being used.

1.1 Research Question

The main research question addressed in this thesis is the following:

"How can inequality reasoning for QR be represented with CHR?"

1For a more detailed description of CHR, see: Thom Frühwirth's description about his

book "Constraint Handling Rules".

2

This question has the following three sub-questions:

• How can inequality reasoning be represented with CHR?

• How can this representation be used for QR systems?

• What are the resulting di�erences in reasoning and speed?

Considering that impressive results are achieved on an active research topiclike CHR, representing inequality reasoning in this form could provide theconnection to a new programming paradigm for applications that make use ofinequality reasoning. Since CHR is a fairly new language extension, no QRinequality reasoning implementation is known to make use of it. It issuspected that re-designing an QR inequality reasoning module in a terselanguage like CHR will lead to a lean and more comprehensible representation,enabling easier extension. Future breakthroughs in the research of CHR couldalso lead to further improvements.

Section 3 shows the inequality reasoning algorithm of current QR applications.Section 4 shows research on several constraint logic programming languagesand the choice for CHR is motivated. Section 6 discusses the implementationof inequality reasoning using CHR. Section 7 introduces a framework for usingCHR inequality reasoning withing QR. Section 8 addresses the evaluation of theimplemented algorithms. Finally, in section 9, conclusions are drawn and futurework is discussed.

2 Qualitative Reasoning

When trying to understand how a complex system works, or when designing anew system, one usually desires to get a rough idea about the system'sbehaviour. In order to get an outline of the behaviour, precise numericaldetails are often unnecessary and are more likely to obfuscate any insights inthe working of the system. Qualitative Reasoning is a research area withinArti�cial Intelligence that focuses on automated high-level reasoning aboutsystem behaviour. It is called Qualitative since it speci�cally uses abstract andincomplete information in order to reason about system behaviour.

The qualitative approach to system modelling and simulation enables QRsoftware to automatically create an outline for any modelled system. To dothis, the QR software �nds all possible states the system could get into for agiven model. After �nding all these states, all state transitions between themare calculated for the given scenario. Next, a directed graph is created showingall states and the transitions between them. This graph is called a behaviour

graph. When running simulations for multiple scenario's of one model, the userwill be able to get a good grasp of the possible behaviours of the system bylooking at this behaviour graph.

3

The research area of Qualitative Reasoning covers multiple subjects, such asautonomous agent behaviour, automated error detection and system simulationfor educational and design purposes.

3 Inequality Reasoning within QR

QR software, such as the sGarp3 QR simulation workbench, use inequalityreasoning as a central inference algorithm in their reasoning. For Garp3, theinteraction of the inequality reasoning module with the other algorithms canbe seen in �gure 1 [BLBL09].

Fig. 1: An overview of the Garp3 reasoning engine and context clarifying the versatile roleof inequality reasoning within QR. Source: [BLBL09].

The engine as a whole receives a scenario and set of model fragments as itsinput. During simulation, the system searches for applicable model fragments.The inequality reasoning engine is used in order to check the applicability.Next, (in)equalities between quantity values and magnitudes are producedwhen the causal model is applied. Quantities can be added together orsubtracted from each other in one of the sides of an equality when needed forthe given model fragment. Now, all (in)equalities with overlapping values arecombined in order to derive new (in)equalities. When the derivations producea new state, this state is added to the behaviour graph and correspondingstate descriptions are created. Next, the inequality reasoning engine is used onthe quantity derivatives again in order to �nd any possible state transitions (orto recognize a stable state when no transitions are found). This process in

4

repeated until all possible state changes have been exhausted.

The inequality reasoning engine will simplify (in)equalities, replace weaker(in)equalities with stronger ones and add new derived statements. Thealgorithm can handle all types of relations, i.e. {<,≤,=,≥, >}, and supportsthe following three principles:

• algebraic simpli�cations, e.g. (A+B) > (A+ C)→ B > C

• transitivity, e.g. (A > B) ∧ (B > C)→ A > C

• anti-symmetry, e.g. (A ≥ B) ∧ (B ≥ A)→ A = B

For the representation of inequalities, Garp3 makes use of several internaloptimizations, such as a bitmap representation and the removing of weakerrelations in favour of dominant ones, e.g. A ≥ B is thrown away when A > Bis present. A canonical representation, using only the relations {=,≥, >} isalso used in order to reduce avoid duplicate relations, e.g. A > B and B < Abeing present.

4 Constraint Handling Rules

4.1 Logic Programming

In order to understand what Constraint Handling Rules are, it is �rstnecessary to understand what constraint logic programming and normal logicprogramming are. Logic programming in the broadest sense encompasses allcomputer programming based on mathematical logic. In a narrower sensethough, it is more regularly understood as programming based on backwardsreasoning. Backwards reasoning is an inference method which starts itsreasoning from its goal position. The method then works backwards whileunifying values of matching variables, until a compliant solution for the goal isfound. The method can also encounter contradictions during its reasoning inwhich case backtracking is applied, which tantamounts to reversing theminimal amount of possibly faulty decision and making other decisions inorder to �nd a situation where the goal is true. A programming languagewhich is speci�cally designed for this kind of logic programming is Prolog 2.

4.2 Constraint Logic Programming Languages

Constraint logic programming (CLP) extends upon normal logic programmingby extending a host language with constraints. Constraint logic languages,like CHIP (Constraint Handling In Prolog), actively use constraints to avoidcombinatorial explosion [DVHS+88]. Combinatorial explosion is also reducedbecause (embedded) CLP languages are committed-choice [FHK+92]. In logic

2SWI-Prolog is a free and open-source version of Prolog

5

programming languages like Prolog, which is based on backwards reasoning, thisnon-reversibility of constraints evidently changes the programming paradigm forlogic programming. There are several (embedded) CLP languages in existence,all of which were initially considered for this research:

• CHIP: Constraint Handling In Prolog.

• Prolog III: A modi�ed version of Prolog with built-in constraintprogramming [Col90]

• CLP(R): Constraint logic programming for real numbers.

• CLP(Q): Constraint logic programming for rational numbers.

• CLP(FD): Constraint logic programming for �nite domains.

• CHR: Constraint handling rules.

Prolog III, CHIP and CLP(R) originate from the time when constraint logicprogramming was in its infancy so they were not considered for this research.We focus on CLP(QR) (a combination of CLP(Q) and CLP(R)), CLP(FD) andCHR to bene�t from new developments. SWI-Prolog (which was used for thisresearch) supports these embedded languages with libraries. In other research,a CLP(FD) model for Qualitative Reasoning has been proposed [Tel96]. ButCLP(FD), CLP(R) and CLP(Q) can only make use of numberical values forvariables, while Qualitative Reasoning needs variables for qualitative values.While a workaround can be used, this seems to create an unnecessary overhead.CHR just allows the usage of qualitative values in variables, is actively beingresearched and allegedly has high computational performance. Hence it is moresuitable to implement inequality reasoning for this project.

5 Constraint Handling Rules

5.1 Overview of CHR

Constraint handling rules are a declarative language extension for writinguser-de�ned constraints in any host language. They were originally designed in1991 by Tom Frühwirth for this particular purpose [Frü98]. CHR are also theonly declarative language known in which every algorithm can be implementedwith optimal space and time complexity [SSD09]. They are proclaimed to beespecially bene�cial to conventional CLP languages such as Prolog due to theterse and understandable syntax which makes CHR suitable for quickprototyping [Sch08]. CHR are typically implemented with a library containinga compiler and a run-time system written in the host language while theconstraint solvers are written in CHR. As a language extension CHR is onlyconcerned with handling the constraints, while all auxiliary computations arehandled by the host language.

6

5.2 Semantics and Syntax

A CHR program is de�ned as a �nite set of rules. A CHR program works onconstraints which are manipulated by these rules. The semantics and syntax ofthe rules and constraints are explained below.

5.2.1 Constraints

Constraints are considered to be distinguished, special, �rst-order predicates(atomic formulae). There are built-in constraints, which are used by thepre-de�ned constraint solver, as well as manually de�ned user constraints.CHR constraints can be either active or passive. When a constraint is active,the CHR reasoner will actively try out rules in which the constraint can beused. When the CHR reasoner cannot �re such a rule, the constraint becomespassive. When a constraints becomes passive, it is stored in the so calledconstraint store. Constraints will reside there until the CHR reasoner needs itagain to �re a rule with multiple prerequisites, which can happen whenanother constraint is active. By default constraints are active when created,but they can also be instanced in passive mode which enables certain programoptimizations.

5.2.2 Rules

Rules de�ne how a CHR program works. There are three types of rules whichall have a similar structure. They all have (1) a head, which accepts one or moreconstraints, (2) a separator, which de�nes the type of the rule, (3) a guard,which describes the condition in which the rule may �re, and (4) a body, whichcontains constraints that will be activated when the rule is �red. The syntax ofthe three rules can be seen in �gure 2).

Name @ Head Sep. Guard | Body

Simpli�cation @ H1, ...,Hi <=> G1, ..., Gj | B1, ..., Bk

Propagation @ H1, ...,Hi ==> G1, ..., Gj | B1, ..., Bk

Simpagation @ H1, ...,Hx\Hy, ...,Hi <=> G1, ..., Gj | B1, ..., Bk

Fig. 2: The CHR Rule Syntax. Each rule type has the same structure and consists ofa variable Name, Head, Guard and Body. These items are separated by the"@"-character, a variable Separator (depending on the rule's type) and the "|"-character.

Every CHR rule can be given a Name followed by the "@"-character, thoughnaming rules is optional and is only for clarity. Whenever the CHR reasonersatis�es the Head of a rule, the (optional) Guard, consisting of statements in thehost language is checked. When the statements in the Guard are true, the ruleis �red. When the Guard fails, the rule is not �red and CHR reasoner will try

7

to match the active constraint with another rule. The constraint will becomepassive when all possible rules have been exhausted. The consequences of the�ring of a rule are dependent on the type of the rule, which is indicated by theseparator (Sep.). Below are descriptions what happens when a certain type ofrule does �re. It has to be remembered that, since CHR are committed-choice,the �ring of a rule cannot be backtracked.

• Simpli�cation @ Head <=> Guard | Body

When a simpli�cation rule is �red, the constraints in the Head are removedand the constraints/host-language arguments in the Body are activated. Asimple example:

red, blue <=> working(paintMixer) | purple.

In this rule, "red", "blue" and "purple" are constraints that stand for di�erentpaint colors. An empty constraint store is assumed. When a "red" constraintis created and activated, the CHR reasoner tries to match this constraint in thehead of the rule. This succeeds, but since the rule is multi-headed the "blue"constraint is also needed. The CHR reasoner looks for the "blue" constraintin the constraint store, but fails to �nd it, so the rule does not �re and the"red" constraint is put in the constraint store. Later, when a "blue" constraintis added, the CHR reasoner will match it in the head of the rule. But now,when looking for the second constraint of the head (the "red" constraint), theCHR reasoner will �nd it in the constraint store. Assuming that the guard(working(paintMixer) is also true, the rule will now �re and both the "red" and"blue" constraints are replaced by the "purple" constraint in the body. Thisconstraint will now be active and the reasoner will again try to �nd rules thatit can use it with (and so forth).

• Propagation @ Head ==> Guard | Body

When a simpli�cation rule is �red, the constraints in the Head are kept andthe constraints/host-language arguments in the Body are activated.

• Simpagation @ HeadA \HeadB <=> Guard | Body

The Head of the simpagation rule is slightly di�erent from the head of theother rules. There is a backslash in the Head which separates the head in twogroups: HeadA and headB. When a simpagation rule is �red, the constraints inthe HeadA are kept while the constraints in the HeadB are removed and theconstraints/host-language arguments in the Body are activated.

8

5.3 Code Con�uence

With good design, it is possible to make the CHR constraints "con�uent" for alot of problems. Code con�uence ensures that processing a given set ofconstraints always results in the same result, regardless of the order they areactivated in [Frü98]. This ensures that the constraint solver can be run usingmulti-threading, possibly enabling a computational speed-up when usingmulti-core architectures. In recent tests with a CHR implementation inHaskell, the obtained speed-up when multi-threading con�uent CHR code wassigni�cant in various experiments, with speed-up gains sometimes close to100% using a dual-core architecture [LS07].

6 Inequality Reasoning using CHR

This section will address the representation of inequality reasoning in CHR, aswell as the processing of inequality statements. The �rst subsection will show theCHR constraints which represent the inequalities and explain the overall designapproach. The next subsection shows how CHR rules can be used to processconstraints to actually perform inequality reasoning on the CHR constraints.

6.1 Representation of Relational Statements

The following CHR constraints have been used to represent all basic relationalstatements (name/arity).

• eq/1 (equal)

• geq/2 (greater-or-equal)

• gt/2 (greater-than)

The arguments used in these constraints are either lists of one or moreelements which are equal to each other. For gt/2 and geq/2 constraints, asum/1 statement containing one or more of such lists can also be used. As aresult, all items in the list in eq/1 statements are equal while the gt/2 andgeq/2 constraints contain two list (or sums) of equal elements where all itemsin the �rst list (or sum) are greater than all items in the second one. For eq/1statements, this representation seems very logical, but for the other tworelations it might feel redundant. Allowing this redundancy has been anintended design choice though. To prevent redundancy, it would be possible touse an eq/2 constraint (instead of eq/1) which would contain one list of equalelements as its �rst argument and an arbitrary pointer as its second argument.This would allow other constraints, such as gt/2, to take two pointers pointingto lists of equal elements and would allow the representation of sums by usinglists of such pointers. The reason this design has not been chosen is because itmakes code con�uence 5.3 harder to obtain. When processing constraints inmultiple threads the eq/2 pointer ID's can start overlapping, introducing

9

incorrect statements when joining all separate threads together. The usage ofpointers would also increase the need for longer CHR rules in order to includethe eq/2 statements, hence increasing complexity for the CHR reasoner whenchecking whether rules should be �red. While further research might improveon this, it was decided to accept some redundancy in the design in order to getaround these issues.

6.2 Processing Constraints

In order to make new derivations with the eq/1, gt/2 and geq/2 constraints,sets of CHR rules are needed to process these constraints. When processingthese constraints, new equalities between elements are often found. When thishappens, the eq/1 statements containing the equal elements are updated. Anexample of this can be seen in the following rules (the inequality/3 constraintsadd a new equality between two single elements in this case):

eq(E),inequality(eq,X,Y) <=> member(X,E),union(E,[Y],Z),

list_to_ord_set(Z,OZ) | eq(OZ).

eq(E),inequality(eq,X,Y) <=> member(Y,E),union(E,[X],Z),

list_to_ord_set(Z,OZ) | eq(OZ).

Fig. 3: An example of rules for updating eq/1 constraints when new information is enteredin the system.

Note that the lists of equalities in eq/1 statements are always sorted by using thelist_to_ordset/2 Prolog predicate. This is done in order to be able to preventthe occurrence of multiple eq/1 statements which are equivalent (containingthe same elements but in a di�erent order). Since a representation was chosenwere multiple elements can be present in a single eq/1 constraint, multiple eq/1constraints can be combined into one. In order to allow this, the following rulescan be used:

eq(E) \ eq(F) <=> true.

eq(E) , eq(F) <=> E \= F, member(A,E), member(A,F),!,

ord_union(E,F,G) | eq(G).

Fig. 4: Ruleset for mutating eq-constraints.

The �rst rule makes sure that equivalent eq/1 statements are removed (whichmight be needed when multi-threading), while the second rule makes sure thateq/1 statements with overlapping elements are combined into a single new eq/1statement. When rules such as the ones above are �red, all gt/2 and geq/2

10

constraints containing any of the involved elements have to be updated to keepthe system up to date. Below is a ruleset which takes care of this updatingprocess:

eq(E) \ geq(X,Y) <=> E\=X, member(M,X),member(M,E) | geq(E,Y).

eq(E) \ geq(X,Y) <=> E\=Y, member(M,X),member(M,E) | geq(X,E).

eq(E) \ gt(X,Y) <=> E\=X, member(M,X),member(M,E) | gt(E,Y).

eq(E) \ gt(X,Y) <=> E\=Y, member(M,X),member(M,E) | gt(X,E).

Fig. 5: Ruleset for updating constraints after changes in eq/1 constraints.

The inequality reasoning system also needs rules to process gt/2 constraints. Aruleset for this can be seen below:

gt(X,X) <=> | log(contraD,gt(X,X)).

gt(X,Y) #passive \ gt(X,Y) <=> | true.

gt(Y,Z) , gt(X,Y) #passive ==> | add_gt(X,Z).

gt(X,Y) \ add_gt(X,Y) <=> | true.

add_gt(X,Y) <=> | gt(X,Y).

Fig. 6: Ruleset for mutating gt-constraints.

The �rst rule in this ruleset is a unique one, since it is the only ruleimplemented to detect contradictions. All contradictions will eventually leadto a contradictory statement in the form of X > X, hence only this rule isneeded to detect the presence of contradictory statements in a set ofconstraints. In this ruleset, contradictions will be logged, but with a simplechange the reasoner can also be made to fail when contradictions areencountered (if such behavior is desired). The second rule is a rule ofre�exivity, which removes double gt/2 statements (which might occur whenmulti-threading). The third, fourth and �fth rules together apply transitivitywhile preventing the introduction of multiple copies of a single constraint byintroducing an add_gt/2 constraint which is only temporarily in existence andwill be �ltered when the corresponding gt/2 constraints already exists. Notethat the #passive statements in the given rules are only for optimization. Inthe second rule above, only an active geq/2 constraint would match the part ofthe head after the backslash. This behaviour is preferable to the behaviour of

11

matching to passive constraints, since it is more useful to remove an activeversion of a double constraint. If the active version of the constraint wouldstill be present and active it would be unlikely to �re any rules, since anotherversion of it was already placed in the constraint store before.

A ruleset for geq/2 statements is also needed for inequality reasoning. Such aruleset is shown below:

geq(X,Y) , geq(Y,X) #passive <=>

ord_union(X,Y,Z), | eq(Z).

geq(X,Y) #passive \ geq(X,Y) <=> | true.

geq(Y,Z) , geq(X,Y) #passive ==> | add_geq(X,Z).

geq(X,Y) \ add_geq(X,Y) ==> | true.

add_geq(X,Y) <=> | geq(X,Y).

Fig. 7: Ruleset for mutating geq-constraints.

The �rst rule in this set applies antisymmetry: two geq/2 constraints arereplaced with a single eq/1 constraint containing a sorted combined elementlist. Two weaker relations are replaced with a single stronger one. The lastfour rules are are similar to the last four gt/2 rules.

Summation-statements are also taken care of with rules similar to the onesshowed above. These rules have to be present for eq/1, geq/2 and gt/2statements. An example of such a rule is shown below:

gt([sum(X)],[sum(Y)]) <=> list_to_ord_set(X,OX),

list_to_ord_set(Y,OY),

ord_intersection(OX,OY,Same),

length(Same,S),

S>0,

ord_subtract(OX,Same,UX),

ord_subtract(OY,Same,UY) |

gt([sum(UX)],[sum(UY)]).

Fig. 8: A rule for mutating gt/2 constraints containing sums.

This rule takes care of gt/2 constraints containing two sum statements andsimpli�es them using algebraic simpli�cation (eliminating the mutually

12

intersecting elements in both sums). Rules to handle geq/2 and eq/1constraints containing two sums are very much similar to this rule. The sameis true for rules handling constraints that contain a single sum statement. Dueto the length of these rules they will now be shown here and it is counted onthat the reader can �gure them out with his/her own imagination.

With these CHR constraints representing inequalities and the explained CHRrulesets, it is possible to perform inequality reasoning. In order to use CHRinequality reasoning for Qualitative Reasoning, a good framework is needed.This will be the topic of the next section.

7 Inequality Reasoning for QR using CHR

During this research, a CHR inequality reasoning framework for QR, consistingof several separate modules, has been designed. This chapter �rst explains thegeneral idea of the framework. Next, all separate modules in the framework arediscussed.

7.1 CHR Inequality Reasoning Framework

Each module in the proposed framework contains a set of CHR rules and isdesigned to perform a speci�c task. An overview of the framework can be seenin �gure 9. The set of QR interface rules can be seen as an interface to theframework. These rules accept a variety of QR statements, converting them toa suitable CHR representation and preparing them for the CHR adding rules.The interface rules also transform all inequality statements to their canonicalrepresentation, only allowing {=,≥ and >} relations. This prevents theexistence of equivalent relational statements (e.g. X > Y and Y < X), hencepreventing unnecessary complexities when processing these statements. TheCHR adding rules �lter out contradictory and super�uous statements whichare presented to the system. Filtering the former is necessary to detectcontradictions, �ltering the latter prevents the execution of unnecessarycomputations 3. The CHR mutation rules take care of the actual inequalityreasoning. Here the framework incorporates the CHR inequality reasoningrules explained in previous section in order to derive new inequalities usingalgebraic simpli�cation, anti-symmetry and transitivity. The QR outputtranslation rules are �nally meant for exporting the �nal inequality statementsfrom their CHR constraint from to a QR form.

3Which is very important considering the prevention of combinatorial explosion.

13

Fig. 9: The CHR Reasoning Framework contains several modules, each taking care of aspeci�c task. The QR interface rules translate QR statements to CHR constraints.The CHR adding rules �lter out new CHR constraints which represent contradictoryand super�uous relations. The CHR mutation rules take care of interactionbetween inequalities and make new derivations. The QR output translation rulesprovide means to export the �nal inequalities.

7.2 Module: QR Interface Rules

The QR interface rules take care of a speci�c task in the framework. They acton a set of speci�c constraints that can be used in order to add new informationto the system. All of these constraints (qr_quantity/2, qr_inequality/3 andqr_correspondence/4) can only be used by the rules in the QR interface module,preventing statements to be entered in other modules without passing throughthis module.

14

qr_quantity(Name,QS) <=> log(addTry,quantity(Name,QS)) |

quantity(Name,QS).

qr_inequality(eq,X,Y) <=> log(addTry,eq(X,Y)) |

inequality(eq,X,Y).

qr_inequality(geq,X,Y) <=> log(addTry,geq(X,Y)) |

inequality(geq,X,Y).

qr_inequality(leq,X,Y) <=> log(addTry,geq(Y,X)) |

inequality(geq,Y,X).

qr_inequality(gt,X,Y) <=> log(addTry,gt(X,Y)) |

inequality(gt,X,Y).

qr_inequality(lt,X,Y) <=> log(addTry,gt(Y,X)) |

inequality(gt,Y,X).

qr_correspondence(D,S,X,Y) <=> count(id,ID),

log(addTry,correspondence(D,S,X,Y)) |

correspondence(ID,D,S,X,Y), fire(ID).

Fig. 10: The QR Interface Rules, logging additions of new statements, convertinginequalities to their canonical form and adding a �re/1 constraint to the systemwhen adding a correspondence.

The qr_quantity/2 constraint can be used to add new quantities to thesystem by providing a name (Name) and a quantity space (QS). Theqr_inequality/3 constraint can be used to add new inequalities to thesystem by providing the type of the inequality (eq, geq, leq, gt or lt) and twoentities. The qr_correspondence/4 constraint can be used to add newcorrespondences to the system by providing the directedness (D, eitherdirected or undirected), the sort (S, can be magnitude, derivative,magnitudeReverse, derivativeReverse, full or fullReverse), and two quantitiesor speci�c quantity values for a quantity between which the correspondencehas to be created.

The rules in this module keep track new additions to the system by writing allactions to a log (log/2 is a helper predicate written in normal Prolog).Inequality statements are converted to their canonical form here. Whenadding a correspondence to the system, these rules also introduce a �re/1constraint with a unique ID. This is necessary to enable the tracking all partsof a complex correspondence so they can be prevented from "�ring" (beingadded to the system) when one of the parts would introduce a contradiction inthe system.

The constraints introduced by this module (inequality/3, correspondence/5 and�re/1) can now be used by the CHR adding rules in order to further processthem.

15

7.3 Module: CHR Adding Rules

The CHR adding rules perform the task of recognizing and �ltering outcontradictory and super�uous statements. When a statement is notcontradictory or super�uous, it will be added to the system. This module isthe only one where quantity/2, inequality/3, correspondence/5 and �re/1statements can be processed. This module contains rules like the following:

gt(X,Y)#passive \ inequality(gt,X,Y) <=> log(superFl,gt(X,Y))

| true.

gt(A,B)#passive \ inequality(gt,X,Y) <=> member(X,B),

member(Y,A),

log(contraD,gt(X,Y))

| true.

inequality(gt,X,Y) <=> log(added,gt(X,Y))

| gt([X],[Y]).

Fig. 11: Example of CHR adding rules

The �rst of these rules is an example of a rule for removing super�uousinequality statements that is being added to the system. This rule takes careof removing the statement and logging this action. The second rule does thesame thing for a contradictory statement. The last rule is meant to add aninequality constraint to the system so the CHR mutation rules can use them,when it is clear that the inequality is not super�uous or does introduce acontradiction. This principle is also used for the quantity/2 constraint (whichcan be super�uous).

The correspondence/5 constraint is handled quite di�erently. A complexcorrespondence statement, like a full quantity space correspondence, are splitup into several undirected correspondences for all values of the quantity space.All these undirected correspondences be split up into two directedcorrespondences each. In order to be sure a complex correspondence does notintroduce a contradiction, it is split up into single directed correspondences inthe system. All these single directed correspondences are represented with aadd_corr/3 constraint (containing an ID and the values of two quantities) andhave the same ID as the original correspondence and the �re/1 statementintroduced by the QR interface rules. When one of these single directedcorrespondences creates a contradiction, a contradiction/1 constraint isintroduced, having the ID of the single directed correspondence as itsargument. When this happens, the active contradiction/1 constraint will be�red with a rule and remove all the add_corr/3 constraints with a similar IDas in the contradiction/1 constraint.

16

7.4 Module: CHR Mutation Rules

The mutation rules are similar to the inequality reasoning rules explained in 6.For this module they have been enriched with logging statements. New ruleshave also been added to handle correspondences and value assignments ofquantities. These rules take care of the actual inequality reasoning in thesystem. They also take care of the saving of the state after the system is doneprocessing constraints, and of the restoration of constraints when a state hasto be re-entered in the system.

After processing, the information in the system can be exported to a QR formusing the QR output translation rules.

7.5 Module: QR Ouptut Translation Rules

The QR output translation rules are a means to export the informationrepresented by the constraint in the system. They take care of translation ofthe inequality statements to the form desired by the QR workbench at hand.

8 Evaluation

Evalutation of the CHR inequality reasoning framework for CHR has beenperformed on two aspects: correctness and performance. In order to improve

8.1 Evaluation: Non-QR Models

For the evaluation of the CHR inequality reasoning software, several non-QRmodels have been used. These were simple models making only use of severalentities and relations. An example of such a model would be the following:

qr_inequality(eq,a,b)

qr_inequality(eq,b,c)

qr_inequality(eq,c,d)

qr_inequality(gt,e,a)

Fig. 12: Example of a non-QR model

After processing this model using the CHR inequality reasoning framework, thesystem correctly derives that a, b, c and d are equal and that e is greater thanall of these entities. For all of this kind of toy problems, the system performsthe ways it should.

17

8.2 Evaluation: Hand-Generated QR Models

Using hand-generated QR models, the CHR inequality reasoning frameworkhandles models containing quantities (containing sum statements), inequalitiesand correspondences the same way the Garp3 framework does.

8.3 Evaluation: Computer-Generated QR Models

A Computer-generated QR models are usually complex and can well be used tomeasure performance in terms of speed. A lot of work has been spent on this,but several design di�erences between Garp3 and the CHR inequality reasoningframework made it hard to have a direct comparison in speed between bothsystems. Hence this is something intended for future research.

9 Conclusion & Future Work

In this research, qualitative inequality reasoning has been represented usingCHR. This is a bene�t compared to the numerical implementations of inequalityreasoning which are imperative when using other CLP languages.This research also shows this it is possible to implement the proposed CHRinequality reasoning for QR software such as Garp3. There are goodindications that computational performance will bene�t from this newpresentation because CHR rules are committed choice and do not allowbacktracking, hence preventing combinatorial explosion. The good support formulti-threading with CHR might also help improve the performance, thoughthis has not been conclusively con�rmed.For future work, it would be interesting to see how the proposedrepresentation can be extended to account for more functionalities within QRreasoning. It would also be interesting to �nd a good way of benchmarking thenew inequality reasoning framework against the inequality reasoning algorithmused in Garp3. Furthermore, benchmarking and improving the currentmulti-threading algorithm would be useful, since this might lead to substantialgains in processing speed and easy scaling for development with multi-corearchitectures.

Acknowledgements

I want to thank my supervisors Bert Bredeweg and Jochem Liem for theirsupport and involvement in this research. They helped me through several toughmoments and I am really grateful for this. I also want to thank the Dynalearncrew for letting me work in their o�ce, and in particular Floris Linnebank forhelping me understand the Dynalearn/Garp3 engine.

18

References

[BLBL09] Bert Bredeweg, Floris Linnebach, Anders Bouwer, and JochemLiem. Garp 3 workbench for qualitative modelling and simulation.Ecological Informatics, Volume 4:Pages 263�281, 2009.

[Col90] Alain Colmerauer. An introduction to prolog iii. Commun. ACM,33:69�90, July 1990.

[DVHS+88] M. Dincbas, P. Van Hentenryck, H. Simonis, A. Aggoun, andA. Herold. The chip system : Constraint handling in prolog.In Ewing Lusk and Ross Overbeek, editors, 9th International

Conference on Automated Deduction, volume 310 of Lecture Notes

in Computer Science, pages 774�775. Springer Berlin / Heidelberg,1988. 10.1007/BFb0012892.

[FHK+92] Thom Frühwirth, Alexander Herold, Volker Küchenho�, ThierryLe Provost, Pierre Lim, Eric Monfroy, and Mark Wallace.Constraint logic programming. In G. Comyn, N. Fuchs, andM. Ratcli�e, editors, Logic Programming in Action, volume 636of Lecture Notes in Computer Science, pages 3�35. Springer Berlin/ Heidelberg, 1992.

[Frü98] Thom Frühwirth. Theory and practice of constraint handling rules.The Journal of Logic Programming, 37(1-3):95 � 138, 1998.

[LS07] Edmund S. L. Lam and Martin Sulzmann. A concurrentconstraint handling rules implementation in haskell with softwaretransactional memory. In Proceedings of the 2007 workshop on

Declarative aspects of multicore programming, DAMP '07, pages19�24, New York, NY, USA, 2007. ACM.

[Sch08] Tom Schrijvers. Constraint handling rules. In Maria Garcia de laBanda and Enrico Pontelli, editors, Logic Programming, volume5366 of Lecture Notes in Computer Science, pages 9�10. SpringerBerlin / Heidelberg, 2008.

[SSD09] Jon Sneyers, Tom Schrijvers, and Bart Demoen. The computationalpower and complexity of constraint handling rules. ACM Trans.

Program. Lang. Syst., 31:8:1�8:42, February 2009.

[Tel96] László Teleki. Embedding qualitative reasoning into constraintlogic programming. 96.

19