Smodels: A System for Answer Set Programming

03/08/2000 ∙ by Ilkka Niemelä, et al. ∙ 0

The Smodels system implements the stable model semantics for normal logic programs. It handles a subclass of programs which contain no function symbols and are domain-restricted but supports extensions including built-in functions as well as cardinality and weight constraints. On top of this core engine more involved systems can be built. As an example, we have implemented total and partial stable model computation for disjunctive logic programs. An interesting application method is based on answer set programming, i.e., encoding an application problem as a set of rules so that its solutions are captured by the stable models of the rules. Smodels has been applied to a number of areas including planning, model checking, reachability analysis, product configuration, dynamic constraint satisfaction, and feature interaction.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 General Information

The Smodels system is written in C++ and the source code, test cases and documentation are available at http://www.tcs.hut.fi/Software/smodels/. In order to compile the system a C++ compiler is needed as well as other standard tools such as make, tar, bison, and perl. The system has been developed under Linux and should work as is on any platform having the appropriate GNU tools installed. It has been used on a wide range of hardware (PC/SPARC/Alpha) mostly running Unix. The total number of lines of codes is about 20000.

2 Description of the System

The Smodels system implements the stable model semantics for normal logic programs extended by built-in functions as well as cardinality and weight constraints for domain-restricted programs. In this section we briefly discuss the syntax, implementation techniques and use of the system. More information can be found at the home page http://www.tcs.hut.fi/Software/smodels/.

As input the Smodels system takes logic program rules basically in Prolog style syntax:

    ancestor(X,Y) :- ancestor(X,Z),
                     parent(Z,Y),
                     person(X).
    ancestor(X,Y) :- parent(X,Y).
    son(X,Y) :- parent(Y,X), male(X).
    daughter(X,Y) :- parent(Y,X), female(X).
    person(X) :- male(X).
    person(X) :- female(X).
    parent(jack, jill). parent(joan, jack).
    male(jack). female(jill). female(joan).

However, in order to support efficient implementation techniques and extensions the programs are required to be domain-restricted where the idea is the following. No proper function symbols are allowed (but we do allow built-in functions) and the predicate symbols in the program are divided into two classes, domain predicates and non-domain predicates. Domain predicates are predicates that are defined non-recursively. In the program above all predicates except ancestor are domain predicates. The predicate ancestor is not a domain predicate because it depends recursively on itself.

The main intuition of domain predicates is that they are used to define the set of terms over which the variables range in each rule of a program . All rules of have to be domain-restricted in the sense that every variable in a rule must appear in a domain predicate which appears positively in the rule body. For instance, in the first rule of the program above all variables appear in domain predicates parent and person in the body of the rule.

In addition to normal logic program rules, Smodels supports rules with cardinality and weight constraints. The idea is that, e.g., a cardinality constraint

holds in a stable model if at the least 1 but at most 2 of the literals in the constraint are satisfied in the model and a weight constraint

holds if the sum of weights of the literals satisfied in the model is between 10 and 20 (inclusive). With built-in functions for integer arithmetic (included in the system), these kinds of rules allow compact and fairly straightforward encodings of many interesting problems. For example, the N queens problem can be captured using rules as a program queens.lp as follows:

    1 { q(X,Y):d(X) } 1 :- d(Y).
    1 { q(X,Y):d(Y) } 1 :- d(X).
    :- d(X), d(Y), d(X1), d(Y1),
       q(X,Y), q(X1,Y1),
       X != X1,  Y != Y1,
       abs(X - X1) == abs(Y - Y1).
    d(1..n).

where d(1..n) is a domain predicate giving the dimension of the board (from 1 to integer which can be specified during run time). The first rule says that for each row , a stable model contains exactly one atom where for , holds and similarly in the second rule for all columns. The third rule is an integrity constraint saying that there cannot be two queens on the same diagonal. Now each stable model corresponds to a legal configuration of queens on a board, i.e., is in a stable model iff is a legal position for a queen.

Stable models of a domain-restricted logic program with variables are computed in three stages. First, the program is transformed into a ground program without variables. Second, the rules of the ground program are translated into primitive rules, and third, a stable model is computed using a Davis-Putnam like procedure [Simons1999]. The first two stages have been implemented in the program lparse, which functions as a front end to smodels which in turn implements the third stage.

In the first stage lparse automatically determines the domain predicates and then using database techniques evaluates the domain predicates and creates a ground program which has exactly the same stable models as the original program with variables. Then the rules are compiled into primitive rules [Niemelä, Simons, & Soininen1999].

The smodels procedure is a Davis-Putnam like backtracking search procedure that finds the stable models of a set of primitive rules by assigning truth values to the atoms of the program. Moreover, it uses the properties of the stable model semantics to infer and propagate additional truth values. Since the procedure is in effect traversing a binary search tree, the number of nodes in the search space is in the worst case on the order of , where can be taken to be the number of atoms that appear in a constraint in a head of a rule or that appear as a negative literal in a recursive loop of the program.

Hence, in order to compute stable models, one uses the two programs lparse, which translates logic programs into an internal format, and smodels, which computes the models, see Figure 1.

lparseinternalrepresentationsmodelsstablemodels
Figure 1: Overall Architecture

For instance, a solution to the 8 queens problem given the program queens.lp above, would be typically computed by a command line:

lparse -c n=8 -d none queens.lp | smodels

where -c n=8 option instructs to use the value 8 for the constant and -d none option instructs to remove all domain predicates from the rules as soon as they have been evaluated. The command line produces output:

Answer: 1
Stable Model: q(4,1) q(2,2) q(7,3) q(5,4)
q(1,5) q(8,6) q(6,7) q(3,8)

2.1 A Further Example

The graph coloring problem may be encoded to a program ncolor.lp using the following two Smodels rules:

  1 { col(N, C) : color(C) } 1 :- node(N).
  :- col(X, C), col(Y,C), edge(X,Y), color(C).

Here the predicate col(N,C) denotes that the color of the node N is C. The first rule states that each node has exactly one color and the second rule states that two adjacent nodes may not have the same color. Suppose we have a fully connected three node graph and we want to find all 3-colorings of it where the first node is colored red. We can encode the problem instance to a program graph.lp:

  node(a ; b; c).
  edge(a,b). edge(a,c). edge(b,c).
  color(red ; green ; blue).
  compute { col(a, red) }.

The first two lines define the graph and the third line defines the three colors. The compute statement tells Smodels that we are interested only in those models where col(a, red) is true, i.e., the node a has color red. We can find all stable models that satisfy the compute statement with the command line:

lparse -d none ncolor.lp graph.lp | smodels 0

This input produces the output:

Answer: 1
Stable Model: col(c,blue) col(b,green)
col(a,red)
Answer: 2
Stable Model: col(c,green) col(b,blue)
col(a,red)

More information about the syntax and use of the system can be found in the lparse user’s manual at http://www.tcs.hut.fi/Software/smodels/lparse/ and about the implementation in [Simons1999, Niemelä, Simons, & Soininen1999].

3 Applying the System

3.1 Methodology

An interesting application methodology for Smodels is based on answer set programming [Marek & Truszczyński1999, Niemelä1999] which has emerged as a viable approach to declarative logic-based knowledge representation. It is based on the stable model semantics of logic programs and can be seen as a novel form of constraint programming where constraints are expressed as rules. The underlying idea is to encode an application problem using logic program rules so that the solutions to the problem are captured by the stable models of the rules. The solution of the N queens problem in the previous section illustrates nicely main ideas of answer set programming.

3.2 Specifics

It is important that the system is based on an implementation-independent declarative semantics. This makes it much easier to develop applications because one does not have to worry too much about the internal implementation-specific aspects of the system. Hence, the system is relatively easy to learn to use. On the other hand, declarative semantics provides much more flexibility in developing implementation approaches and in optimizing different parts of the implementation. We have taken advantage of this and developed methods which are substantially different from usual implementation methods for logic programming (Prolog) but still work efficiently in new kinds of applications where Prolog style systems are not appropriate.

Smodels implements the stable model semantics for range-restricted function free normal programs. It can also compute well-founded models for these programs. Smodels supports built-in functions, e.g., for integer arithmetic. Basic Smodels extends normal logic programs with cardinality and weight constraints [Simons1999, Niemelä, Simons, & Soininen1999]. On top of this core engine more involved systems can be built. As an example, we have implemented total and partial stable model computation for disjunctive logic programs [Janhunen et al.2000].

The semantics for logic programs with cardinality and weight constraints supported by the core engine is an interesting compromise: it is rather simple to learn, its complexity stays in NP in the ground case (like for propositional logic) but it seems strictly more expressive than propositional logic (or other standard constraint satisfaction formalisms).

With our work on Smodels we hope to demonstrate that nonmonotonic reasoning techniques are useful conceptual tools as well as bring computational advantages which can lead to new interesting applications and to developments of novel implementation techniques and tools.

3.3 Users and Usability

The basic semantics of Smodels rules seems to be simple enough that it can be explained to a non-expert or a student in a relatively short amount of time sufficiently so that one can start using Smodels.

Smodels has been employed in a number of areas including planning [Dimopoulos, Nebel, & Koehler1997, Niemelä1999, Lifschitz1999], model checking [Liu, Ramakrishnan, & Smolka1998], reachability analysis [Heljanko1999a, Heljanko1999b], product configuration [Soininen & Niemelä1999, Syrjänen1999], dynamic constraint satisfaction [Soininen, Niemelä, & Gelle1999], feature interaction [Accorsi, Areces, & de Rijke1999], and logical cryptanalysis [Hietalahti, Massacci, & Niemelä2000].

In order to make Smodels more flexible an API has been added to lparse and smodels. Hence, they can be used through the API and embedded into a C/C++ program as libraries. Furthermore, it is possible to define new built-in functions for the front-end lparse in order to accommodate new applications. These new functions are written in C/C++ and they are dynamically linked to lparse when needed.

As a further usability feature, lparse performs simple analysis of the program and warns about constructs that are often erroneous. For example, lparse detects if a variable is accidentally mistyped as a constant or vice versa. These warnings can be enabled with command line options.

4 Evaluating the System

4.1 Benchmarks

We have compiled quite a large collection of families of benchmarks that we use to evaluate new developments and improvements in our system and which we can employ to compare our system to other competing ones and which can be used also by others (see, http://www.tcs.hut.fi/Software/smodels/tests/). Similar testing methodology (e.g., generating test cases from graph problems) has also been used by the groups in Kentucky (DeReS/TheoryBase system [Cholewiński et al.1999]) and in Vienna (dlv system [Eiter et al.1998]). These kinds of tests can be used for measuring the base level performance and to compare different systems. However, it is unclear what is a portable way of representing such benchmarks. We use Prolog style syntax which is quite generally accepted but it seems that each system has its specialties.

4.2 Comparison

Smodels can already compete with special purpose systems and we have even cases where it outperforms commercial top edge tools, e.g., in a verification application it has performance better than that of one of the most efficient commercial integer programming tools (CPLEX) [Heljanko1999b].

4.3 Problem Size

We believe that Smodels is no longer a mere prototype but it can handle realistic size problems. We have applications where programs with hundreds of thousands of non-trivial ground rules are treated efficiently, see e.g. [Niemelä1999, Heljanko1999b].

References

  • [Accorsi, Areces, & de Rijke1999] Accorsi, R.; Areces, C.; and de Rijke, M. 1999. Towards feature interaction via stable models. In Proceedings of the Second Workshop on Formal Methods.
  • [Cholewiński et al.1999] Cholewiński, P.; Marek, V.; Mikitiuk, A.; and Truszczyński, M. 1999. Computing with default logic. Artificial Intelligence 112:105–146.
  • [Dimopoulos, Nebel, & Koehler1997] Dimopoulos, Y.; Nebel, B.; and Koehler, J. 1997. Encoding planning problems in non-monotonic logic programs. In Proceedings of the Fourth European Conference on Planning, 169–181. Toulouse, France: Springer-Verlag.
  • [Eiter et al.1998] Eiter, T.; Leone, N.; Mateis, C.; Pfeifer, G.; and Scarnello, F. 1998. The KR system dlv: Progress report, comparisons and benchmarks. In Proceedings of the 6th International Conference on Principles of Knowledge Representation and Reasoning, 406–417. Trento, Italy: Morgan Kaufmann Publishers.
  • [Heljanko1999a] Heljanko, K. 1999a. Using logic programs with stable model semantics to solve deadlock and reachability problems for 1-safe Petri nets. In Proceedings of the 5th International Conference on Tools and Algorithms for the Construction and Analysis of Systems, 240–254. Amsterdam, the Netherlands: Springer-Verlag.
  • [Heljanko1999b] Heljanko, K. 1999b. Using logic programs with stable model semantics to solve deadlock and reachability problems for 1-safe Petri nets. Fundamenta Informaticae 37(3):247–268.
  • [Hietalahti, Massacci, & Niemelä2000] Hietalahti, M.; Massacci, F.; and Niemelä, I. 2000. DES: a challenge problem for nonmonotonic reasoning systems. In Proceedings of the 8th International Workshop on Non-Monotonic Reasoning. Accepted for publication.
  • [Janhunen et al.2000] Janhunen, T.; Niemelä, I.; Simons, P.; and You, J. 2000. Unfolding partiality and disjunctions in stable model semantics. In Cohn, A.; Guinchiglia, F.; and Selman, B., eds., Proceedings of the Seventh International Conference on Principles of Knowledge Representation and Reasoning. Breckenridge, Colorado, USA: Morgan Kaufmann Publishers. Accepted for publication.
  • [Lifschitz1999] Lifschitz, V. 1999. Answer set planning. In Proceedings of the 16th International Conference on Logic Programming, 25–37. Las Cruces, New Mexico: The MIT Press.
  • [Liu, Ramakrishnan, & Smolka1998] Liu, X.; Ramakrishnan, C.; and Smolka, S. A. 1998. Fully local and efficient evaluation of alternating fixed points. In Steffen, B., ed., Proceedings of the 4th International Conference on Tools and Algorithms for the Construction and Analysis of Systems, 5–19. Lisbon, Portugal: Springer-Verlag.
  • [Marek & Truszczyński1999] Marek, W., and Truszczyński, M. 1999. Stable models and an alternative logic programming paradigm. In The Logic Programming Paradigm: a 25-Year Perspective. Springer-Verlag. 375–398.
  • [Niemelä, Simons, & Soininen1999] Niemelä, I.; Simons, P.; and Soininen, T. 1999. Stable model semantics of weight constraint rules. In Proceedings of the 5th International Conference on Logic Programming and Nonmonotonic Reasoning, 317–331. El Paso, Texas, USA: Springer-Verlag.
  • [Niemelä1999] Niemelä, I. 1999. Logic programming with stable model semantics as a constraint programming paradigm. Annals of Mathematics and Artificial Intelligence 25(3,4):241–273.
  • [Simons1999] Simons, P. 1999. Extending the stable model semantics with more expressive rules. In Proceedings of the 5th International Conference on Logic Programming and Nonmonotonic Reasoning, 305–316. El Paso, Texas, USA: Springer-Verlag.
  • [Soininen & Niemelä1999] Soininen, T., and Niemelä, I. 1999. Developing a declarative rule language for applications in product configuration. In Gupta, G., ed., Proceedings of the First International Workshop on Practical Aspects of Declarative Languages, 305–319. San Antonio, Texas: Springer-Verlag.
  • [Soininen, Niemelä, & Gelle1999] Soininen, T.; Niemelä, I.; and Gelle, E. 1999. A fixpoint definition of dynamic constraint satisfaction. In Jaffar, J., ed., Proceedings of the Fifth International Conference on Principles and Practice of Constraint Programming, 419–433. Alexandria, Virginia, USA: Springer-Verlag.
  • [Syrjänen1999] Syrjänen, T. 1999. A rule-based formal model for software configuration. Research report A55, Helsinki University of Technology, Laboratory for Theoretical Computer Science, Helsinki, Finland.