Answer set programming should not be confused with Active Server Pages.
Answer set programming (ASP) is a form of declarative programming oriented towards difficult (primarily NP-hard) search problems. It is based on the stable model (answer set) semantics of logic programming. In ASP, search problems are reduced to computing stable models, and answer set solvers—programs for generating stable models—are used to perform search. The computational process employed in the design of many answer set solvers is an enhancement of the DPLL algorithm and, in principle, it always terminates (unlike Prolog query evaluation, which may lead to an infinite loop).
In a more general sense, ASP includes all applications of answer sets to knowledge representation and reasoning[1] [2] and the use of Prolog-style query evaluation for solving problems arising in these applications.
An early example of answer set programming was the planning method proposed in 1997 by Dimopoulos, Nebel and Köhler.[3] [4] Their approach is based on the relationship between plans and stable models.[5] In 1998 Soininen and Niemelä applied what is now known as answer set programming to the problem of product configuration.[4] In 1999, the term "answer set programming" appeared for the first time in a book The Logic Programming Paradigm as the title of a collection of two papers.[4] The first of these papers identified the use of answer set solvers for search as a new programming paradigm.[6] That same year Niemelä also proposed "logic programs with stable model semantics" as a new paradigm.[7]
Lparse is the name of the program that was originally created as a grounding tool (front-end) for the answer set solver smodels. The language that Lparse accepts is now commonly called AnsProlog,[8] short for Answer Set Programming in Logic.[9] It is now used in the same way in many other answer set solvers, including assat, clasp, cmodels, gNt, nomore++ and pbmodels. (dlv is an exception; the syntax of ASP programs written for dlv is somewhat different.) An AnsProlog program consists of rules of the form
The symbol :- ("if") is dropped if <body> is empty; such rules are called facts. The simplest kind of Lparse rules are rules with constraints.
One other useful construct included in this language is choice. For instance, the choice rule
says: choose arbitrarily which of the atoms
p,q,r
\{p,q,r\}
(p\lor\negp)\land(q\lor\negq)\land(r\lor\negr).
The language of Lparse allows us also to write "constrained" choice rules, such as
This rule says: choose at least 1 of the atoms
p,q,r
(p\lor\negp)\land(q\lor\negq)\land(r\lor\negr)
\land(p\lorq\lorr)\land\neg(p\landq\landr).
Cardinality bounds can be used in the body of a rule as well, for instance:
- 2.
Adding this constraint to an Lparse program eliminates the stable models that contain at least 2 of the atoms
p,q,r
\neg((p\landq)\lor(p\landr)\lor(q\landr)).
Variables (capitalized, as in Prolog) are used in Lparse to abbreviate collections of rules that follow the same pattern, and also to abbreviate collections of atoms within the same rule. For instance, the Lparse program
has the same meaning as
The program
is shorthand for
A range is of the form:
is a shortcut for
Ranges can also be used in rule bodies with the same semantics.
A conditional literal is of the form:
If the extension of q is {q(a1), q(a2), ..., q(aN)}, the above condition is semantically equivalent to writing {p(a1), p(a2), ..., p(aN)} in the place of the condition. For example,
is a shorthand for
To find a stable model of the Lparse program stored in file ${filename} we use the command
Option 0 instructs smodels to find all stable models of the program. For instance, if file test contains the rules
then the command produces the output
An
n
G=\left\langV,E\right\rang
color:V\to\{1,...,n\}
color(x) ≠ color(y)
(x,y)\inE
n
This can be accomplished using the following Lparse program:
- color(X,I), color(Y,I), e(X,Y), c(I).
Line 1 defines the numbers
1,...,n
i
x
x
y
If we combine this file with a definition of
G
and run smodels on it, with the numeric value of
n
color(...,...)
n
G
The program in this example illustrates the "generate-and-test" organization that is often found in simple ASP programs. The choice rule describes a set of "potential solutions"—a simple superset of the set of solutions to the given search problem. It is followed by a constraint, which eliminates all potential solutions that are not acceptable. However, the search process employed by smodels and other answer set solvers is not based on trial and error.
A clique in a graph is a set of pairwise adjacent vertices. The following Lparse program finds a clique of size
\geqn
- in(X), in(Y), X!=Y, not e(X,Y).
This is another example of the generate-and-test organization. The choice rule in Line 1 "generates" all sets consisting of
\geqn
A Hamiltonian cycle in a directed graph is a cycle that passes through each vertex of the graph exactly once. The following Lparse program can be used to find a Hamiltonian cycle in a given directed graph if it exists; we assume that 0 is one of the vertices.
- 2, v(X).
- 2, v(Y).
r(X) :- in(0,X), v(X).r(Y) :- r(X), in(X,Y), e(X,Y).
- not r(X), v(X).
The choice rule in Line 1 "generates" all subsets of the set of edges. The three constraints "weed out" the subsets that are not Hamiltonian cycles. The last of them uses the auxiliary predicate
r(x)
x
This program is an example of the more general "generate, define and test" organization: it includes the definition of an auxiliary predicate that helps us eliminate all "bad" potential solutions.
In natural language processing, dependency-based parsing can be formulated as an ASP problem.[12] The following code parses the Latin sentence "Puella pulchra in villa linguam latinam discit", "the pretty girl is learning Latin in the villa".The syntax tree is expressed by the arc predicates which represent the dependencies between the words of the sentence.The computed structure is a linearly ordered rooted tree.
- arc(X, Z, _), arc(Y, Z, _), X != Y.
- arc(X, Y, L1), arc(X, Y, L2), L1 != L2.path(X, Y) :- arc(X, Y, _).path(X, Z) :- arc(X, Y, _), path(Y, Z).
- path(X, X).
- root(X), node(Y, _), X != Y, not path(X, Y).leaf(X) :- node(X, _), not arc(X, _, _).
The ASP standardization working group produced a standard language specification, called ASP-Core-2,[13] towards which recent ASP systems are converging. ASP-Core-2 is the reference language for the Answer Set Programming Competition, in which ASP solvers are periodically benchmarked over a number of reference problems.
Early systems, such as smodels, used backtracking to find solutions. As the theory and practice of Boolean SAT solvers evolved, a number of ASP solvers were built on top of SAT solvers, including ASSAT and Cmodels. These converted ASP formula into SAT propositions, applied the SAT solver, and then converted the solutions back to ASP form. More recent systems, such as Clasp, use a hybrid approach, using conflict-driven algorithms inspired by SAT, without fully converting into a Boolean-logic form. These approaches allow for significant improvements of performance, often by an order of magnitude, over earlier backtracking algorithms.
The Potassco project acts as an umbrella for many of the systems below, including clasp, grounding systems (gringo), incremental systems (iclingo), constraint solvers (clingcon), action language to ASP compilers (coala), distributed Message Passing Interface implementations (claspar), and many others.
Most systems support variables, but only indirectly, by forcing grounding, by using a grounding system such as Lparse or gringo as a front end. The need for grounding can cause a combinatorial explosion of clauses; thus, systems that perform on-the-fly grounding might have an advantage.[14]
Query-driven implementations of answer set programming, such as the Galliwasp system[15] and s(CASP)[16] avoid grounding altogether by using a combination of resolution and coinduction.
| Platform | Features | Mechanics | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Name | OS | Licence | Variables | Function symbols | Explicit sets | Explicit lists | Disjunctive (choice rules) support | |||
| ASPeRiX | Linux | GPL | on-the-fly grounding | |||||||
| ASSAT | Solaris | Freeware | SAT-solver based | |||||||
| Clasp Answer Set Solver | Linux, macOS, Windows | MIT License | incremental, SAT-solver inspired (nogood, conflict-driven) | |||||||
| Cmodels | Linux, Solaris | GPL | incremental, SAT-solver inspired (nogood, conflict-driven) | |||||||
| diff-SAT | Linux, macOS, Windows (Java virtual machine) | MIT License | SAT-solver inspired (nogood, conflict-driven). Supports solving probabilistic problems and answer set sampling | |||||||
| DLV | Linux, macOS, Windows[17] | free for academic and non-commercial educational use, and for non-profit organizations | not Lparse compatible | |||||||
| DLV-Complex | Linux, macOS, Windows | GPL | built on top of DLV — not Lparse compatible | |||||||
| GnT | Linux | GPL | built on top of smodels | |||||||
| nomore++ | Linux | GPL | combined literal+rule-based | |||||||
| Platypus | Linux, Solaris, Windows | GPL | distributed, multi-threaded nomore++, smodels | |||||||
| Pbmodels | Linux | ? | pseudo-boolean solver based | |||||||
| Smodels | Linux, macOS, Windows | GPL | ||||||||
| Smodels-cc | Linux | ? | SAT-solver based; smodels w/conflict clauses | |||||||
| Sup | Linux | ? | SAT-solver based | |||||||