Answer Set Programming Book
Uploaded by
dare gateAnswer Set Programming Book
Uploaded by
dare gateAnswer Set Programming
Torsten Schaub
University of Potsdam
FMCAD@Cambridge
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 1 / 178
Rough Roadmap
1 Motivation
2 Introduction
3 Modeling
4 Systems
5 Conclusion
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 2 / 178
Motivation: Overview
1 Motivation
2 Nutshell
3 Shifting paradigms
4 Rooting ASP
5 ASP solving
6 Using ASP
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 3 / 178
Motivation
Outline
1 Motivation
2 Nutshell
3 Shifting paradigms
4 Rooting ASP
5 ASP solving
6 Using ASP
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 4 / 178
Motivation
Informatics
“What is the problem?” versus “How to solve the problem?”
Problem Solution
6
?
Computer - Output
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 5 / 178
Motivation
Informatics
“What is the problem?” versus “How to solve the problem?”
Problem Solution
6
?
Computer - Output
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 5 / 178
Motivation
Traditional programming
“What is the problem?” versus “How to solve the problem?”
Problem Solution
6
?
Computer - Output
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 5 / 178
Motivation
Traditional programming
“What is the problem?” versus “How to solve the problem?”
Problem Solution
6
Programming Interpreting
?
Program - Output
Executing
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 5 / 178
Motivation
Declarative problem solving
“What is the problem?” versus “How to solve the problem?”
Problem Solution
6
Interpreting
?
Computer - Output
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 5 / 178
Motivation
Declarative problem solving
“What is the problem?” versus “How to solve the problem?”
Problem Solution
6
Modeling Interpreting
?
Representation - Output
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 5 / 178
Motivation
Declarative problem solving
“What is the problem?” versus “How to solve the problem?”
Problem Solution
6
Modeling Interpreting
?
Representation - Output
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 5 / 178
Nutshell
Outline
1 Motivation
2 Nutshell
3 Shifting paradigms
4 Rooting ASP
5 ASP solving
6 Using ASP
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 6 / 178
Nutshell
Answer Set Programming
in a Nutshell
ASP is an approach to declarative problem solving, combining
a rich yet simple modeling language
with high-performance solving capacities
ASP has its roots in
(deductive) databases
logic programming (with negation)
(logic-based) knowledge representation and (nonmonotonic) reasoning
constraint solving (in particular, SATisfiability testing)
ASP allows for solving all search problems in NP (and NP NP )
in a uniform way
ASP is versatile as reflected by the ASP solver clasp, winning
first places at ASP, CASC, MISC, PB, and SAT competitions
ASP embraces many emerging application areas
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 7 / 178
Nutshell
Answer Set Programming
in a Nutshell
ASP is an approach to declarative problem solving, combining
a rich yet simple modeling language
with high-performance solving capacities
ASP has its roots in
(deductive) databases
logic programming (with negation)
(logic-based) knowledge representation and (nonmonotonic) reasoning
constraint solving (in particular, SATisfiability testing)
ASP allows for solving all search problems in NP (and NP NP )
in a uniform way
ASP is versatile as reflected by the ASP solver clasp, winning
first places at ASP, CASC, MISC, PB, and SAT competitions
ASP embraces many emerging application areas
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 7 / 178
Nutshell
Answer Set Programming
in a Nutshell
ASP is an approach to declarative problem solving, combining
a rich yet simple modeling language
with high-performance solving capacities
ASP has its roots in
(deductive) databases
logic programming (with negation)
(logic-based) knowledge representation and (nonmonotonic) reasoning
constraint solving (in particular, SATisfiability testing)
ASP allows for solving all search problems in NP (and NP NP )
in a uniform way
ASP is versatile as reflected by the ASP solver clasp, winning
first places at ASP, CASC, MISC, PB, and SAT competitions
ASP embraces many emerging application areas
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 7 / 178
Nutshell
Answer Set Programming
in a Nutshell
ASP is an approach to declarative problem solving, combining
a rich yet simple modeling language
with high-performance solving capacities
ASP has its roots in
(deductive) databases
logic programming (with negation)
(logic-based) knowledge representation and (nonmonotonic) reasoning
constraint solving (in particular, SATisfiability testing)
ASP allows for solving all search problems in NP (and NP NP )
in a uniform way
ASP is versatile as reflected by the ASP solver clasp, winning
first places at ASP, CASC, MISC, PB, and SAT competitions
ASP embraces many emerging application areas
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 7 / 178
Nutshell
Answer Set Programming
in a Nutshell
ASP is an approach to declarative problem solving, combining
a rich yet simple modeling language
with high-performance solving capacities
ASP has its roots in
(deductive) databases
logic programming (with negation)
(logic-based) knowledge representation and (nonmonotonic) reasoning
constraint solving (in particular, SATisfiability testing)
ASP allows for solving all search problems in NP (and NP NP )
in a uniform way
ASP is versatile as reflected by the ASP solver clasp, winning
first places at ASP, CASC, MISC, PB, and SAT competitions
ASP embraces many emerging application areas
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 7 / 178
Nutshell
Answer Set Programming
in a Nutshell
ASP is an approach to declarative problem solving, combining
a rich yet simple modeling language
with high-performance solving capacities
ASP has its roots in
(deductive) databases
logic programming (with negation)
(logic-based) knowledge representation and (nonmonotonic) reasoning
constraint solving (in particular, SATisfiability testing)
ASP allows for solving all search problems in NP (and NP NP )
in a uniform way
ASP is versatile as reflected by the ASP solver clasp, winning
first places at ASP, CASC, MISC, PB, and SAT competitions
ASP embraces many emerging application areas
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 7 / 178
Nutshell
Answer Set Programming
in a Hazelnutshell
ASP is an approach to declarative problem solving, combining
a rich yet simple modeling language
with high-performance solving capacities
tailored to Knowledge Representation and Reasoning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 8 / 178
Nutshell
Answer Set Programming
in a Hazelnutshell
ASP is an approach to declarative problem solving, combining
a rich yet simple modeling language
with high-performance solving capacities
tailored to Knowledge Representation and Reasoning
ASP = DB+LP+KR+SAT
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 8 / 178
Shifting paradigms
Outline
1 Motivation
2 Nutshell
3 Shifting paradigms
4 Rooting ASP
5 ASP solving
6 Using ASP
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 9 / 178
Shifting paradigms
KR’s shift of paradigm
Theorem Proving based approach (eg. Prolog)
1 Provide a representation of the problem
2 A solution is given by a derivation of a query
Model Generation based approach (eg. SATisfiability testing)
1 Provide a representation of the problem
2 A solution is given by a model of the representation
Automated planning, Kautz and Selman (ECAI’92)
Represent planning problems as propositional theories so that
models not proofs describe solutions
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 10 / 178
Shifting paradigms
KR’s shift of paradigm
Theorem Proving based approach (eg. Prolog)
1 Provide a representation of the problem
2 A solution is given by a derivation of a query
Model Generation based approach (eg. SATisfiability testing)
1 Provide a representation of the problem
2 A solution is given by a model of the representation
Automated planning, Kautz and Selman (ECAI’92)
Represent planning problems as propositional theories so that
models not proofs describe solutions
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 10 / 178
Shifting paradigms
KR’s shift of paradigm
Theorem Proving based approach (eg. Prolog)
1 Provide a representation of the problem
2 A solution is given by a derivation of a query
Model Generation based approach (eg. SATisfiability testing)
1 Provide a representation of the problem
2 A solution is given by a model of the representation
Automated planning, Kautz and Selman (ECAI’92)
Represent planning problems as propositional theories so that
models not proofs describe solutions
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 10 / 178
Shifting paradigms
KR’s shift of paradigm
Theorem Proving based approach (eg. Prolog)
1 Provide a representation of the problem
2 A solution is given by a derivation of a query
Model Generation based approach (eg. SATisfiability testing)
1 Provide a representation of the problem
2 A solution is given by a model of the representation
Automated planning, Kautz and Selman (ECAI’92)
Represent planning problems as propositional theories so that
models not proofs describe solutions
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 10 / 178
Shifting paradigms
Model Generation based Problem Solving
Representation Solution
constraint satisfaction problem assignment
propositional horn theories smallest model
propositional theories models
propositional theories minimal models
propositional theories stable models
propositional programs minimal models
propositional programs supported models
propositional programs stable models
first-order theories models
first-order theories minimal models
first-order theories stable models
first-order theories Herbrand models
auto-epistemic theories expansions
default theories extensions
.. ..
. .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 11 / 178
Shifting paradigms
Model Generation based Problem Solving
Representation Solution
constraint satisfaction problem assignment
propositional horn theories smallest model
propositional theories models
propositional theories minimal models
propositional theories stable models
propositional programs minimal models
propositional programs supported models
propositional programs stable models
first-order theories models
first-order theories minimal models
first-order theories stable models
first-order theories Herbrand models
auto-epistemic theories expansions
default theories extensions
.. ..
. .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 11 / 178
Shifting paradigms
Model Generation based Problem Solving
Representation Solution
constraint satisfaction problem assignment
propositional horn theories smallest model
propositional theories models SAT
propositional theories minimal models
propositional theories stable models
propositional programs minimal models
propositional programs supported models
propositional programs stable models
first-order theories models
first-order theories minimal models
first-order theories stable models
first-order theories Herbrand models
auto-epistemic theories expansions
default theories extensions
.. ..
. .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 11 / 178
Shifting paradigms
LP-style playing with blocks
Prolog program
on(a,b).
on(b,c).
above(X,Y) :- on(X,Y).
above(X,Y) :- on(X,Z), above(Z,Y).
Prolog queries
?- above(a,c).
true.
?- above(c,a).
no.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 12 / 178
Shifting paradigms
LP-style playing with blocks
Prolog program
on(a,b).
on(b,c).
above(X,Y) :- on(X,Y).
above(X,Y) :- on(X,Z), above(Z,Y).
Prolog queries
?- above(a,c).
true.
?- above(c,a).
no.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 12 / 178
Shifting paradigms
LP-style playing with blocks
Prolog program
on(a,b).
on(b,c).
above(X,Y) :- on(X,Y).
above(X,Y) :- on(X,Z), above(Z,Y).
Prolog queries
?- above(a,c).
true.
?- above(c,a).
no.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 12 / 178
Shifting paradigms
LP-style playing with blocks
Prolog program
on(a,b).
on(b,c).
above(X,Y) :- on(X,Y).
above(X,Y) :- on(X,Z), above(Z,Y).
Prolog queries (testing entailment)
?- above(a,c).
true.
?- above(c,a).
no.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 12 / 178
Shifting paradigms
LP-style playing with blocks
Shuffled Prolog program
on(a,b).
on(b,c).
above(X,Y) :- above(X,Z), on(Z,Y).
above(X,Y) :- on(X,Y).
Prolog queries
?- above(a,c).
Fatal Error: local stack overflow.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 13 / 178
Shifting paradigms
LP-style playing with blocks
Shuffled Prolog program
on(a,b).
on(b,c).
above(X,Y) :- above(X,Z), on(Z,Y).
above(X,Y) :- on(X,Y).
Prolog queries
?- above(a,c).
Fatal Error: local stack overflow.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 13 / 178
Shifting paradigms
LP-style playing with blocks
Shuffled Prolog program
on(a,b).
on(b,c).
above(X,Y) :- above(X,Z), on(Z,Y).
above(X,Y) :- on(X,Y).
Prolog queries (answered via fixed execution)
?- above(a,c).
Fatal Error: local stack overflow.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 13 / 178
Shifting paradigms
SAT-style playing with blocks
Formula
on(a, b)
∧ on(b, c)
∧ (on(X , Y ) → above(X , Y ))
∧ (on(X , Z ) ∧ above(Z , Y ) → above(X , Y ))
Herbrand model
on(a, b), on(b, c), on(a, c), on(b, b),
above(a, b), above(b, c), above(a, c), above(b, b), above(c, b)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 14 / 178
Shifting paradigms
SAT-style playing with blocks
Formula
on(a, b)
∧ on(b, c)
∧ (on(X , Y ) → above(X , Y ))
∧ (on(X , Z ) ∧ above(Z , Y ) → above(X , Y ))
Herbrand model
on(a, b), on(b, c), on(a, c), on(b, b),
above(a, b), above(b, c), above(a, c), above(b, b), above(c, b)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 14 / 178
Shifting paradigms
SAT-style playing with blocks
Formula
on(a, b)
∧ on(b, c)
∧ (on(X , Y ) → above(X , Y ))
∧ (on(X , Z ) ∧ above(Z , Y ) → above(X , Y ))
Herbrand model (among 426!)
on(a, b), on(b, c), on(a, c), on(b, b),
above(a, b), above(b, c), above(a, c), above(b, b), above(c, b)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 14 / 178
Shifting paradigms
SAT-style playing with blocks
Formula
on(a, b)
∧ on(b, c)
∧ (on(X , Y ) → above(X , Y ))
∧ (on(X , Z ) ∧ above(Z , Y ) → above(X , Y ))
Herbrand model (among 426!)
on(a, b), on(b, c), on(a, c), on(b, b),
above(a, b), above(b, c), above(a, c), above(b, b), above(c, b)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 14 / 178
Shifting paradigms
SAT-style playing with blocks
Formula
on(a, b)
∧ on(b, c)
∧ (on(X , Y ) → above(X , Y ))
∧ (on(X , Z ) ∧ above(Z , Y ) → above(X , Y ))
Herbrand model (among 426!)
on(a, b), on(b, c), on(a, c), on(b, b),
above(a, b), above(b, c), above(a, c), above(b, b), above(c, b)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 14 / 178
Rooting ASP
Outline
1 Motivation
2 Nutshell
3 Shifting paradigms
4 Rooting ASP
5 ASP solving
6 Using ASP
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 15 / 178
Rooting ASP
KR’s shift of paradigm
Theorem Proving based approach (eg. Prolog)
1 Provide a representation of the problem
2 A solution is given by a derivation of a query
Model Generation based approach (eg. SATisfiability testing)
1 Provide a representation of the problem
2 A solution is given by a model of the representation
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 16 / 178
Rooting ASP
KR’s shift of paradigm
Theorem Proving based approach (eg. Prolog)
1 Provide a representation of the problem
2 A solution is given by a derivation of a query
Model Generation based approach (eg. SATisfiability testing)
1 Provide a representation of the problem
2 A solution is given by a model of the representation
å Answer Set Programming (ASP)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 16 / 178
Rooting ASP
Model Generation based Problem Solving
Representation Solution
constraint satisfaction problem assignment
propositional horn theories smallest model
propositional theories models
propositional theories minimal models
propositional theories stable models
propositional programs minimal models
propositional programs supported models
propositional programs stable models
first-order theories models
first-order theories minimal models
first-order theories stable models
first-order theories Herbrand models
auto-epistemic theories expansions
default theories extensions
.. ..
. .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 17 / 178
Rooting ASP
Answer Set Programming at large
Representation Solution
constraint satisfaction problem assignment
propositional horn theories smallest model
propositional theories models
propositional theories minimal models
propositional theories stable models
propositional programs minimal models
propositional programs supported models
propositional programs stable models
first-order theories models
first-order theories minimal models
first-order theories stable models
first-order theories Herbrand models
auto-epistemic theories expansions
default theories extensions
.. ..
. .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 17 / 178
Rooting ASP
Answer Set Programming commonly
Representation Solution
constraint satisfaction problem assignment
propositional horn theories smallest model
propositional theories models
propositional theories minimal models
propositional theories stable models
propositional programs minimal models
propositional programs supported models
propositional programs stable models
first-order theories models
first-order theories minimal models
first-order theories stable models
first-order theories Herbrand models
auto-epistemic theories expansions
default theories extensions
.. ..
. .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 17 / 178
Rooting ASP
Answer Set Programming in practice
Representation Solution
constraint satisfaction problem assignment
propositional horn theories smallest model
propositional theories models
propositional theories minimal models
propositional theories stable models
propositional programs minimal models
propositional programs supported models
propositional programs stable models
first-order theories models
first-order theories minimal models
first-order theories stable models
first-order theories Herbrand models
auto-epistemic theories expansions
default theories extensions
.. ..
. .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 17 / 178
Rooting ASP
Answer Set Programming in practice
Representation Solution
constraint satisfaction problem assignment
propositional horn theories smallest model
propositional theories models
propositional theories minimal models
propositional theories stable models
propositional programs minimal models
propositional programs supported models
propositional programs stable models
first-order theories models
first-order theories minimal models
first-order theories stable models
first-order theories Herbrand models
auto-epistemic theories expansions
default theories extensions
first-order programs stable Herbrand models
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 17 / 178
Rooting ASP
ASP-style playing with blocks
Logic program
on(a,b).
on(b,c).
above(X,Y) :- on(X,Y).
above(X,Y) :- on(X,Z), above(Z,Y).
Stable Herbrand model
{ on(a, b), on(b, c), above(b, c), above(a, b), above(a, c) }
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 18 / 178
Rooting ASP
ASP-style playing with blocks
Logic program
on(a,b).
on(b,c).
above(X,Y) :- on(X,Y).
above(X,Y) :- on(X,Z), above(Z,Y).
Stable Herbrand model
{ on(a, b), on(b, c), above(b, c), above(a, b), above(a, c) }
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 18 / 178
Rooting ASP
ASP-style playing with blocks
Logic program
on(a,b).
on(b,c).
above(X,Y) :- on(X,Y).
above(X,Y) :- on(X,Z), above(Z,Y).
Stable Herbrand model (and no others)
{ on(a, b), on(b, c), above(b, c), above(a, b), above(a, c) }
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 18 / 178
Rooting ASP
ASP-style playing with blocks
Logic program
on(a,b).
on(b,c).
above(X,Y) :- above(Z,Y), on(X,Z).
above(X,Y) :- on(X,Y).
Stable Herbrand model (and no others)
{ on(a, b), on(b, c), above(b, c), above(a, b), above(a, c) }
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 18 / 178
Rooting ASP
ASP-style playing with blocks
Logic program
on(a,b).
on(b,c).
above(X,Y) :- above(Z,Y), on(X,Z).
above(X,Y) :- on(X,Y).
Stable Herbrand model (and no others)
{ on(a, b), on(b, c), above(b, c), above(a, b), above(a, c) }
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 18 / 178
Rooting ASP
ASP versus LP
ASP Prolog
Model generation Query orientation
Bottom-up Top-down
Modeling language Programming language
Rule-based format
Instantiation Unification
Flat terms Nested terms
(Turing +) NP(NP ) Turing
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 19 / 178
Rooting ASP
ASP versus SAT
ASP SAT
Model generation
Bottom-up
Constructive Logic Classical Logic
Closed (and open) Open world reasoning
world reasoning
Modeling language —
Complex reasoning modes Satisfiability testing
Satisfiability Satisfiability
Enumeration/Projection —
Optimization —
Intersection/Union —
(Turing +) NP(NP ) NP
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 20 / 178
ASP solving
Outline
1 Motivation
2 Nutshell
3 Shifting paradigms
4 Rooting ASP
5 ASP solving
6 Using ASP
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 21 / 178
ASP solving
ASP solving
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 22 / 178
ASP solving
SAT solving
Problem Solution
Programming Interpreting
?
Formula - Solver - Classical
(CNF) Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 23 / 178
ASP solving
Rooting ASP solving
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 24 / 178
ASP solving
Rooting ASP solving
Problem Solution
Modeling KR Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
LP DB Solving SAT DB+KR+LP
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 24 / 178
Using ASP
Outline
1 Motivation
2 Nutshell
3 Shifting paradigms
4 Rooting ASP
5 ASP solving
6 Using ASP
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 25 / 178
Using ASP
Two sides of a coin
ASP as High-level Language
Express problem instance(s) as sets of facts
Encode problem (class) as a set of rules
Read off solutions from stable models of facts and rules
ASP as Low-level Language
Compile a problem into a logic program
Solve the original problem by solving its compilation
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 26 / 178
Using ASP
What is ASP good for?
Combinatorial search problems in the realm of P, NP, and NP NP
(some with substantial amount of data), like
Automated Planning
Code Optimization
Composition of Renaissance Music
Database Integration
Decision Support for NASA shuttle controllers
Model Checking
Product Configuration
Robotics
System Biology
System Synthesis
(industrial) Team-building
and many many more
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 27 / 178
Using ASP
What is ASP good for?
Combinatorial search problems in the realm of P, NP, and NP NP
(some with substantial amount of data), like
Automated Planning
Code Optimization
Composition of Renaissance Music
Database Integration
Decision Support for NASA shuttle controllers
Model Checking
Product Configuration
Robotics
System Biology
System Synthesis
(industrial) Team-building
and many many more
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 27 / 178
Using ASP
What does ASP offer?
Integration of DB, KR, and SAT techniques
Succinct, elaboration-tolerant problem representations
Rapid application development tool
Easy handling of dynamic, knowledge intensive applications
including: data, frame axioms, exceptions, defaults, closures, etc
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 28 / 178
Using ASP
What does ASP offer?
Integration of DB, KR, and SAT techniques
Succinct, elaboration-tolerant problem representations
Rapid application development tool
Easy handling of dynamic, knowledge intensive applications
including: data, frame axioms, exceptions, defaults, closures, etc
ASP = DB+LP+KR+SAT
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 28 / 178
Introduction: Overview
7 Syntax
8 Semantics
9 Examples
10 Variables
11 Language constructs
12 Reasoning modes
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 29 / 178
Syntax
Outline
7 Syntax
8 Semantics
9 Examples
10 Variables
11 Language constructs
12 Reasoning modes
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 30 / 178
Syntax
Problem solving in ASP: Syntax
Problem Solution
6
Modeling Interpreting
?
Logic Program - Stable Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 31 / 178
Syntax
Normal logic programs
A (normal) logic program over a set A of atoms is a finite set of rules
A (normal) rule, r , is an ordered pair of the form
a0 ← a1 , . . . , am , ∼ am+1 , . . . , ∼ an
where 0 ≤ m ≤ n and each ai ∈ A is an atom for 0 ≤ i ≤ n
Notation
head(r ) = a0
body (r ) = {a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
body (r )+ = {a1 , . . . , am }
body (r )− = {am+1 , . . . , an }
A program is called positive if body (r )− = ∅ for all its rules
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 32 / 178
Syntax
Normal logic programs
A (normal) logic program over a set A of atoms is a finite set of rules
A (normal) rule, r , is an ordered pair of the form
a0 ← a1 , . . . , am , ∼ am+1 , . . . , ∼ an
where 0 ≤ m ≤ n and each ai ∈ A is an atom for 0 ≤ i ≤ n
Notation
head(r ) = a0
body (r ) = {a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
body (r )+ = {a1 , . . . , am }
body (r )− = {am+1 , . . . , an }
A program is called positive if body (r )− = ∅ for all its rules
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 32 / 178
Syntax
Normal logic programs
A (normal) logic program over a set A of atoms is a finite set of rules
A (normal) rule, r , is an ordered pair of the form
a0 ← a1 , . . . , am , ∼ am+1 , . . . , ∼ an
where 0 ≤ m ≤ n and each ai ∈ A is an atom for 0 ≤ i ≤ n
Notation
head(r ) = a0
body (r ) = {a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
body (r )+ = {a1 , . . . , am }
body (r )− = {am+1 , . . . , an }
A program is called positive if body (r )− = ∅ for all its rules
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 32 / 178
Syntax
Rough notational convention
We sometimes use the following notation interchangeably
in order to stress the respective view:
default classical
true, false if and or iff negation negation
source code :- , | not -
logic program ← , ; ∼ ¬
formula ⊥, > → ∧ ∨ ↔ ∼ ¬
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 33 / 178
Semantics
Outline
7 Syntax
8 Semantics
9 Examples
10 Variables
11 Language constructs
12 Reasoning modes
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 34 / 178
Semantics
Problem solving in ASP: Semantics
Problem Solution
6
Modeling Interpreting
?
Logic Program - Stable Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 35 / 178
Semantics
Formal Definition
Stable models of positive programs
A set of atoms X is closed under a positive program P iff
for any r ∈ P, head(r ) ∈ X whenever body (r )+ ⊆ X
X corresponds to a model of P (seen as a formula)
The smallest set of atoms which is closed under a positive program P
is denoted by Cn(P)
Cn(P) corresponds to the ⊆-smallest model of P (ditto)
The set Cn(P) of atoms is the stable model of a positive program P
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 36 / 178
Semantics
Formal Definition
Stable models of positive programs
A set of atoms X is closed under a positive program P iff
for any r ∈ P, head(r ) ∈ X whenever body (r )+ ⊆ X
X corresponds to a model of P (seen as a formula)
The smallest set of atoms which is closed under a positive program P
is denoted by Cn(P)
Cn(P) corresponds to the ⊆-smallest model of P (ditto)
The set Cn(P) of atoms is the stable model of a positive program P
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 36 / 178
Semantics
Formal Definition
Stable models of positive programs
A set of atoms X is closed under a positive program P iff
for any r ∈ P, head(r ) ∈ X whenever body (r )+ ⊆ X
X corresponds to a model of P (seen as a formula)
The smallest set of atoms which is closed under a positive program P
is denoted by Cn(P)
Cn(P) corresponds to the ⊆-smallest model of P (ditto)
The set Cn(P) of atoms is the stable model of a positive program P
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 36 / 178
Semantics
Formal Definition
Stable models of positive programs
A set of atoms X is closed under a positive program P iff
for any r ∈ P, head(r ) ∈ X whenever body (r )+ ⊆ X
X corresponds to a model of P (seen as a formula)
The smallest set of atoms which is closed under a positive program P
is denoted by Cn(P)
Cn(P) corresponds to the ⊆-smallest model of P (ditto)
The set Cn(P) of atoms is the stable model of a positive program P
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 36 / 178
Semantics
Some “logical” remarks
Positive rules are also referred to as definite clauses
Definite clauses are disjunctions with exactly one positive atom:
a0 ∨ ¬a1 ∨ · · · ∨ ¬am
A set of definite clauses has a (unique) smallest model
Horn clauses are clauses with at most one positive atom
Every definite clause is a Horn clause but not vice versa
Non-definite Horn clauses can be regarded as integrity constraints
A set of Horn clauses has a smallest model or none
This smallest model is the intended semantics of such sets of clauses
Given a positive program P, Cn(P) corresponds to the smallest model
of the set of definite clauses corresponding to P
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 37 / 178
Semantics
Some “logical” remarks
Positive rules are also referred to as definite clauses
Definite clauses are disjunctions with exactly one positive atom:
a0 ∨ ¬a1 ∨ · · · ∨ ¬am
A set of definite clauses has a (unique) smallest model
Horn clauses are clauses with at most one positive atom
Every definite clause is a Horn clause but not vice versa
Non-definite Horn clauses can be regarded as integrity constraints
A set of Horn clauses has a smallest model or none
This smallest model is the intended semantics of such sets of clauses
Given a positive program P, Cn(P) corresponds to the smallest model
of the set of definite clauses corresponding to P
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 37 / 178
Semantics
Some “logical” remarks
Positive rules are also referred to as definite clauses
Definite clauses are disjunctions with exactly one positive atom:
a0 ∨ ¬a1 ∨ · · · ∨ ¬am
A set of definite clauses has a (unique) smallest model
Horn clauses are clauses with at most one positive atom
Every definite clause is a Horn clause but not vice versa
Non-definite Horn clauses can be regarded as integrity constraints
A set of Horn clauses has a smallest model or none
This smallest model is the intended semantics of such sets of clauses
Given a positive program P, Cn(P) corresponds to the smallest model
of the set of definite clauses corresponding to P
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 37 / 178
Semantics
Basic idea
Consider the logical formula Φ and its three
(classical) models: Φ q ∧ (q ∧ ¬r → p)
{p, q}, {q, r }, and {p, q, r }
Formula Φ has one stable model,
often called answer set: PΦ q ←
p ← q, ∼ r
{p, q}
Informally, a set X of atoms is a stable model of a logic program P
if X is a (classical) model of P and
if all atoms in X are justified by some rule in P
(rooted in intuitionistic logics HT (Heyting, 1930) and G3 (Gödel, 1932))
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 38 / 178
Semantics
Basic idea
Consider the logical formula Φ and its three
(classical) models: Φ q ∧ (q ∧ ¬r → p)
{p, q}, {q, r }, and {p, q, r }
Formula Φ has one stable model,
often called answer set: PΦ q ←
p ← q, ∼ r
{p, q}
Informally, a set X of atoms is a stable model of a logic program P
if X is a (classical) model of P and
if all atoms in X are justified by some rule in P
(rooted in intuitionistic logics HT (Heyting, 1930) and G3 (Gödel, 1932))
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 38 / 178
Semantics
Basic idea
Consider the logical formula Φ and its three
(classical) models: Φ q ∧ (q ∧ ¬r → p)
{p, q}, {q, r }, and {p, q, r }
H
H
Formula Φ has HHone stable model,
H
often called answer H
set: PΦ q ←
H 7→ 1
pj p ← q, ∼ r
q 7→ 1
{p, q}
r 7→ 0
Informally, a set X of atoms is a stable model of a logic program P
if X is a (classical) model of P and
if all atoms in X are justified by some rule in P
(rooted in intuitionistic logics HT (Heyting, 1930) and G3 (Gödel, 1932))
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 38 / 178
Semantics
Basic idea
Consider the logical formula Φ and its three
(classical) models: Φ q ∧ (q ∧ ¬r → p)
{p, q}, {q, r }, and {p, q, r }
Formula Φ has one stable model,
often called answer set: PΦ q ←
p ← q, ∼ r
{p, q}
Informally, a set X of atoms is a stable model of a logic program P
if X is a (classical) model of P and
if all atoms in X are justified by some rule in P
(rooted in intuitionistic logics HT (Heyting, 1930) and G3 (Gödel, 1932))
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 38 / 178
Semantics
Basic idea
Consider the logical formula Φ and its three
(classical) models: Φ q ∧ (q ∧ ¬r → p)
{p, q}, {q, r }, and {p, q, r }
Formula Φ has one stable model,
often called answer set: PΦ q ←
p ← q, ∼ r
{p, q}
Informally, a set X of atoms is a stable model of a logic program P
if X is a (classical) model of P and
if all atoms in X are justified by some rule in P
(rooted in intuitionistic logics HT (Heyting, 1930) and G3 (Gödel, 1932))
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 38 / 178
Semantics
Basic idea
Consider the logical formula Φ and its three
(classical) models: Φ q ∧ (q ∧ ¬r → p)
{p, q}, {q, r }, and {p, q, r }
Formula Φ has one stable model,
often called answer set: PΦ q ←
p ← q, ∼ r
{p, q}
Informally, a set X of atoms is a stable model of a logic program P
if X is a (classical) model of P and
if all atoms in X are justified by some rule in P
(rooted in intuitionistic logics HT (Heyting, 1930) and G3 (Gödel, 1932))
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 38 / 178
Semantics
Basic idea
Consider the logical formula Φ and its three
(classical) models: Φ q ∧ (q ∧ ¬r → p)
{p, q}, {q, r }, and {p, q, r }
Formula Φ has one stable model,
often called answer set: PΦ q ←
p ← q, ∼ r
{p, q}
Informally, a set X of atoms is a stable model of a logic program P
if X is a (classical) model of P and
if all atoms in X are justified by some rule in P
(rooted in intuitionistic logics HT (Heyting, 1930) and G3 (Gödel, 1932))
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 38 / 178
Semantics
Basic idea
Consider the logical formula Φ and its three
(classical) models: Φ q ∧ (q ∧ ¬r → p)
{p, q}, {q, r }, and {p, q, r }
Formula Φ has one stable model,
often called answer set: PΦ q ←
p ← q, ∼ r
{p, q}
Informally, a set X of atoms is a stable model of a logic program P
if X is a (classical) model of P and
if all atoms in X are justified by some rule in P
(rooted in intuitionistic logics HT (Heyting, 1930) and G3 (Gödel, 1932))
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 38 / 178
Semantics
Formal Definition
Stable model of normal programs
The reduct, P X , of a program P relative to a set X of atoms is
defined by
P X = {head(r ) ← body (r )+ | r ∈ P and body (r )− ∩ X = ∅}
A set X of atoms is a stable model of a program P, if Cn(P X ) = X
Note: Cn(P X ) is the ⊆–smallest (classical) model of P X
Note: Every atom in X is justified by an “applying rule from P”
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 39 / 178
Semantics
Formal Definition
Stable model of normal programs
The reduct, P X , of a program P relative to a set X of atoms is
defined by
P X = {head(r ) ← body (r )+ | r ∈ P and body (r )− ∩ X = ∅}
A set X of atoms is a stable model of a program P, if Cn(P X ) = X
Note: Cn(P X ) is the ⊆–smallest (classical) model of P X
Note: Every atom in X is justified by an “applying rule from P”
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 39 / 178
Semantics
Formal Definition
Stable model of normal programs
The reduct, P X , of a program P relative to a set X of atoms is
defined by
P X = {head(r ) ← body (r )+ | r ∈ P and body (r )− ∩ X = ∅}
A set X of atoms is a stable model of a program P, if Cn(P X ) = X
Note: Cn(P X ) is the ⊆–smallest (classical) model of P X
Note: Every atom in X is justified by an “applying rule from P”
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 39 / 178
Semantics
A closer look at P X
In other words, given a set X of atoms from P,
P X is obtained from P by deleting
1 each rule having ∼ a in its body with a ∈ X
and then
2 all negative atoms of the form ∼ a
in the bodies of the remaining rules
Note: Only negative body literals are evaluated wrt X
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 40 / 178
Semantics
A closer look at P X
In other words, given a set X of atoms from P,
P X is obtained from P by deleting
1 each rule having ∼ a in its body with a ∈ X
and then
2 all negative atoms of the form ∼ a
in the bodies of the remaining rules
Note: Only negative body literals are evaluated wrt X
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 40 / 178
Examples
Outline
7 Syntax
8 Semantics
9 Examples
10 Variables
11 Language constructs
12 Reasoning modes
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 41 / 178
Examples
A first example
P = {p ← p, q ← ∼ p}
X PX Cn(P X )
∅ p ← p {q} 8
q ←
{p} p ← p ∅ 8
{q} p ← p {q} 4
q ←
{p, q} p ← p ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 42 / 178
Examples
A first example
P = {p ← p, q ← ∼ p}
X PX Cn(P X )
∅ p ← p {q} 8
q ←
{p} p ← p ∅ 8
{q} p ← p {q} 4
q ←
{p, q} p ← p ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 42 / 178
Examples
A first example
P = {p ← p, q ← ∼ p}
X PX Cn(P X )
∅ p ← p {q} 8
q ←
{p} p ← p ∅ 8
{q} p ← p {q} 4
q ←
{p, q} p ← p ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 42 / 178
Examples
A first example
P = {p ← p, q ← ∼ p}
X PX Cn(P X )
∅ p ← p {q} 8
q ←
{p} p ← p ∅ 8
{q} p ← p {q} 4
q ←
{p, q} p ← p ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 42 / 178
Examples
A first example
P = {p ← p, q ← ∼ p}
X PX Cn(P X )
∅ p ← p {q} 8
q ←
{p} p ← p ∅ 8
{q} p ← p {q} 4
q ←
{p, q} p ← p ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 42 / 178
Examples
A first example
P = {p ← p, q ← ∼ p}
X PX Cn(P X )
∅ p ← p {q} 8
q ←
{p} p ← p ∅ 8
{q} p ← p {q} 4
q ←
{p, q} p ← p ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 42 / 178
Examples
A first example
P = {p ← p, q ← ∼ p}
X PX Cn(P X )
∅ p ← p {q} 8
q ←
{p} p ← p ∅ 8
{q} p ← p {q} 4
q ←
{p, q} p ← p ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 42 / 178
Examples
A second example
P = {p ← ∼ q, q ← ∼ p}
X PX Cn(P X )
∅ p ← {p, q} 8
q ←
{p} p ← {p} 4
{q} {q} 4
q ←
{p, q} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 43 / 178
Examples
A second example
P = {p ← ∼ q, q ← ∼ p}
X PX Cn(P X )
∅ p ← {p, q} 8
q ←
{p} p ← {p} 4
{q} {q} 4
q ←
{p, q} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 43 / 178
Examples
A second example
P = {p ← ∼ q, q ← ∼ p}
X PX Cn(P X )
∅ p ← {p, q} 8
q ←
{p} p ← {p} 4
{q} {q} 4
q ←
{p, q} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 43 / 178
Examples
A second example
P = {p ← ∼ q, q ← ∼ p}
X PX Cn(P X )
∅ p ← {p, q} 8
q ←
{p} p ← {p} 4
{q} {q} 4
q ←
{p, q} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 43 / 178
Examples
A second example
P = {p ← ∼ q, q ← ∼ p}
X PX Cn(P X )
∅ p ← {p, q} 8
q ←
{p} p ← {p} 4
{q} {q} 4
q ←
{p, q} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 43 / 178
Examples
A second example
P = {p ← ∼ q, q ← ∼ p}
X PX Cn(P X )
∅ p ← {p, q} 8
q ←
{p} p ← {p} 4
{q} {q} 4
q ←
{p, q} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 43 / 178
Examples
A third example
P = {p ← ∼ p}
X PX Cn(P X )
∅ p ← {p} 8
{p} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 44 / 178
Examples
A third example
P = {p ← ∼ p}
X PX Cn(P X )
∅ p ← {p} 8
{p} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 44 / 178
Examples
A third example
P = {p ← ∼ p}
X PX Cn(P X )
∅ p ← {p} 8
{p} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 44 / 178
Examples
A third example
P = {p ← ∼ p}
X PX Cn(P X )
∅ p ← {p} 8
{p} ∅ 8
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 44 / 178
Examples
Some properties
A logic program may have zero, one, or multiple stable models!
If X is an stable model of a logic program P,
then X is a model of P (seen as a formula)
If X and Y are stable models of a normal program P,
then X 6⊂ Y
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 45 / 178
Examples
Some properties
A logic program may have zero, one, or multiple stable models!
If X is an stable model of a logic program P,
then X is a model of P (seen as a formula)
If X and Y are stable models of a normal program P,
then X 6⊂ Y
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 45 / 178
Variables
Outline
7 Syntax
8 Semantics
9 Examples
10 Variables
11 Language constructs
12 Reasoning modes
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 46 / 178
Variables
Programs with Variables
Let P be a logic program
Let T be a set of (variable-free) terms
Let A be a set of (variable-free) atoms constructable from T
Ground Instances of r ∈ P: Set of variable-free rules obtained by
replacing all variables in r by elements from T :
ground(r ) = {r θ | θ : var (r ) → T , var (r θ) = ∅}
where var (r ) stands for the set of all variables occurring in r ;
θ is a (ground) substitution
S
Ground Instantiation of P: ground(P) = r ∈P ground(r )
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 47 / 178
Variables
Programs with Variables
Let P be a logic program
Let T be a set of variable-free terms (also called Herbrand universe)
Let A be a set of (variable-free) atoms constructable from T
(also called alphabet or Herbrand base)
Ground Instances of r ∈ P: Set of variable-free rules obtained by
replacing all variables in r by elements from T :
ground(r ) = {r θ | θ : var (r ) → T , var (r θ) = ∅}
where var (r ) stands for the set of all variables occurring in r ;
θ is a (ground) substitution
S
Ground Instantiation of P: ground(P) = r ∈P ground(r )
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 47 / 178
Variables
Programs with Variables
Let P be a logic program
Let T be a set of (variable-free) terms
Let A be a set of (variable-free) atoms constructable from T
Ground Instances of r ∈ P: Set of variable-free rules obtained by
replacing all variables in r by elements from T :
ground(r ) = {r θ | θ : var (r ) → T , var (r θ) = ∅}
where var (r ) stands for the set of all variables occurring in r ;
θ is a (ground) substitution
S
Ground Instantiation of P: ground(P) = r ∈P ground(r )
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 47 / 178
Variables
Programs with Variables
Let P be a logic program
Let T be a set of (variable-free) terms
Let A be a set of (variable-free) atoms constructable from T
Ground Instances of r ∈ P: Set of variable-free rules obtained by
replacing all variables in r by elements from T :
ground(r ) = {r θ | θ : var (r ) → T , var (r θ) = ∅}
where var (r ) stands for the set of all variables occurring in r ;
θ is a (ground) substitution
S
Ground Instantiation of P: ground(P) = r ∈P ground(r )
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 47 / 178
Variables
An example
P = { r (a, b) ←, r (b, c) ←, t(X , Y ) ← r (X , Y ) }
T = {a, b, c}
r (a, a), r (a, b), r (a, c), r (b, a), r (b, b), r (b, c), r (c, a), r (c, b), r (c, c),
A=
t(a, a), t(a, b), t(a, c), t(b, a), t(b, b), t(b, c), t(c, a), t(c, b), t(c, c)
r (a, b) ← ,
r (b, c) ← ,
ground(P) = t(a, a) ← r (a, a), t(b, a) ← r (b, a), t(c, a) ← r (c, a),
t(a, b) ← r (a, b), t(b, b) ← r (b, b), t(c, b) ← r (c, b),
t(a, c) ← r (a, c), t(b, c) ← r (b, c), t(c, c) ← r (c, c)
Intelligent Grounding aims at reducing the ground instantiation
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 48 / 178
Variables
An example
P = { r (a, b) ←, r (b, c) ←, t(X , Y ) ← r (X , Y ) }
T = {a, b, c}
r (a, a), r (a, b), r (a, c), r (b, a), r (b, b), r (b, c), r (c, a), r (c, b), r (c, c),
A=
t(a, a), t(a, b), t(a, c), t(b, a), t(b, b), t(b, c), t(c, a), t(c, b), t(c, c)
r (a, b) ← ,
r (b, c) ← ,
ground(P) = t(a, a) ← r (a, a), t(b, a) ← r (b, a), t(c, a) ← r (c, a),
t(a, b) ← r (a, b), t(b, b) ← r (b, b), t(c, b) ← r (c, b),
t(a, c) ← r (a, c), t(b, c) ← r (b, c), t(c, c) ← r (c, c)
Intelligent Grounding aims at reducing the ground instantiation
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 48 / 178
Variables
An example
P = { r (a, b) ←, r (b, c) ←, t(X , Y ) ← r (X , Y ) }
T = {a, b, c}
r (a, a), r (a, b), r (a, c), r (b, a), r (b, b), r (b, c), r (c, a), r (c, b), r (c, c),
A=
t(a, a), t(a, b), t(a, c), t(b, a), t(b, b), t(b, c), t(c, a), t(c, b), t(c, c)
r (a, b) ← ,
r (b, c) ← ,
ground(P) = t(a, a) ← r (a, a), t(b, a) ← r (b, a), t(c, a) ← r (c, a),
t(a, b) ← r (a, b), t(b, b) ← r (b, b), t(c, b) ← r (c, b),
t(a, c) ← r (a, c), t(b, c) ← r (b, c), t(c, c) ← r (c, c)
Intelligent Grounding aims at reducing the ground instantiation
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 48 / 178
Variables
Stable models of programs with Variables
Let P be a normal logic program with variables
A set X of (ground) atoms as a stable model of P,
if Cn(ground(P)X ) = X
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 49 / 178
Variables
Stable models of programs with Variables
Let P be a normal logic program with variables
A set X of (ground) atoms as a stable model of P,
if Cn(ground(P)X ) = X
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 49 / 178
Language constructs
Outline
7 Syntax
8 Semantics
9 Examples
10 Variables
11 Language constructs
12 Reasoning modes
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 50 / 178
Language constructs
Problem solving in ASP: Extended Syntax
Problem Solution
6
Modeling Interpreting
?
Logic Program - Stable Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 51 / 178
Language constructs
Language Constructs
Variables (over the Herbrand Universe)
p(X) :- q(X) over constants {a, b, c} stands for
p(a) :- q(a), p(b) :- q(b), p(c) :- q(c)
Conditional Literals
p :- q(X) : r(X) given r(a), r(b), r(c) stands for
p :- q(a), q(b), q(c)
Disjunction
p(X) | q(X) :- r(X)
Integrity Constraints
:- q(X), p(X)
Choice
2 { p(X,Y) : q(X) } 7 :- r(Y)
Aggregates
s(Y) :- r(Y), 2 #count { p(X,Y) : q(X) } 7
also: #sum, #avg, #min, #max, #even, #odd
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 52 / 178
Language constructs
Language Constructs
Variables (over the Herbrand Universe)
p(X) :- q(X) over constants {a, b, c} stands for
p(a) :- q(a), p(b) :- q(b), p(c) :- q(c)
Conditional Literals
p :- q(X) : r(X) given r(a), r(b), r(c) stands for
p :- q(a), q(b), q(c)
Disjunction
p(X) | q(X) :- r(X)
Integrity Constraints
:- q(X), p(X)
Choice
2 { p(X,Y) : q(X) } 7 :- r(Y)
Aggregates
s(Y) :- r(Y), 2 #count { p(X,Y) : q(X) } 7
also: #sum, #avg, #min, #max, #even, #odd
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 52 / 178
Language constructs
Language Constructs
Variables (over the Herbrand Universe)
p(X) :- q(X) over constants {a, b, c} stands for
p(a) :- q(a), p(b) :- q(b), p(c) :- q(c)
Conditional Literals
p :- q(X) : r(X) given r(a), r(b), r(c) stands for
p :- q(a), q(b), q(c)
Disjunction
p(X) | q(X) :- r(X)
Integrity Constraints
:- q(X), p(X)
Choice
2 { p(X,Y) : q(X) } 7 :- r(Y)
Aggregates
s(Y) :- r(Y), 2 #count { p(X,Y) : q(X) } 7
also: #sum, #avg, #min, #max, #even, #odd
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 52 / 178
Language constructs
Language Constructs
Variables (over the Herbrand Universe)
p(X) :- q(X) over constants {a, b, c} stands for
p(a) :- q(a), p(b) :- q(b), p(c) :- q(c)
Conditional Literals
p :- q(X) : r(X) given r(a), r(b), r(c) stands for
p :- q(a), q(b), q(c)
Disjunction
p(X) | q(X) :- r(X)
Integrity Constraints
:- q(X), p(X)
Choice
2 { p(X,Y) : q(X) } 7 :- r(Y)
Aggregates
s(Y) :- r(Y), 2 #count { p(X,Y) : q(X) } 7
also: #sum, #avg, #min, #max, #even, #odd
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 52 / 178
Language constructs
Language Constructs
Variables (over the Herbrand Universe)
p(X) :- q(X) over constants {a, b, c} stands for
p(a) :- q(a), p(b) :- q(b), p(c) :- q(c)
Conditional Literals
p :- q(X) : r(X) given r(a), r(b), r(c) stands for
p :- q(a), q(b), q(c)
Disjunction
p(X) | q(X) :- r(X)
Integrity Constraints
:- q(X), p(X)
Choice
2 { p(X,Y) : q(X) } 7 :- r(Y)
Aggregates
s(Y) :- r(Y), 2 #count { p(X,Y) : q(X) } 7
also: #sum, #avg, #min, #max, #even, #odd
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 52 / 178
Language constructs
Language Constructs
Variables (over the Herbrand Universe)
p(X) :- q(X) over constants {a, b, c} stands for
p(a) :- q(a), p(b) :- q(b), p(c) :- q(c)
Conditional Literals
p :- q(X) : r(X) given r(a), r(b), r(c) stands for
p :- q(a), q(b), q(c)
Disjunction
p(X) | q(X) :- r(X)
Integrity Constraints
:- q(X), p(X)
Choice
2 { p(X,Y) : q(X) } 7 :- r(Y)
Aggregates
s(Y) :- r(Y), 2 #count { p(X,Y) : q(X) } 7
also: #sum, #avg, #min, #max, #even, #odd
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 52 / 178
Language constructs
Language Constructs
Variables (over the Herbrand Universe)
p(X) :- q(X) over constants {a, b, c} stands for
p(a) :- q(a), p(b) :- q(b), p(c) :- q(c)
Conditional Literals
p :- q(X) : r(X) given r(a), r(b), r(c) stands for
p :- q(a), q(b), q(c)
Disjunction
p(X) | q(X) :- r(X)
Integrity Constraints
:- q(X), p(X)
Choice
2 { p(X,Y) : q(X) } 7 :- r(Y)
Aggregates
s(Y) :- r(Y), 2 #count { p(X,Y) : q(X) } 7
also: #sum, #avg, #min, #max, #even, #odd
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 52 / 178
Language constructs
Language Constructs
Variables (over the Herbrand Universe)
p(X) :- q(X) over constants {a, b, c} stands for
p(a) :- q(a), p(b) :- q(b), p(c) :- q(c)
Conditional Literals
p :- q(X) : r(X) given r(a), r(b), r(c) stands for
p :- q(a), q(b), q(c)
Disjunction
p(X) | q(X) :- r(X)
Integrity Constraints
:- q(X), p(X)
Choice
2 { p(X,Y) : q(X) } 7 :- r(Y)
Aggregates
s(Y) :- r(Y), 2 #count { p(X,Y) : q(X) } 7
also: #sum, #avg, #min, #max, #even, #odd
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 52 / 178
Reasoning modes
Outline
7 Syntax
8 Semantics
9 Examples
10 Variables
11 Language constructs
12 Reasoning modes
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 53 / 178
Reasoning modes
Problem solving in ASP: Reasoning Modes
Problem Solution
6
Modeling Interpreting
?
Logic Program - Stable Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 54 / 178
Reasoning modes
Reasoning Modes
Satisfiability
Enumeration†
Projection†
Intersection‡
Union‡
Optimization
and combinations of them
†
without solution recording
‡
without solution enumeration
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 55 / 178
Basic Modeling: Overview
13 ASP solving process
Graph coloring
14 Methodology
Satisfiability
Queens
Traveling Salesperson
Reviewer Assignment
Planning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 56 / 178
Modeling and Interpreting
Problem Solution
6
Modeling Interpreting
?
Logic Program - Stable Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 57 / 178
Modeling
For solving a problem class C for a problem instance I,
encode
1 the problem instance I as a set PI of facts and
2 the problem class C as a set PC of rules
such that the solutions to C for I can be (polynomially) extracted
from the stable models of PI ∪ PC
PI is (still) called problem instance
PC is often called the problem encoding
An encoding PC is uniform, if it can be used to solve all its
problem instances
That is, PC encodes the solutions to C for any set PI of facts
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 58 / 178
Modeling
For solving a problem class C for a problem instance I,
encode
1 the problem instance I as a set PI of facts and
2 the problem class C as a set PC of rules
such that the solutions to C for I can be (polynomially) extracted
from the stable models of PI ∪ PC
PI is (still) called problem instance
PC is often called the problem encoding
An encoding PC is uniform, if it can be used to solve all its
problem instances
That is, PC encodes the solutions to C for any set PI of facts
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 58 / 178
Modeling
For solving a problem class C for a problem instance I,
encode
1 the problem instance I as a set PI of facts and
2 the problem class C as a set PC of rules
such that the solutions to C for I can be (polynomially) extracted
from the stable models of PI ∪ PC
PI is (still) called problem instance
PC is often called the problem encoding
An encoding PC is uniform, if it can be used to solve all its
problem instances
That is, PC encodes the solutions to C for any set PI of facts
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 58 / 178
ASP solving process
Outline
13 ASP solving process
Graph coloring
14 Methodology
Satisfiability
Queens
Traveling Salesperson
Reviewer Assignment
Planning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 59 / 178
ASP solving process
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 60 / 178
ASP solving process
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 60 / 178
ASP solving process
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 60 / 178
ASP solving process
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 60 / 178
ASP solving process
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 60 / 178
ASP solving process
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 60 / 178
ASP solving process
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
6 Solving
Elaborating
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 60 / 178
ASP solving process Graph coloring
Outline
13 ASP solving process
Graph coloring
14 Methodology
Satisfiability
Queens
Traveling Salesperson
Reviewer Assignment
Planning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 61 / 178
ASP solving process Graph coloring
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 62 / 178
ASP solving process Graph coloring
Graph coloring
Problem instance A graph consisting of nodes and edges
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 63 / 178
ASP solving process Graph coloring
Graph coloring
Problem instance A graph consisting of nodes and edges
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 63 / 178
ASP solving process Graph coloring
Graph coloring
Problem instance A graph consisting of nodes and edges
3 5
1 2
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 63 / 178
ASP solving process Graph coloring
Graph coloring
Problem instance A graph consisting of nodes and edges
facts formed by predicates node/1 and edge/2
3 5
1 2
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 63 / 178
ASP solving process Graph coloring
Graph coloring
Problem instance A graph consisting of nodes and edges
facts formed by predicates node/1 and edge/2
facts formed by predicate color/1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 63 / 178
ASP solving process Graph coloring
Graph coloring
Problem instance A graph consisting of nodes and edges
facts formed by predicates node/1 and edge/2
facts formed by predicate color/1
Problem class Assign each node one color such that no two nodes
connected by an edge have the same color
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 63 / 178
ASP solving process Graph coloring
Graph coloring
Problem instance A graph consisting of nodes and edges
facts formed by predicates node/1 and edge/2
facts formed by predicate color/1
Problem class Assign each node one color such that no two nodes
connected by an edge have the same color
In other words,
1 Each node has a unique color
2 Two connected nodes must not have the same color
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 63 / 178
ASP solving process Graph coloring
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 64 / 178
ASP solving process Graph coloring
Graph coloring
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
Graph coloring
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
Graph coloring
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
Graph coloring
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
Graph coloring
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
Graph coloring
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
Graph coloring
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
Graph coloring
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
Graph coloring
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
color.lp
node(1..6).
edge(1,2). edge(1,3). edge(1,4).
edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5).
Problem
edge(4,1). edge(4,2).
instance
edge(5,3). edge(5,4). edge(5,6).
edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 { color(X,C) : col(C) } 1 :- node(X).
Problem
encoding
:- edge(X,Y), color(X,C), color(Y,C).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 65 / 178
ASP solving process Graph coloring
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 66 / 178
ASP solving process Graph coloring
Graph coloring: Grounding
$ gringo --text color.lp
node(1). node(2). node(3). node(4). node(5). node(6).
edge(1,2). edge(1,3). edge(1,4). edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5). edge(4,1). edge(4,2). edge(5,3).
edge(5,4). edge(5,6). edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 {color(1,r), color(1,b), color(1,g)} 1.
1 {color(2,r), color(2,b), color(2,g)} 1.
1 {color(3,r), color(3,b), color(3,g)} 1.
1 {color(4,r), color(4,b), color(4,g)} 1.
1 {color(5,r), color(5,b), color(5,g)} 1.
1 {color(6,r), color(6,b), color(6,g)} 1.
:- color(1,r), color(2,r). :- color(2,g), color(5,g). ... :- color(6,r), color(2,r).
:- color(1,b), color(2,b). :- color(2,r), color(6,r). :- color(6,b), color(2,b).
:- color(1,g), color(2,g). :- color(2,b), color(6,b). :- color(6,g), color(2,g).
:- color(1,r), color(3,r). :- color(2,g), color(6,g). :- color(6,r), color(3,r).
:- color(1,b), color(3,b). :- color(3,r), color(1,r). :- color(6,b), color(3,b).
:- color(1,g), color(3,g). :- color(3,b), color(1,b). :- color(6,g), color(3,g).
:- color(1,r), color(4,r). :- color(3,g), color(1,g). :- color(6,r), color(5,r).
:- color(1,b), color(4,b). :- color(3,r), color(4,r). :- color(6,b), color(5,b).
:- color(1,g), color(4,g). :- color(3,b), color(4,b). :- color(6,g), color(5,g).
:- color(2,r), color(4,r). :- color(3,g), color(4,g).
:- color(2,b), color(4,b). :- color(3,r), color(5,r).
:- color(2,g), color(4,g). :- color(3,b), color(5,b).
:- color(2,r),
Torsten Schaubcolor(5,r).
(KRR@UP) :- color(3,g), color(5,g).
ASP FMCAD@Cambridge 67 / 178
ASP solving process Graph coloring
Graph coloring: Grounding
$ gringo --text color.lp
node(1). node(2). node(3). node(4). node(5). node(6).
edge(1,2). edge(1,3). edge(1,4). edge(2,4). edge(2,5). edge(2,6).
edge(3,1). edge(3,4). edge(3,5). edge(4,1). edge(4,2). edge(5,3).
edge(5,4). edge(5,6). edge(6,2). edge(6,3). edge(6,5).
col(r). col(b). col(g).
1 {color(1,r), color(1,b), color(1,g)} 1.
1 {color(2,r), color(2,b), color(2,g)} 1.
1 {color(3,r), color(3,b), color(3,g)} 1.
1 {color(4,r), color(4,b), color(4,g)} 1.
1 {color(5,r), color(5,b), color(5,g)} 1.
1 {color(6,r), color(6,b), color(6,g)} 1.
:- color(1,r), color(2,r). :- color(2,g), color(5,g). ... :- color(6,r), color(2,r).
:- color(1,b), color(2,b). :- color(2,r), color(6,r). :- color(6,b), color(2,b).
:- color(1,g), color(2,g). :- color(2,b), color(6,b). :- color(6,g), color(2,g).
:- color(1,r), color(3,r). :- color(2,g), color(6,g). :- color(6,r), color(3,r).
:- color(1,b), color(3,b). :- color(3,r), color(1,r). :- color(6,b), color(3,b).
:- color(1,g), color(3,g). :- color(3,b), color(1,b). :- color(6,g), color(3,g).
:- color(1,r), color(4,r). :- color(3,g), color(1,g). :- color(6,r), color(5,r).
:- color(1,b), color(4,b). :- color(3,r), color(4,r). :- color(6,b), color(5,b).
:- color(1,g), color(4,g). :- color(3,b), color(4,b). :- color(6,g), color(5,g).
:- color(2,r), color(4,r). :- color(3,g), color(4,g).
:- color(2,b), color(4,b). :- color(3,r), color(5,r).
:- color(2,g), color(4,g). :- color(3,b), color(5,b).
:- color(2,r),
Torsten Schaubcolor(5,r).
(KRR@UP) :- color(3,g), color(5,g).
ASP FMCAD@Cambridge 67 / 178
ASP solving process Graph coloring
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 68 / 178
ASP solving process Graph coloring
Graph coloring: Solving
$ gringo color.lp | clasp 0
clasp version 2.1.0
Reading from stdin
Solving...
Answer: 1
edge(1,2) ... col(r) ... node(1) ... color(6,b) color(5,g) color(4,b) color(3,r) color(2,r) color(1,g)
Answer: 2
edge(1,2) ... col(r) ... node(1) ... color(6,r) color(5,g) color(4,r) color(3,b) color(2,b) color(1,g)
Answer: 3
edge(1,2) ... col(r) ... node(1) ... color(6,g) color(5,b) color(4,g) color(3,r) color(2,r) color(1,b)
Answer: 4
edge(1,2) ... col(r) ... node(1) ... color(6,r) color(5,b) color(4,r) color(3,g) color(2,g) color(1,b)
Answer: 5
edge(1,2) ... col(r) ... node(1) ... color(6,g) color(5,r) color(4,g) color(3,b) color(2,b) color(1,r)
Answer: 6
edge(1,2) ... col(r) ... node(1) ... color(6,b) color(5,r) color(4,b) color(3,g) color(2,g) color(1,r)
SATISFIABLE
Models : 6
Time : 0.002s (Solving: 0.00s 1st Model: 0.00s Unsat: 0.00s)
CPU Time : 0.000s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 69 / 178
ASP solving process Graph coloring
Graph coloring: Solving
$ gringo color.lp | clasp 0
clasp version 2.1.0
Reading from stdin
Solving...
Answer: 1
edge(1,2) ... col(r) ... node(1) ... color(6,b) color(5,g) color(4,b) color(3,r) color(2,r) color(1,g)
Answer: 2
edge(1,2) ... col(r) ... node(1) ... color(6,r) color(5,g) color(4,r) color(3,b) color(2,b) color(1,g)
Answer: 3
edge(1,2) ... col(r) ... node(1) ... color(6,g) color(5,b) color(4,g) color(3,r) color(2,r) color(1,b)
Answer: 4
edge(1,2) ... col(r) ... node(1) ... color(6,r) color(5,b) color(4,r) color(3,g) color(2,g) color(1,b)
Answer: 5
edge(1,2) ... col(r) ... node(1) ... color(6,g) color(5,r) color(4,g) color(3,b) color(2,b) color(1,r)
Answer: 6
edge(1,2) ... col(r) ... node(1) ... color(6,b) color(5,r) color(4,b) color(3,g) color(2,g) color(1,r)
SATISFIABLE
Models : 6
Time : 0.002s (Solving: 0.00s 1st Model: 0.00s Unsat: 0.00s)
CPU Time : 0.000s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 69 / 178
ASP solving process Graph coloring
ASP solving process
Problem Solution
Modeling Interpreting
?
Logic - Grounder - Solver - Stable
Program Models
Solving
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 70 / 178
ASP solving process Graph coloring
A coloring
Answer: 6
edge(1,2) ... col(r) ... node(1) ... \
color(6,b) color(5,r) color(4,b) color(3,g) color(2,g) color(1,r)
3 5
1 2
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 71 / 178
ASP solving process Graph coloring
A coloring
Answer: 6
edge(1,2) ... col(r) ... node(1) ... \
color(6,b) color(5,r) color(4,b) color(3,g) color(2,g) color(1,r)
3 5
1 2
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 71 / 178
Methodology
Outline
13 ASP solving process
Graph coloring
14 Methodology
Satisfiability
Queens
Traveling Salesperson
Reviewer Assignment
Planning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 72 / 178
Methodology
Basic methodology
Methodology
Generate and Test (or: Guess and Check)
Generator Generate potential stable model candidates
(typically through non-deterministic constructs)
Tester Eliminate invalid candidates
(typically through integrity constraints)
Nutshell
Logic program = Data + Generator + Tester ( + Optimizer)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 73 / 178
Methodology
Basic methodology
Methodology
Generate and Test (or: Guess and Check)
Generator Generate potential stable model candidates
(typically through non-deterministic constructs)
Tester Eliminate invalid candidates
(typically through integrity constraints)
Nutshell
Logic program = Data + Generator + Tester ( + Optimizer)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 73 / 178
Methodology Satisfiability
Outline
13 ASP solving process
Graph coloring
14 Methodology
Satisfiability
Queens
Traveling Salesperson
Reviewer Assignment
Planning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 74 / 178
Methodology Satisfiability
Satisfiability testing
Problem Instance: A propositional formula φ in CNF
Problem Class: Is there an assignment of propositional variables to
true and false such that a given formula φ is true
Example: Consider formula
(a ∨ ¬b) ∧ (¬a ∨ b)
Logic Program:
Generator Tester Stable models
{ a, b } ← ← ∼ a, b X1 = {a, b}
← a, ∼ b X2 = {}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 75 / 178
Methodology Satisfiability
Satisfiability testing
Problem Instance: A propositional formula φ in CNF
Problem Class: Is there an assignment of propositional variables to
true and false such that a given formula φ is true
Example: Consider formula
(a ∨ ¬b) ∧ (¬a ∨ b)
Logic Program:
Generator Tester Stable models
{ a, b } ← ← ∼ a, b X1 = {a, b}
← a, ∼ b X2 = {}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 75 / 178
Methodology Satisfiability
Satisfiability testing
Problem Instance: A propositional formula φ in CNF
Problem Class: Is there an assignment of propositional variables to
true and false such that a given formula φ is true
Example: Consider formula
(a ∨ ¬b) ∧ (¬a ∨ b)
Logic Program:
Generator Tester Stable models
{ a, b } ← ← ∼ a, b X1 = {a, b}
← a, ∼ b X2 = {}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 75 / 178
Methodology Satisfiability
Satisfiability testing
Problem Instance: A propositional formula φ in CNF
Problem Class: Is there an assignment of propositional variables to
true and false such that a given formula φ is true
Example: Consider formula
(a ∨ ¬b) ∧ (¬a ∨ b)
Logic Program:
Generator Tester Stable models
{ a, b } ← ← ∼ a, b X1 = {a, b}
← a, ∼ b X2 = {}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 75 / 178
Methodology Satisfiability
Satisfiability testing
Problem Instance: A propositional formula φ in CNF
Problem Class: Is there an assignment of propositional variables to
true and false such that a given formula φ is true
Example: Consider formula
(a ∨ ¬b) ∧ (¬a ∨ b)
Logic Program:
Generator Tester Stable models
{ a, b } ← ← ∼ a, b X1 = {a, b}
← a, ∼ b X2 = {}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 75 / 178
Methodology Queens
Outline
13 ASP solving process
Graph coloring
14 Methodology
Satisfiability
Queens
Traveling Salesperson
Reviewer Assignment
Planning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 76 / 178
Methodology Queens
The n-Queens Problem
Place n queens on an n × n
5
Z0Z0Z chess board
4
0Z0Z0 Queens must not attack one
3
Z0Z0Z another
2
0Z0Z0 Q Q Q
1
Z0Z0Z Q Q
1 2 3 4 5
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 77 / 178
Methodology Queens
Defining the Field
queens.lp
row (1.. n ).
col (1.. n ).
Create file queens.lp
Define the field
n rows
n columns
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 78 / 178
Methodology Queens
Defining the Field
Running . . .
$ clingo queens . lp -- const n =5
Answer : 1
row (1) row (2) row (3) row (4) row (5) \
col (1) col (2) col (3) col (4) col (5)
SATISFIABLE
Models : 1
Time : 0.000
Prepare : 0.000
Prepro . : 0.000
Solving : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 79 / 178
Methodology Queens
Placing some Queens
queens.lp
row (1.. n ).
col (1.. n ).
{ queen(I,J) : row(I) : col(J) }.
Guess a solution candidate
by placing some queens on the board
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 80 / 178
Methodology Queens
Placing some Queens
Running . . .
$ clingo queens . lp -- const n =5 3
Answer : 1
row (1) row (2) row (3) row (4) row (5) \
col (1) col (2) col (3) col (4) col (5)
Answer : 2
row (1) row (2) row (3) row (4) row (5) \
col (1) col (2) col (3) col (4) col (5) queen(1,1)
Answer : 3
row (1) row (2) row (3) row (4) row (5) \
col (1) col (2) col (3) col (4) col (5) queen(2,1)
SATISFIABLE
Models : 3+
...
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 81 / 178
Methodology Queens
Placing some Queens: Answer 1
Answer 1
5
Z0Z0Z
4
0Z0Z0
3
Z0Z0Z
2
0Z0Z0
1
Z0Z0Z
1 2 3 4 5
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 82 / 178
Methodology Queens
Placing some Queens: Answer 2
Answer 2
5
Z0Z0Z
4
0Z0Z0
3
Z0Z0Z
2
0Z0Z0
1
L0Z0Z
1 2 3 4 5
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 83 / 178
Methodology Queens
Placing some Queens: Answer 3
Answer 3
5
Z0Z0Z
4
0Z0Z0
3
Z0Z0Z
2
QZ0Z0
1
Z0Z0Z
1 2 3 4 5
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 84 / 178
Methodology Queens
Placing n Queens
queens.lp
row (1.. n ).
col (1.. n ).
{ queen (I , J ) : row ( I ) : col ( J ) }.
:- not n { queen(I,J) } n.
Place exactly n queens on the board
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 85 / 178
Methodology Queens
Placing n Queens
Running . . .
$ clingo queens . lp -- const n =5 2
Answer : 1
row (1) row (2) row (3) row (4) row (5) \
col (1) col (2) col (3) col (4) col (5) \
queen(5,1) queen(4,1) queen(3,1) \
queen(2,1) queen(1,1)
Answer : 2
row (1) row (2) row (3) row (4) row (5) \
col (1) col (2) col (3) col (4) col (5) \
queen(1,2) queen(4,1) queen(3,1) \
queen(2,1) queen(1,1)
...
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 86 / 178
Methodology Queens
Placing n Queens: Answer 1
Answer 1
5
L0Z0Z
4
QZ0Z0
3
L0Z0Z
2
QZ0Z0
1
L0Z0Z
1 2 3 4 5
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 87 / 178
Methodology Queens
Placing n Queens: Answer 2
Answer 2
5
Z0Z0Z
4
QZ0Z0
3
L0Z0Z
2
QZ0Z0
1
LQZ0Z
1 2 3 4 5
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 88 / 178
Methodology Queens
Horizontal and vertical Attack
queens.lp
row (1.. n ).
col (1.. n ).
{ queen (I , J ) : row ( I ) : col ( J ) }.
: - not n { queen (I , J ) } n .
:- queen(I,J), queen(I,JJ), J != JJ.
:- queen(I,J), queen(II,J), I != II.
Forbid horizontal attacks
Forbid vertical attacks
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 89 / 178
Methodology Queens
Horizontal and vertical Attack
queens.lp
row (1.. n ).
col (1.. n ).
{ queen (I , J ) : row ( I ) : col ( J ) }.
: - not n { queen (I , J ) } n .
:- queen(I,J), queen(I,JJ), J != JJ.
:- queen(I,J), queen(II,J), I != II.
Forbid horizontal attacks
Forbid vertical attacks
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 89 / 178
Methodology Queens
Horizontal and vertical Attack
Running . . .
$ clingo queens . lp -- const n =5
Answer : 1
row (1) row (2) row (3) row (4) row (5) \
col (1) col (2) col (3) col (4) col (5) \
queen(5,5) queen(4,4) queen(3,3) \
queen(2,2) queen(1,1)
...
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 90 / 178
Methodology Queens
Horizontal and vertical Attack: Answer 1
Answer 1
5
Z0Z0L
4
0Z0L0
3
Z0L0Z
2
0L0Z0
1
L0Z0Z
1 2 3 4 5
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 91 / 178
Methodology Queens
Diagonal Attack
queens.lp
row (1.. n ).
col (1.. n ).
{ queen (I , J ) : row ( I ) : col ( J ) }.
: - not n { queen (I , J ) } n .
: - queen (I , J ) , queen (I , JJ ) , J != JJ .
: - queen (I , J ) , queen ( II , J ) , I != II .
:- queen(I,J), queen(II,JJ), (I,J) != (II,JJ), I-J == II-JJ.
:- queen(I,J), queen(II,JJ), (I,J) != (II,JJ), I+J == II+JJ.
Forbid diagonal attacks
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 92 / 178
Methodology Queens
Diagonal Attack
Running . . .
$ clingo queens . lp -- const n =5
Answer : 1
row (1) row (2) row (3) row (4) row (5) \
col (1) col (2) col (3) col (4) col (5) \
queen(4,5) queen(1,4) queen(3,3) \
queen(5,2) queen(2,1)
SATISFIABLE
Models : 1+
Time : 0.000
Prepare : 0.000
Prepro . : 0.000
Solving : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 93 / 178
Methodology Queens
Diagonal Attack: Answer 1
Answer 1
5
ZQZ0Z
4
0Z0ZQ
3
Z0L0Z
2
QZ0Z0
1
Z0ZQZ
1 2 3 4 5
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 94 / 178
Methodology Queens
Optimizing
queens-opt.lp
1 { queen (I ,1.. n ) } 1 : - I = 1.. n .
1 { queen (1.. n , J ) } 1 : - J = 1.. n .
: - { queen (D -J , J ) } 2 , D = 2..2* n .
: - { queen ( D +J , J ) } 2 , D = 1 - n .. n -1.
Encoding can be optimized
Much faster to solve
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 95 / 178
Methodology Traveling Salesperson
Outline
13 ASP solving process
Graph coloring
14 Methodology
Satisfiability
Queens
Traveling Salesperson
Reviewer Assignment
Planning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 96 / 178
Methodology Traveling Salesperson
Traveling Salesperson
node(1..6).
edge(1,2;3;4). edge(2,4;5;6). edge(3,1;4;5).
edge(4,1;2). edge(5,3;4;6). edge(6,2;3;5).
cost(1,2,2). cost(1,3,3). cost(1,4,1).
cost(2,4,2). cost(2,5,2). cost(2,6,4).
cost(3,1,3). cost(3,4,2). cost(3,5,2).
cost(4,1,1). cost(4,2,2).
cost(5,3,2). cost(5,4,2). cost(5,6,1).
cost(6,2,4). cost(6,3,3). cost(6,5,1).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 97 / 178
Methodology Traveling Salesperson
Traveling Salesperson
node(1..6).
edge(1,2;3;4). edge(2,4;5;6). edge(3,1;4;5).
edge(4,1;2). edge(5,3;4;6). edge(6,2;3;5).
cost(1,2,2). cost(1,3,3). cost(1,4,1).
cost(2,4,2). cost(2,5,2). cost(2,6,4).
cost(3,1,3). cost(3,4,2). cost(3,5,2).
cost(4,1,1). cost(4,2,2).
cost(5,3,2). cost(5,4,2). cost(5,6,1).
cost(6,2,4). cost(6,3,3). cost(6,5,1).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 97 / 178
Methodology Traveling Salesperson
Traveling Salesperson
node(1..6).
edge(1,2;3;4). edge(2,4;5;6). edge(3,1;4;5).
edge(4,1;2). edge(5,3;4;6). edge(6,2;3;5).
cost(1,2,2). cost(1,3,3). cost(1,4,1).
cost(2,4,2). cost(2,5,2). cost(2,6,4).
cost(3,1,3). cost(3,4,2). cost(3,5,2).
cost(4,1,1). cost(4,2,2).
cost(5,3,2). cost(5,4,2). cost(5,6,1).
cost(6,2,4). cost(6,3,3). cost(6,5,1).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 97 / 178
Methodology Traveling Salesperson
Traveling Salesperson
1 { cycle(X,Y) : edge(X,Y) } 1 :- node(X).
1 { cycle(X,Y) : edge(X,Y) } 1 :- node(Y).
reached(Y) :- cycle(1,Y).
reached(Y) :- cycle(X,Y), reached(X).
:- node(Y), not reached(Y).
#minimize { cycle(X,Y) = C : cost(X,Y,C) }.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 98 / 178
Methodology Traveling Salesperson
Traveling Salesperson
1 { cycle(X,Y) : edge(X,Y) } 1 :- node(X).
1 { cycle(X,Y) : edge(X,Y) } 1 :- node(Y).
reached(Y) :- cycle(1,Y).
reached(Y) :- cycle(X,Y), reached(X).
:- node(Y), not reached(Y).
#minimize { cycle(X,Y) = C : cost(X,Y,C) }.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 98 / 178
Methodology Traveling Salesperson
Traveling Salesperson
1 { cycle(X,Y) : edge(X,Y) } 1 :- node(X).
1 { cycle(X,Y) : edge(X,Y) } 1 :- node(Y).
reached(Y) :- cycle(1,Y).
reached(Y) :- cycle(X,Y), reached(X).
:- node(Y), not reached(Y).
#minimize { cycle(X,Y) = C : cost(X,Y,C) }.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 98 / 178
Methodology Traveling Salesperson
Traveling Salesperson
1 { cycle(X,Y) : edge(X,Y) } 1 :- node(X).
1 { cycle(X,Y) : edge(X,Y) } 1 :- node(Y).
reached(Y) :- cycle(1,Y).
reached(Y) :- cycle(X,Y), reached(X).
:- node(Y), not reached(Y).
#minimize { cycle(X,Y) = C : cost(X,Y,C) }.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 98 / 178
Methodology Reviewer Assignment
Outline
13 ASP solving process
Graph coloring
14 Methodology
Satisfiability
Queens
Traveling Salesperson
Reviewer Assignment
Planning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 99 / 178
Methodology Reviewer Assignment
Reviewer Assignment
by Ilkka Niemelä
reviewer(r1). paper(p1). classA(r1,p1). classB(r1,p2). coi(r1,p3).
reviewer(r2). paper(p2). classA(r1,p3). classB(r1,p4). coi(r1,p6).
...
3 { assigned(P,R) : reviewer(R) } 3 :- paper(P).
:- assigned(P,R), coi(R,P).
:- assigned(P,R), not classA(R,P), not classB(R,P).
:- not 6 { assigned(P,R) : paper(P) } 9, reviewer(R).
assignedB(P,R) :- classB(R,P), assigned(P,R).
:- 3 { assignedB(P,R) : paper(P) }, reviewer(R).
#minimize { assignedB(P,R) : paper(P) : reviewer(R) }.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 100 / 178
Methodology Reviewer Assignment
Reviewer Assignment
by Ilkka Niemelä
reviewer(r1). paper(p1). classA(r1,p1). classB(r1,p2). coi(r1,p3).
reviewer(r2). paper(p2). classA(r1,p3). classB(r1,p4). coi(r1,p6).
...
3 { assigned(P,R) : reviewer(R) } 3 :- paper(P).
:- assigned(P,R), coi(R,P).
:- assigned(P,R), not classA(R,P), not classB(R,P).
:- not 6 { assigned(P,R) : paper(P) } 9, reviewer(R).
assignedB(P,R) :- classB(R,P), assigned(P,R).
:- 3 { assignedB(P,R) : paper(P) }, reviewer(R).
#minimize { assignedB(P,R) : paper(P) : reviewer(R) }.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 100 / 178
Methodology Reviewer Assignment
Reviewer Assignment
by Ilkka Niemelä
reviewer(r1). paper(p1). classA(r1,p1). classB(r1,p2). coi(r1,p3).
reviewer(r2). paper(p2). classA(r1,p3). classB(r1,p4). coi(r1,p6).
...
3 { assigned(P,R) : reviewer(R) } 3 :- paper(P).
:- assigned(P,R), coi(R,P).
:- assigned(P,R), not classA(R,P), not classB(R,P).
:- not 6 { assigned(P,R) : paper(P) } 9, reviewer(R).
assignedB(P,R) :- classB(R,P), assigned(P,R).
:- 3 { assignedB(P,R) : paper(P) }, reviewer(R).
#minimize { assignedB(P,R) : paper(P) : reviewer(R) }.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 100 / 178
Methodology Reviewer Assignment
Reviewer Assignment
by Ilkka Niemelä
reviewer(r1). paper(p1). classA(r1,p1). classB(r1,p2). coi(r1,p3).
reviewer(r2). paper(p2). classA(r1,p3). classB(r1,p4). coi(r1,p6).
...
3 { assigned(P,R) : reviewer(R) } 3 :- paper(P).
:- assigned(P,R), coi(R,P).
:- assigned(P,R), not classA(R,P), not classB(R,P).
:- not 6 { assigned(P,R) : paper(P) } 9, reviewer(R).
assignedB(P,R) :- classB(R,P), assigned(P,R).
:- 3 { assignedB(P,R) : paper(P) }, reviewer(R).
#minimize { assignedB(P,R) : paper(P) : reviewer(R) }.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 100 / 178
Methodology Reviewer Assignment
Reviewer Assignment
by Ilkka Niemelä
reviewer(r1). paper(p1). classA(r1,p1). classB(r1,p2). coi(r1,p3).
reviewer(r2). paper(p2). classA(r1,p3). classB(r1,p4). coi(r1,p6).
...
3 { assigned(P,R) : reviewer(R) } 3 :- paper(P).
:- assigned(P,R), coi(R,P).
:- assigned(P,R), not classA(R,P), not classB(R,P).
:- not 6 { assigned(P,R) : paper(P) } 9, reviewer(R).
assignedB(P,R) :- classB(R,P), assigned(P,R).
:- 3 { assignedB(P,R) : paper(P) }, reviewer(R).
#minimize { assignedB(P,R) : paper(P) : reviewer(R) }.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 100 / 178
Methodology Planning
Outline
13 ASP solving process
Graph coloring
14 Methodology
Satisfiability
Queens
Traveling Salesperson
Reviewer Assignment
Planning
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 101 / 178
Methodology Planning
Simplistic STRIPS Planning
time(1..k). lasttime(T) :- time(T), not time(T+1).
fluent(p). action(a). action(b). init(p).
fluent(q). pre(a,p). pre(b,q).
fluent(r). add(a,q). add(b,r). query(r).
del(a,p). del(b,q).
holds(P,0) :- init(P).
1 { occ(A,T) : action(A) } 1 :- time(T).
:- occ(A,T), pre(A,F), not holds(F,T-1).
ocdel(F,T) :- occ(A,T), del(A,F).
holds(F,T) :- occ(A,T), add(A,F).
holds(F,T) :- holds(F,T-1), not ocdel(F,T), time(T).
:- query(F), not holds(F,T), lasttime(T).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 102 / 178
Methodology Planning
Simplistic STRIPS Planning
time(1..k). lasttime(T) :- time(T), not time(T+1).
fluent(p). action(a). action(b). init(p).
fluent(q). pre(a,p). pre(b,q).
fluent(r). add(a,q). add(b,r). query(r).
del(a,p). del(b,q).
holds(P,0) :- init(P).
1 { occ(A,T) : action(A) } 1 :- time(T).
:- occ(A,T), pre(A,F), not holds(F,T-1).
ocdel(F,T) :- occ(A,T), del(A,F).
holds(F,T) :- occ(A,T), add(A,F).
holds(F,T) :- holds(F,T-1), not ocdel(F,T), time(T).
:- query(F), not holds(F,T), lasttime(T).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 102 / 178
Methodology Planning
Simplistic STRIPS Planning
time(1..k). lasttime(T) :- time(T), not time(T+1).
fluent(p). action(a). action(b). init(p).
fluent(q). pre(a,p). pre(b,q).
fluent(r). add(a,q). add(b,r). query(r).
del(a,p). del(b,q).
holds(P,0) :- init(P).
1 { occ(A,T) : action(A) } 1 :- time(T).
:- occ(A,T), pre(A,F), not holds(F,T-1).
ocdel(F,T) :- occ(A,T), del(A,F).
holds(F,T) :- occ(A,T), add(A,F).
holds(F,T) :- holds(F,T-1), not ocdel(F,T), time(T).
:- query(F), not holds(F,T), lasttime(T).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 102 / 178
Methodology Planning
Simplistic STRIPS Planning
time(1..k). lasttime(T) :- time(T), not time(T+1).
fluent(p). action(a). action(b). init(p).
fluent(q). pre(a,p). pre(b,q).
fluent(r). add(a,q). add(b,r). query(r).
del(a,p). del(b,q).
holds(P,0) :- init(P).
1 { occ(A,T) : action(A) } 1 :- time(T).
:- occ(A,T), pre(A,F), not holds(F,T-1).
ocdel(F,T) :- occ(A,T), del(A,F).
holds(F,T) :- occ(A,T), add(A,F).
holds(F,T) :- holds(F,T-1), not ocdel(F,T), time(T).
:- query(F), not holds(F,T), lasttime(T).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 102 / 178
Language Extensions: Overview
15 Motivation
16 Integrity constraint
17 Choice rule
18 Cardinality rule
19 Weight rule
20 Conditional literal
21 Optimization statement
22 smodels format
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 103 / 178
Motivation
Outline
15 Motivation
16 Integrity constraint
17 Choice rule
18 Cardinality rule
19 Weight rule
20 Conditional literal
21 Optimization statement
22 smodels format
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 104 / 178
Motivation
Language extensions
The expressiveness of a language can be enhanced by introducing
new constructs
To this end, we must address the following issues:
What is the syntax of the new language construct?
What is the semantics of the new language construct?
How to implement the new language construct?
A way of providing semantics is to furnish a translation removing the
new constructs, eg. classical negation
This translation might also be used for implementing the language
extension
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 105 / 178
Motivation
Language extensions
The expressiveness of a language can be enhanced by introducing
new constructs
To this end, we must address the following issues:
What is the syntax of the new language construct?
What is the semantics of the new language construct?
How to implement the new language construct?
A way of providing semantics is to furnish a translation removing the
new constructs, eg. classical negation
This translation might also be used for implementing the language
extension
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 105 / 178
Motivation
Language extensions
The expressiveness of a language can be enhanced by introducing
new constructs
To this end, we must address the following issues:
What is the syntax of the new language construct?
What is the semantics of the new language construct?
How to implement the new language construct?
A way of providing semantics is to furnish a translation removing the
new constructs, eg. classical negation
This translation might also be used for implementing the language
extension
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 105 / 178
Integrity constraint
Outline
15 Motivation
16 Integrity constraint
17 Choice rule
18 Cardinality rule
19 Weight rule
20 Conditional literal
21 Optimization statement
22 smodels format
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 106 / 178
Integrity constraint
Integrity constraint
Idea Eliminate unwanted solution candidates
Syntax An integrity constraint is of the form
← a1 , . . . , am , ∼ am+1 , . . . , ∼ an
where 1 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n
Example :- edge(3,7), color(3,red), color(7,red).
Embedding The above integrity constraint can be turned into the
normal rule
x ← a1 , . . . , am , ∼ am+1 , . . . , ∼ an , ∼ x
where x is a new symbol, that is, x 6∈ A.
Another example P = {a ← not b, b ← not a}
versus P 0 = P ∪ {← a} and P 00 = P ∪ {← not a}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 107 / 178
Integrity constraint
Integrity constraint
Idea Eliminate unwanted solution candidates
Syntax An integrity constraint is of the form
← a1 , . . . , am , ∼ am+1 , . . . , ∼ an
where 1 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n
Example :- edge(3,7), color(3,red), color(7,red).
Embedding The above integrity constraint can be turned into the
normal rule
x ← a1 , . . . , am , ∼ am+1 , . . . , ∼ an , ∼ x
where x is a new symbol, that is, x 6∈ A.
Another example P = {a ← not b, b ← not a}
versus P 0 = P ∪ {← a} and P 00 = P ∪ {← not a}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 107 / 178
Integrity constraint
Integrity constraint
Idea Eliminate unwanted solution candidates
Syntax An integrity constraint is of the form
← a1 , . . . , am , ∼ am+1 , . . . , ∼ an
where 1 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n
Example :- edge(3,7), color(3,red), color(7,red).
Embedding The above integrity constraint can be turned into the
normal rule
x ← a1 , . . . , am , ∼ am+1 , . . . , ∼ an , ∼ x
where x is a new symbol, that is, x 6∈ A.
Another example P = {a ← not b, b ← not a}
versus P 0 = P ∪ {← a} and P 00 = P ∪ {← not a}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 107 / 178
Choice rule
Outline
15 Motivation
16 Integrity constraint
17 Choice rule
18 Cardinality rule
19 Weight rule
20 Conditional literal
21 Optimization statement
22 smodels format
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 108 / 178
Choice rule
Choice rule
Idea Choices over subsets
Syntax A choice rule is of the form
{a1 , . . . , am } ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
where 0 ≤ m ≤ n ≤ o and each ai is an atom for 0 ≤ i ≤ o
Informal meaning If the body is satisfied by the stable model at hand,
then any subset of {a1 , . . . , am } can be included in the stable model
Example { buy(pizza), buy(wine), buy(corn) } :- at(grocery).
Another Example P = { {a} ← b, b ← } has two stable models:
{b} and {a, b}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 109 / 178
Choice rule
Choice rule
Idea Choices over subsets
Syntax A choice rule is of the form
{a1 , . . . , am } ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
where 0 ≤ m ≤ n ≤ o and each ai is an atom for 0 ≤ i ≤ o
Informal meaning If the body is satisfied by the stable model at hand,
then any subset of {a1 , . . . , am } can be included in the stable model
Example { buy(pizza), buy(wine), buy(corn) } :- at(grocery).
Another Example P = { {a} ← b, b ← } has two stable models:
{b} and {a, b}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 109 / 178
Choice rule
Choice rule
Idea Choices over subsets
Syntax A choice rule is of the form
{a1 , . . . , am } ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
where 0 ≤ m ≤ n ≤ o and each ai is an atom for 0 ≤ i ≤ o
Informal meaning If the body is satisfied by the stable model at hand,
then any subset of {a1 , . . . , am } can be included in the stable model
Example { buy(pizza), buy(wine), buy(corn) } :- at(grocery).
Another Example P = { {a} ← b, b ← } has two stable models:
{b} and {a, b}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 109 / 178
Choice rule
Choice rule
Idea Choices over subsets
Syntax A choice rule is of the form
{a1 , . . . , am } ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
where 0 ≤ m ≤ n ≤ o and each ai is an atom for 0 ≤ i ≤ o
Informal meaning If the body is satisfied by the stable model at hand,
then any subset of {a1 , . . . , am } can be included in the stable model
Example { buy(pizza), buy(wine), buy(corn) } :- at(grocery).
Another Example P = { {a} ← b, b ← } has two stable models:
{b} and {a, b}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 109 / 178
Choice rule
Embedding in normal rules
A choice rule of form
{a1 , . . . , am } ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
can be translated into 2m + 1 normal rules
a0 ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
a1 ← a0 , ∼ a1 ... am ← a0 , ∼ am
a1 ← ∼ a1 ... am ← ∼ am
by introducing new atoms a0 , a1 , . . . , am .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 110 / 178
Choice rule
Embedding in normal rules
A choice rule of form
{a1 , . . . , am } ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
can be translated into 2m + 1 normal rules
a0 ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
a1 ← a0 , ∼ a1 ... am ← a0 , ∼ am
a1 ← ∼ a1 ... am ← ∼ am
by introducing new atoms a0 , a1 , . . . , am .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 110 / 178
Choice rule
Embedding in normal rules
A choice rule of form
{a1 , . . . , am } ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
can be translated into 2m + 1 normal rules
a0 ← am+1 , . . . , an , ∼ an+1 , . . . , ∼ ao
a1 ← a0 , ∼ a1 ... am ← a0 , ∼ am
a1 ← ∼ a1 ... am ← ∼ am
by introducing new atoms a0 , a1 , . . . , am .
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 110 / 178
Cardinality rule
Outline
15 Motivation
16 Integrity constraint
17 Choice rule
18 Cardinality rule
19 Weight rule
20 Conditional literal
21 Optimization statement
22 smodels format
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 111 / 178
Cardinality rule
Cardinality rule
Idea Control (lower) cardinality of subsets
Syntax A cardinality rule is the form
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
where 0 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n;
l is a non-negative integer.
Informal meaning The head atom belongs to the stable model,
if at least l elements of the body are included in the stable model
Note l acts as a lower bound on the body
Example pass(c42) :- 2 { pass(a1), pass(a2), pass(a3) }.
Another Example P = { a ← 1{b, c}, b ←} has stable model {a, b}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 112 / 178
Cardinality rule
Cardinality rule
Idea Control (lower) cardinality of subsets
Syntax A cardinality rule is the form
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
where 0 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n;
l is a non-negative integer.
Informal meaning The head atom belongs to the stable model,
if at least l elements of the body are included in the stable model
Note l acts as a lower bound on the body
Example pass(c42) :- 2 { pass(a1), pass(a2), pass(a3) }.
Another Example P = { a ← 1{b, c}, b ←} has stable model {a, b}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 112 / 178
Cardinality rule
Cardinality rule
Idea Control (lower) cardinality of subsets
Syntax A cardinality rule is the form
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
where 0 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n;
l is a non-negative integer.
Informal meaning The head atom belongs to the stable model,
if at least l elements of the body are included in the stable model
Note l acts as a lower bound on the body
Example pass(c42) :- 2 { pass(a1), pass(a2), pass(a3) }.
Another Example P = { a ← 1{b, c}, b ←} has stable model {a, b}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 112 / 178
Cardinality rule
Cardinality rule
Idea Control (lower) cardinality of subsets
Syntax A cardinality rule is the form
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
where 0 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n;
l is a non-negative integer.
Informal meaning The head atom belongs to the stable model,
if at least l elements of the body are included in the stable model
Note l acts as a lower bound on the body
Example pass(c42) :- 2 { pass(a1), pass(a2), pass(a3) }.
Another Example P = { a ← 1{b, c}, b ←} has stable model {a, b}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 112 / 178
Cardinality rule
Embedding in normal rules
Replace each cardinality rule
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
by a0 ← ctr (1, l)
where atom ctr (i, j) represents the fact that at least j of the literals
having an equal or greater index than i, are in a stable model
The definition of ctr /2 is given for 0 ≤ k ≤ l by the rules
ctr (i, k+1) ← ctr (i + 1, k), ai
ctr (i, k) ← ctr (i + 1, k) for 1 ≤ i ≤ m
ctr (j, k+1) ← ctr (j + 1, k), ∼ aj
ctr (j, k) ← ctr (j + 1, k) for m + 1 ≤ j ≤ n
ctr (n + 1, 0) ←
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 113 / 178
Cardinality rule
Embedding in normal rules
Replace each cardinality rule
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
by a0 ← ctr (1, l)
where atom ctr (i, j) represents the fact that at least j of the literals
having an equal or greater index than i, are in a stable model
The definition of ctr /2 is given for 0 ≤ k ≤ l by the rules
ctr (i, k+1) ← ctr (i + 1, k), ai
ctr (i, k) ← ctr (i + 1, k) for 1 ≤ i ≤ m
ctr (j, k+1) ← ctr (j + 1, k), ∼ aj
ctr (j, k) ← ctr (j + 1, k) for m + 1 ≤ j ≤ n
ctr (n + 1, 0) ←
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 113 / 178
Cardinality rule
Embedding in normal rules
Replace each cardinality rule
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
by a0 ← ctr (1, l)
where atom ctr (i, j) represents the fact that at least j of the literals
having an equal or greater index than i, are in a stable model
The definition of ctr /2 is given for 0 ≤ k ≤ l by the rules
ctr (i, k+1) ← ctr (i + 1, k), ai
ctr (i, k) ← ctr (i + 1, k) for 1 ≤ i ≤ m
ctr (j, k+1) ← ctr (j + 1, k), ∼ aj
ctr (j, k) ← ctr (j + 1, k) for m + 1 ≤ j ≤ n
ctr (n + 1, 0) ←
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 113 / 178
Cardinality rule
Embedding in normal rules
Replace each cardinality rule
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
by a0 ← ctr (1, l)
where atom ctr (i, j) represents the fact that at least j of the literals
having an equal or greater index than i, are in a stable model
The definition of ctr /2 is given for 0 ≤ k ≤ l by the rules
ctr (i, k+1) ← ctr (i + 1, k), ai
ctr (i, k) ← ctr (i + 1, k) for 1 ≤ i ≤ m
ctr (j, k+1) ← ctr (j + 1, k), ∼ aj
ctr (j, k) ← ctr (j + 1, k) for m + 1 ≤ j ≤ n
ctr (n + 1, 0) ←
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 113 / 178
Cardinality rule
Embedding in normal rules
Replace each cardinality rule
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
by a0 ← ctr (1, l)
where atom ctr (i, j) represents the fact that at least j of the literals
having an equal or greater index than i, are in a stable model
The definition of ctr /2 is given for 0 ≤ k ≤ l by the rules
ctr (i, k+1) ← ctr (i + 1, k), ai
ctr (i, k) ← ctr (i + 1, k) for 1 ≤ i ≤ m
ctr (j, k+1) ← ctr (j + 1, k), ∼ aj
ctr (j, k) ← ctr (j + 1, k) for m + 1 ≤ j ≤ n
ctr (n + 1, 0) ←
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 113 / 178
Cardinality rule
Embedding in normal rules
Replace each cardinality rule
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
by a0 ← ctr (1, l)
where atom ctr (i, j) represents the fact that at least j of the literals
having an equal or greater index than i, are in a stable model
The definition of ctr /2 is given for 0 ≤ k ≤ l by the rules
ctr (i, k+1) ← ctr (i + 1, k), ai
ctr (i, k) ← ctr (i + 1, k) for 1 ≤ i ≤ m
ctr (j, k+1) ← ctr (j + 1, k), ∼ aj
ctr (j, k) ← ctr (j + 1, k) for m + 1 ≤ j ≤ n
ctr (n + 1, 0) ←
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 113 / 178
Cardinality rule
Embedding in normal rules
Replace each cardinality rule
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
by a0 ← ctr (1, l)
where atom ctr (i, j) represents the fact that at least j of the literals
having an equal or greater index than i, are in a stable model
The definition of ctr /2 is given for 0 ≤ k ≤ l by the rules
ctr (i, k+1) ← ctr (i + 1, k), ai
ctr (i, k) ← ctr (i + 1, k) for 1 ≤ i ≤ m
ctr (j, k+1) ← ctr (j + 1, k), ∼ aj
ctr (j, k) ← ctr (j + 1, k) for m + 1 ≤ j ≤ n
ctr (n + 1, 0) ←
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 113 / 178
Cardinality rule
An example
Program { a ←, c ← 1 {a, b} } has the stable model {a, c}
Translating the cardinality rule yields the rules
a ← c ← ctr (1, 1)
ctr (1, 2) ← ctr (2, 1), a
ctr (1, 1) ← ctr (2, 1)
ctr (2, 2) ← ctr (3, 1), b
ctr (2, 1) ← ctr (3, 1)
ctr (1, 1) ← ctr (2, 0), a
ctr (1, 0) ← ctr (2, 0)
ctr (2, 1) ← ctr (3, 0), b
ctr (2, 0) ← ctr (3, 0)
ctr (3, 0) ←
having stable model {a, ctr (3, 0), ctr (2, 0), ctr (1, 0), ctr (1, 1), c}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 114 / 178
Cardinality rule
An example
Program { a ←, c ← 1 {a, b} } has the stable model {a, c}
Translating the cardinality rule yields the rules
a ← c ← ctr (1, 1)
ctr (1, 2) ← ctr (2, 1), a
ctr (1, 1) ← ctr (2, 1)
ctr (2, 2) ← ctr (3, 1), b
ctr (2, 1) ← ctr (3, 1)
ctr (1, 1) ← ctr (2, 0), a
ctr (1, 0) ← ctr (2, 0)
ctr (2, 1) ← ctr (3, 0), b
ctr (2, 0) ← ctr (3, 0)
ctr (3, 0) ←
having stable model {a, ctr (3, 0), ctr (2, 0), ctr (1, 0), ctr (1, 1), c}
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 114 / 178
Cardinality rule
. . . and vice versa
A normal rule
a0 ← a1 , . . . , am , not am+1 , . . . , not an ,
can be represented by the cardinality rule
a0 ← n {a1 , . . . , am , not am+1 , . . . , not an }
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 115 / 178
Cardinality rule
Cardinality rules with upper bounds
A rule of the form
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an } u
where 0 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n;
l and u are non-negative integers
stands for
a0 ← b, ∼ c
b ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
c ← u+1 { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
where b and c are new symbols
The single constraint in the body of the above cardinality rule is
referred to as a cardinality constraint
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 116 / 178
Cardinality rule
Cardinality rules with upper bounds
A rule of the form
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an } u
where 0 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n;
l and u are non-negative integers
stands for
a0 ← b, ∼ c
b ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
c ← u+1 { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
where b and c are new symbols
The single constraint in the body of the above cardinality rule is
referred to as a cardinality constraint
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 116 / 178
Cardinality rule
Cardinality rules with upper bounds
A rule of the form
a0 ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an } u
where 0 ≤ m ≤ n and each ai is an atom for 0 ≤ i ≤ n;
l and u are non-negative integers
stands for
a0 ← b, ∼ c
b ← l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
c ← u+1 { a1 , . . . , am , ∼ am+1 , . . . , ∼ an }
where b and c are new symbols
The single constraint in the body of the above cardinality rule is
referred to as a cardinality constraint
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 116 / 178
Cardinality rule
Cardinality constraints
Syntax A cardinality constraint is of the form
l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an } u
where 1 ≤ m ≤ n and each ai is an atom for 1 ≤ i ≤ n;
l and u are non-negative integers
Informal meaning A cardinality constraint is satisfied by a stable
model X , if the number of its contained literals satisfied by X is
between l and u (inclusive)
In other words, if
l ≤ | ({a1 , . . . , am } ∩ X ) ∪ ({am+1 , . . . , an } \ X ) | ≤ u
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 117 / 178
Cardinality rule
Cardinality constraints
Syntax A cardinality constraint is of the form
l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an } u
where 1 ≤ m ≤ n and each ai is an atom for 1 ≤ i ≤ n;
l and u are non-negative integers
Informal meaning A cardinality constraint is satisfied by a stable
model X , if the number of its contained literals satisfied by X is
between l and u (inclusive)
In other words, if
l ≤ | ({a1 , . . . , am } ∩ X ) ∪ ({am+1 , . . . , an } \ X ) | ≤ u
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 117 / 178
Cardinality rule
Cardinality constraints
Syntax A cardinality constraint is of the form
l { a1 , . . . , am , ∼ am+1 , . . . , ∼ an } u
where 1 ≤ m ≤ n and each ai is an atom for 1 ≤ i ≤ n;
l and u are non-negative integers
Informal meaning A cardinality constraint is satisfied by a stable
model X , if the number of its contained literals satisfied by X is
between l and u (inclusive)
In other words, if
l ≤ | ({a1 , . . . , am } ∩ X ) ∪ ({am+1 , . . . , an } \ X ) | ≤ u
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 117 / 178
Cardinality rule
Cardinality constraints as heads
A rule of the form
l {a1 , . . . , am , ∼ am+1 , . . . , ∼ an } u ← an+1 , . . . , ao , ∼ ao+1 , . . . , ∼ ap
where 0 ≤ m ≤ n ≤ o ≤ p and each ai is an atom for 0 ≤ i ≤ p;
l and u are non-negative integers
stands for
b ← an+1 , . . . , ao , ∼ ao+1 , . . . , ∼ ap
{a1 , . . . , am } ← b
c ← l {a1 , . . . , am , , ∼ am+1 , . . . , ∼ an } u
← b, ∼ c
where b and c are new symbols
Example 1 { color(v42,red),color(v42,green),color(v42,blue) } 1.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 118 / 178
Cardinality rule
Cardinality constraints as heads
A rule of the form
l {a1 , . . . , am , ∼ am+1 , . . . , ∼ an } u ← an+1 , . . . , ao , ∼ ao+1 , . . . , ∼ ap
where 0 ≤ m ≤ n ≤ o ≤ p and each ai is an atom for 0 ≤ i ≤ p;
l and u are non-negative integers
stands for
b ← an+1 , . . . , ao , ∼ ao+1 , . . . , ∼ ap
{a1 , . . . , am } ← b
c ← l {a1 , . . . , am , , ∼ am+1 , . . . , ∼ an } u
← b, ∼ c
where b and c are new symbols
Example 1 { color(v42,red),color(v42,green),color(v42,blue) } 1.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 118 / 178
Cardinality rule
Cardinality constraints as heads
A rule of the form
l {a1 , . . . , am , ∼ am+1 , . . . , ∼ an } u ← an+1 , . . . , ao , ∼ ao+1 , . . . , ∼ ap
where 0 ≤ m ≤ n ≤ o ≤ p and each ai is an atom for 0 ≤ i ≤ p;
l and u are non-negative integers
stands for
b ← an+1 , . . . , ao , ∼ ao+1 , . . . , ∼ ap
{a1 , . . . , am } ← b
c ← l {a1 , . . . , am , , ∼ am+1 , . . . , ∼ an } u
← b, ∼ c
where b and c are new symbols
Example 1 { color(v42,red),color(v42,green),color(v42,blue) } 1.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 118 / 178
Cardinality rule
Full-fledged cardinality rules
A rule of the form
l0 S0 u0 ← l1 S1 u1 , . . . , ln Sn un
where for 1 ≤ i ≤ n each li Si ui
stands for 0 ≤ i ≤ n
a ← b1 , . . . , bn , ∼ c1 , . . . , ∼ cn
S0 + ← a
← a, ∼ b0 bi ← li Si
← a, c0 ci ← ui +1 Si
where a, bi , ci are new symbols
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 119 / 178
Cardinality rule
Full-fledged cardinality rules
A rule of the form
l0 S0 u0 ← l1 S1 u1 , . . . , ln Sn un
where for 1 ≤ i ≤ n each li Si ui
stands for 0 ≤ i ≤ n
a ← b1 , . . . , bn , ∼ c1 , . . . , ∼ cn
S0 + ← a
← a, ∼ b0 bi ← li Si
← a, c0 ci ← ui +1 Si
where a, bi , ci are new symbols
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 119 / 178
Cardinality rule
Full-fledged cardinality rules
A rule of the form
l0 S0 u0 ← l1 S1 u1 , . . . , ln Sn un
where for 1 ≤ i ≤ n each li Si ui
stands for 0 ≤ i ≤ n
a ← b1 , . . . , bn , ∼ c1 , . . . , ∼ cn
S0 + ← a
← a, ∼ b0 bi ← li Si
← a, c0 ci ← ui +1 Si
where a, bi , ci are new symbols
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 119 / 178
Cardinality rule
Full-fledged cardinality rules
A rule of the form
l0 S0 u0 ← l1 S1 u1 , . . . , ln Sn un
where for 1 ≤ i ≤ n each li Si ui
stands for 0 ≤ i ≤ n
a ← b1 , . . . , bn , ∼ c1 , . . . , ∼ cn
S0 + ← a
← a, ∼ b0 bi ← li Si
← a, c0 ci ← ui +1 Si
where a, bi , ci are new symbols
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 119 / 178
Cardinality rule
Full-fledged cardinality rules
A rule of the form
l0 S0 u0 ← l1 S1 u1 , . . . , ln Sn un
where for 1 ≤ i ≤ n each li Si ui
stands for 0 ≤ i ≤ n
a ← b1 , . . . , bn , ∼ c1 , . . . , ∼ cn
S0 + ← a
← a, ∼ b0 bi ← li Si
← a, c0 ci ← ui +1 Si
where a, bi , ci are new symbols
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 119 / 178
Cardinality rule
Full-fledged cardinality rules
A rule of the form
l0 S0 u0 ← l1 S1 u1 , . . . , ln Sn un
where for 1 ≤ i ≤ n each li Si ui
stands for 0 ≤ i ≤ n
a ← b1 , . . . , bn , ∼ c1 , . . . , ∼ cn
S0 + ← a
← a, ∼ b0 bi ← li Si
← a, c0 ci ← ui +1 Si
where a, bi , ci are new symbols
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 119 / 178
Weight rule
Outline
15 Motivation
16 Integrity constraint
17 Choice rule
18 Cardinality rule
19 Weight rule
20 Conditional literal
21 Optimization statement
22 smodels format
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 120 / 178
Weight rule
Weight rule
Syntax A weight rule is the form
a0 ← l { a1 = w1 , . . . , am = wm , ∼ am+1 = wm+1 , . . . , ∼ an = wn }
where 0 ≤ m ≤ n and each ai is an atom;
l and wi are integers for 0 ≤ i ≤ n
A weighted literal, `i = wi , associates each literal `i with a weight wi
Note A cardinality rule is a weight rule where wi = 1 for 0 ≤ i ≤ n
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 121 / 178
Weight rule
Weight rule
Syntax A weight rule is the form
a0 ← l { a1 = w1 , . . . , am = wm , ∼ am+1 = wm+1 , . . . , ∼ an = wn }
where 0 ≤ m ≤ n and each ai is an atom;
l and wi are integers for 0 ≤ i ≤ n
A weighted literal, `i = wi , associates each literal `i with a weight wi
Note A cardinality rule is a weight rule where wi = 1 for 0 ≤ i ≤ n
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 121 / 178
Weight rule
Weight constraints
Syntax A weight constraint is of the form
l { a1 = w1 , . . . , am = wm , ∼ am+1 = wm+1 , . . . , ∼ an = wn } u
where 1 ≤ m ≤ n and each ai is an atom;
l, u and wi are integers for 0 ≤ i ≤ n
Meaning A weight constraint is satisfied by a stable model X , if
P P
l≤ 1≤i≤m,ai ∈X wi + m<i≤n,ai 6∈X wi ≤u
Note (Cardinality and) weight constraints amount to constraints on
(count and) sum aggregate functions
Example 10 {course(db)=6,course(ai)=6,course(project)=8,course(xml)=3} 20
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 122 / 178
Weight rule
Weight constraints
Syntax A weight constraint is of the form
l { a1 = w1 , . . . , am = wm , ∼ am+1 = wm+1 , . . . , ∼ an = wn } u
where 1 ≤ m ≤ n and each ai is an atom;
l, u and wi are integers for 0 ≤ i ≤ n
Meaning A weight constraint is satisfied by a stable model X , if
P P
l≤ 1≤i≤m,ai ∈X wi + m<i≤n,ai 6∈X wi ≤u
Note (Cardinality and) weight constraints amount to constraints on
(count and) sum aggregate functions
Example 10 {course(db)=6,course(ai)=6,course(project)=8,course(xml)=3} 20
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 122 / 178
Weight rule
Weight constraints
Syntax A weight constraint is of the form
l { a1 = w1 , . . . , am = wm , ∼ am+1 = wm+1 , . . . , ∼ an = wn } u
where 1 ≤ m ≤ n and each ai is an atom;
l, u and wi are integers for 0 ≤ i ≤ n
Meaning A weight constraint is satisfied by a stable model X , if
P P
l≤ 1≤i≤m,ai ∈X wi + m<i≤n,ai 6∈X wi ≤u
Note (Cardinality and) weight constraints amount to constraints on
(count and) sum aggregate functions
Example 10 {course(db)=6,course(ai)=6,course(project)=8,course(xml)=3} 20
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 122 / 178
Weight rule
Weight constraints
Syntax A weight constraint is of the form
l { a1 = w1 , . . . , am = wm , ∼ am+1 = wm+1 , . . . , ∼ an = wn } u
where 1 ≤ m ≤ n and each ai is an atom;
l, u and wi are integers for 0 ≤ i ≤ n
Meaning A weight constraint is satisfied by a stable model X , if
P P
l≤ 1≤i≤m,ai ∈X wi + m<i≤n,ai 6∈X wi ≤u
Note (Cardinality and) weight constraints amount to constraints on
(count and) sum aggregate functions
Example 10 {course(db)=6,course(ai)=6,course(project)=8,course(xml)=3} 20
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 122 / 178
Conditional literal
Outline
15 Motivation
16 Integrity constraint
17 Choice rule
18 Cardinality rule
19 Weight rule
20 Conditional literal
21 Optimization statement
22 smodels format
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 123 / 178
Conditional literal
Conditional literals
Syntax A conditional literal is of the form
` : `1 : · · · : `n
where ` and `i are literals for 0 ≤ i ≤ n
Informal meaning A conditional literal can be regarded as the list of
elements in the set {` | `1 , . . . , `n }
Note The expansion of conditional literals is context dependent
Example Given ‘ p(1). p(2). p(3). q(2).’
r(X):p(X):not q(X) :- r(X):p(X):not q(X), 1 {r(X):p(X):not q(X)}.
is instantiated to
r(1); r(3) :- r(1), r(3), 1 {r(1), r(3)}.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 124 / 178
Conditional literal
Conditional literals
Syntax A conditional literal is of the form
` : `1 : · · · : `n
where ` and `i are literals for 0 ≤ i ≤ n
Informal meaning A conditional literal can be regarded as the list of
elements in the set {` | `1 , . . . , `n }
Note The expansion of conditional literals is context dependent
Example Given ‘ p(1). p(2). p(3). q(2).’
r(X):p(X):not q(X) :- r(X):p(X):not q(X), 1 {r(X):p(X):not q(X)}.
is instantiated to
r(1); r(3) :- r(1), r(3), 1 {r(1), r(3)}.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 124 / 178
Conditional literal
Conditional literals
Syntax A conditional literal is of the form
` : `1 : · · · : `n
where ` and `i are literals for 0 ≤ i ≤ n
Informal meaning A conditional literal can be regarded as the list of
elements in the set {` | `1 , . . . , `n }
Note The expansion of conditional literals is context dependent
Example Given ‘ p(1). p(2). p(3). q(2).’
r(X):p(X):not q(X) :- r(X):p(X):not q(X), 1 {r(X):p(X):not q(X)}.
is instantiated to
r(1); r(3) :- r(1), r(3), 1 {r(1), r(3)}.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 124 / 178
Conditional literal
Conditional literals
Syntax A conditional literal is of the form
` : `1 : · · · : `n
where ` and `i are literals for 0 ≤ i ≤ n
Informal meaning A conditional literal can be regarded as the list of
elements in the set {` | `1 , . . . , `n }
Note The expansion of conditional literals is context dependent
Example Given ‘ p(1). p(2). p(3). q(2).’
r(X):p(X):not q(X) :- r(X):p(X):not q(X), 1 {r(X):p(X):not q(X)}.
is instantiated to
r(1); r(3) :- r(1), r(3), 1 {r(1), r(3)}.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 124 / 178
Conditional literal
Conditional literals
Syntax A conditional literal is of the form
` : `1 : · · · : `n
where ` and `i are literals for 0 ≤ i ≤ n
Informal meaning A conditional literal can be regarded as the list of
elements in the set {` | `1 , . . . , `n }
Note The expansion of conditional literals is context dependent
Example Given ‘ p(1). p(2). p(3). q(2).’
r(X):p(X):not q(X) :- r(X):p(X):not q(X), 1 {r(X):p(X):not q(X)}.
is instantiated to
r(1); r(3) :- r(1), r(3), 1 {r(1), r(3)}.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 124 / 178
Conditional literal
Conditional literals
Syntax A conditional literal is of the form
` : `1 : · · · : `n
where ` and `i are literals for 0 ≤ i ≤ n
Informal meaning A conditional literal can be regarded as the list of
elements in the set {` | `1 , . . . , `n }
Note The expansion of conditional literals is context dependent
Example Given ‘ p(1). p(2). p(3). q(2).’
r(X):p(X):not q(X) :- r(X):p(X):not q(X), 1 {r(X):p(X):not q(X)}.
is instantiated to
r(1); r(3) :- r(1), r(3), 1 {r(1), r(3)}.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 124 / 178
Conditional literal
Conditional literals
Syntax A conditional literal is of the form
` : `1 : · · · : `n
where ` and `i are literals for 0 ≤ i ≤ n
Informal meaning A conditional literal can be regarded as the list of
elements in the set {` | `1 , . . . , `n }
Note The expansion of conditional literals is context dependent
Example Given ‘ p(1). p(2). p(3). q(2).’
r(X):p(X):not q(X) :- r(X):p(X):not q(X), 1 {r(X):p(X):not q(X)}.
is instantiated to
r(1); r(3) :- r(1), r(3), 1 {r(1), r(3)}.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 124 / 178
Optimization statement
Outline
15 Motivation
16 Integrity constraint
17 Choice rule
18 Cardinality rule
19 Weight rule
20 Conditional literal
21 Optimization statement
22 smodels format
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 125 / 178
Optimization statement
Optimization statement
Idea Express cost functions subject to minimization and/or
maximization
Syntax A minimize statement is of the form
minimize{ `1 = w1 @p1 , . . . , `n = wn @pn }.
where each `i is a literal; and wi and pi are integers for 1 ≤ i ≤ n
Priority levels, pi , allow for representing lexicographically ordered
minimization objectives
Meaning A minimize statement is a directive that instructs the ASP
solver to compute optimal stable models by minimizing a weighted
sum of elements
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 126 / 178
Optimization statement
Optimization statement
Idea Express cost functions subject to minimization and/or
maximization
Syntax A minimize statement is of the form
minimize{ `1 = w1 @p1 , . . . , `n = wn @pn }.
where each `i is a literal; and wi and pi are integers for 1 ≤ i ≤ n
Priority levels, pi , allow for representing lexicographically ordered
minimization objectives
Meaning A minimize statement is a directive that instructs the ASP
solver to compute optimal stable models by minimizing a weighted
sum of elements
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 126 / 178
Optimization statement
Optimization statement
Idea Express cost functions subject to minimization and/or
maximization
Syntax A minimize statement is of the form
minimize{ `1 = w1 @p1 , . . . , `n = wn @pn }.
where each `i is a literal; and wi and pi are integers for 1 ≤ i ≤ n
Priority levels, pi , allow for representing lexicographically ordered
minimization objectives
Meaning A minimize statement is a directive that instructs the ASP
solver to compute optimal stable models by minimizing a weighted
sum of elements
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 126 / 178
Optimization statement
Optimization statement
A maximize statement of the form
maximize{ `1 = w1 @p1 , . . . , `n = wn @pn }
stands for minimize{ `1 = −w1 @p1 , . . . , `n = −wn @pn }
Example When configuring a computer, we may want to maximize
hard disk capacity, while minimizing price
#maximize[ hd(1)=250@1, hd(2)=500@1, hd(3)=750@1, hd(4)=1000@1 ].
#minimize[ hd(1)=30@2, hd(2)=40@2, hd(3)=60@2, hd(4)=80@2 ].
The priority levels indicate that (minimizing) price is more important
than (maximizing) capacity
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 127 / 178
Optimization statement
Optimization statement
A maximize statement of the form
maximize{ `1 = w1 @p1 , . . . , `n = wn @pn }
stands for minimize{ `1 = −w1 @p1 , . . . , `n = −wn @pn }
Example When configuring a computer, we may want to maximize
hard disk capacity, while minimizing price
#maximize[ hd(1)=250@1, hd(2)=500@1, hd(3)=750@1, hd(4)=1000@1 ].
#minimize[ hd(1)=30@2, hd(2)=40@2, hd(3)=60@2, hd(4)=80@2 ].
The priority levels indicate that (minimizing) price is more important
than (maximizing) capacity
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 127 / 178
smodels format
Outline
15 Motivation
16 Integrity constraint
17 Choice rule
18 Cardinality rule
19 Weight rule
20 Conditional literal
21 Optimization statement
22 smodels format
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 128 / 178
smodels format
smodels format
Logic programs in smodels format consist of
normal rules
choice rules
cardinality rules
weight rules
optimization statements
Such a format is obtained by grounders lparse and gringo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 129 / 178
Systems: Overview
23 Potassco
24 gringo
25 clasp
26 Siblings
claspfolio
clingcon
iclingo
oclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 130 / 178
Potassco
Outline
23 Potassco
24 gringo
25 clasp
26 Siblings
claspfolio
clingcon
iclingo
oclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 131 / 178
Potassco
http://potassco.sourceforge.net
Potassco, the Potsdam Answer Set Solving Collection,
bundles tools for ASP developed at the University of Potsdam,
for instance:
Grounder: gringo, lingo, pyngo
Solver: clasp, {a,h,pb,un}clasp, claspD, claspfolio, claspar, aspeed
Grounder+Solver: Clingo, iClingo, oClingo, Clingcon
Further Tools: asp{un}cud, coala, fimo, metasp, plasp, etc
Benchmark repository: http://asparagus.cs.uni-potsdam.de
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 132 / 178
Potassco
http://potassco.sourceforge.net
Potassco, the Potsdam Answer Set Solving Collection,
bundles tools for ASP developed at the University of Potsdam,
for instance:
Grounder: gringo, lingo, pyngo
Solver: clasp, {a,h,pb,un}clasp, claspD, claspfolio, claspar, aspeed
Grounder+Solver: Clingo, iClingo, oClingo, Clingcon
Further Tools: asp{un}cud, coala, fimo, metasp, plasp, etc
Benchmark repository: http://asparagus.cs.uni-potsdam.de
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 132 / 178
Potassco
http://potassco.sourceforge.net
Potassco, the Potsdam Answer Set Solving Collection,
bundles tools for ASP developed at the University of Potsdam,
for instance:
Grounder: gringo, lingo, pyngo
Solver: clasp, {a,h,pb,un}clasp, claspD, claspfolio, claspar, aspeed
Grounder+Solver: Clingo, iClingo, oClingo, Clingcon
Further Tools: asp{un}cud, coala, fimo, metasp, plasp, etc
Benchmark repository: http://asparagus.cs.uni-potsdam.de
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 132 / 178
gringo
Outline
23 Potassco
24 gringo
25 clasp
26 Siblings
claspfolio
clingcon
iclingo
oclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 133 / 178
gringo
gringo
Accepts safe programs with aggregates
Tolerates unrestricted use of function symbols
(as long as it yields a finite ground instantiation :)
Expressive power of a Turing machine
Basic architecture of gringo:
Parser Preprocessor Grounder Output
--lparse
--ground --text
--reify
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 134 / 178
gringo
An example
d(a)
d(c)
d(d)
p(a, b)
p(b, c)
p(c, d)
p(X , Z ) ← p(X , Y ), p(Y , Z )
q(a)
q(b)
q(X ) ← ∼ r (X ), d(X )
r (X ) ← ∼ q(X ), d(X )
s(X ) ← ∼ r (X ), p(X , Y ), q(Y )
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 135 / 178
gringo
An example
Safe ?
d(a)
d(c)
d(d)
p(a, b)
p(b, c)
p(c, d)
p(X , Z ) ← p(X , Y ), p(Y , Z )
q(a)
q(b)
q(X ) ← ∼ r (X ), d(X )
r (X ) ← ∼ q(X ), d(X )
s(X ) ← ∼ r (X ), p(X , Y ), q(Y )
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 135 / 178
gringo
An example
Safe ?
d(a) 4
d(c) 4
d(d) 4
p(a, b) 4
p(b, c) 4
p(c, d) 4
p(X , Z ) ← p(X , Y ), p(Y , Z )
q(a) 4
q(b) 4
q(X ) ← ∼ r (X ), d(X )
r (X ) ← ∼ q(X ), d(X )
s(X ) ← ∼ r (X ), p(X , Y ), q(Y )
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 135 / 178
gringo
An example
Safe ?
d(a) 4
d(c) 4
d(d) 4
p(a, b) 4
p(b, c) 4
p(c, d) 4
p(X , Z ) ← p(X , Y ), p(Y , Z )
q(a) 4
q(b) 4
q(X ) ← ∼ r (X ), d(X )
r (X ) ← ∼ q(X ), d(X )
s(X ) ← ∼ r (X ), p(X , Y ), q(Y )
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 135 / 178
gringo
An example
Safe ?
d(a) 4
d(c) 4
d(d) 4
p(a, b) 4
p(b, c) 4
p(c, d) 4
p(X , Z ) ← p(X , Y ), p(Y , Z ) 4
q(a) 4
q(b) 4
q(X ) ← ∼ r (X ), d(X ) 4
r (X ) ← ∼ q(X ), d(X ) 4
s(X ) ← ∼ r (X ), p(X , Y ), q(Y ) 4
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 135 / 178
gringo
Match
A substitution is a mapping from variables to terms
Given sets B and D of atoms, a substitution θ is a match of B in D,
if Bθ ⊆ D
Given a set B of atoms and a set D of ground atoms, define
Θ(B, D) = { θ | θ is a ⊆ -minimal match of B in D }
Example {X 7→ 1} and {X 7→ 2} are ⊆-minimal matches of {p(X )}
in {p(1), p(2), p(3)}, while match {X 7→ 1, Y 7→ 2} is not
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 136 / 178
gringo
Match
A substitution is a mapping from variables to terms
Given sets B and D of atoms, a substitution θ is a match of B in D,
if Bθ ⊆ D
Given a set B of atoms and a set D of ground atoms, define
Θ(B, D) = { θ | θ is a ⊆ -minimal match of B in D }
Example {X 7→ 1} and {X 7→ 2} are ⊆-minimal matches of {p(X )}
in {p(1), p(2), p(3)}, while match {X 7→ 1, Y 7→ 2} is not
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 136 / 178
gringo
Match
A substitution is a mapping from variables to terms
Given sets B and D of atoms, a substitution θ is a match of B in D,
if Bθ ⊆ D
Given a set B of atoms and a set D of ground atoms, define
Θ(B, D) = { θ | θ is a ⊆ -minimal match of B in D }
Example {X 7→ 1} and {X 7→ 2} are ⊆-minimal matches of {p(X )}
in {p(1), p(2), p(3)}, while match {X 7→ 1, Y 7→ 2} is not
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 136 / 178
gringo
Match
A substitution is a mapping from variables to terms
Given sets B and D of atoms, a substitution θ is a match of B in D,
if Bθ ⊆ D
Given a set B of atoms and a set D of ground atoms, define
Θ(B, D) = { θ | θ is a ⊆ -minimal match of B in D }
Example {X 7→ 1} and {X 7→ 2} are ⊆-minimal matches of {p(X )}
in {p(1), p(2), p(3)}, while match {X 7→ 1, Y 7→ 2} is not
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 136 / 178
gringo
Naive instantiation
Algorithm 1: NaiveInstantiation
Input : A safe (first-order) logic program P
Output : A ground logic program P 0
1 D := ∅
2 P 0 := ∅
3 repeat
4 D 0 := D
5 foreach r ∈ P do
6 B := body (r )+
7 foreach θ ∈ Θ(B, D) do
8 D := D ∪ {head(r )θ}
9 P 0 := P 0 ∪ {r θ}
10 until D = D 0
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 137 / 178
gringo
Predicate-rule dependency graph
1 d(a) 2 d(c) 5 q(a) 6 q(b)
3 d(d) d/1 q(X ) ← ∼ r (X ), d(X ) q/1
4
8 p(a, b) 9 p(b, c) r (X ) ← ∼ q(X ), d(X )
7
10 p(c, d) p/2 r /1
p(X , Z ) ← p(X , Y ), p(Y , Z ) s(X ) ← ∼ r (X ), p(X , Y ), q(Y ) s/1
11 12 13
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 138 / 178
gringo
Instantiation
SCC Θ(B, D) D P0
1 {∅} d(a) d(a) ←
2 {∅} d(c) d(c) ←
3 {∅} d(d) d(d) ←
5 {∅} q(a) q(a) ←
6 {∅} q(b) q(b) ←
7 {{X 7→ a}, q(a) ← ∼ r (a), d(a)
{X 7→ c}, q(c) q(c) ← ∼ r (c), d(c)
{X 7→ d}, q(d) q(d) ← ∼ r (d), d(d)
{X 7→ a}, r (a) ← ∼ q(a), d(a)
{X 7→ c}, r (c) r (c) ← ∼ q(c), d(c)
{X 7→ d}} r (d) r (d) ← ∼ q(d), d(d)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 139 / 178
gringo
Instantiation
SCC Θ(B, D) D P0
8 {∅} p(a, b) p(a, b) ←
9 {∅} p(b, c) p(b, c) ←
10 {∅} p(c, d) p(c, d) ←
11 {{X 7→ a, Y 7→ b, Z 7→ c}, p(a, c) p(a, c) ← p(a, b), p(b, c)
{X 7→ b, Y 7→ c, Z 7→ d}} p(b, d) p(b, d) ← p(b, c), p(c, d)
{{X 7→ a, Y 7→ c, Z 7→ d}, p(a, d) p(a, d) ← p(a, c), p(c, d)
{X 7→ a, Y 7→ b, Z 7→ d}} p(a, d) ← p(a, b), p(b, d)
12 {{X 7→ a, Y 7→ b}, s(a) s(a) ← ∼ r (a), p(a, b), q(b)
{X 7→ a, Y 7→ c}, s(a) ← ∼ r (a), p(a, c), q(c)
{X 7→ a, Y 7→ d}, s(a) ← ∼ r (a), p(a, d), q(d)
{X 7→ b, Y 7→ c}, s(b) s(b) ← ∼ r (b), p(b, c), q(c)
{X 7→ b, Y 7→ d}, s(b) ← ∼ r (b), p(b, d), q(d)
{X 7→ c, Y 7→ d}} s(c) s(c) ← ∼ r (c), p(c, d), q(d)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 140 / 178
clasp
Outline
23 Potassco
24 gringo
25 clasp
26 Siblings
claspfolio
clingcon
iclingo
oclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 141 / 178
clasp
clasp
clasp is a native ASP solver combining conflict-driven search with
sophisticated reasoning techniques:
Advanced preprocessing including, like equivalence reasoning
lookback-based decision heuristics
restart policies
nogood deletion
progress saving
dedicated data structures for binary and ternary nogoods
lazy data structures (watched literals) for long nogoods
dedicated data structures for cardinality and weight constraints
lazy unfounded set checking based on “source pointers”
tight integration of unit propagation and unfounded set checking
various reasoning modes
parallel search
...
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 142 / 178
clasp
clasp
clasp is a native ASP solver combining conflict-driven search with
sophisticated reasoning techniques:
Advanced preprocessing including, like equivalence reasoning
lookback-based decision heuristics
restart policies
nogood deletion
progress saving
dedicated data structures for binary and ternary nogoods
lazy data structures (watched literals) for long nogoods
dedicated data structures for cardinality and weight constraints
lazy unfounded set checking based on “source pointers”
tight integration of unit propagation and unfounded set checking
various reasoning modes
parallel search
...
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 142 / 178
clasp
clasp
clasp is a native ASP solver combining conflict-driven search with
sophisticated reasoning techniques:
Advanced preprocessing including, like equivalence reasoning
lookback-based decision heuristics
restart policies
nogood deletion
progress saving
dedicated data structures for binary and ternary nogoods
lazy data structures (watched literals) for long nogoods
dedicated data structures for cardinality and weight constraints
lazy unfounded set checking based on “source pointers”
tight integration of unit propagation and unfounded set checking
various reasoning modes
parallel search
...
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 142 / 178
clasp
Reasoning modes of clasp
Beyond deciding (stable) model existence, clasp allows for:
Optimization
Enumeration (without solution recording)
Projective enumeration (without solution recording)
Intersection and Union (linear solution computation)
and combinations thereof
clasp allows for
ASP solving (smodels format)
MaxSAT and SAT solving (extended dimacs format)
PB solving (opb and wbo format)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 143 / 178
clasp
Reasoning modes of clasp
Beyond deciding (stable) model existence, clasp allows for:
Optimization
Enumeration (without solution recording)
Projective enumeration (without solution recording)
Intersection and Union (linear solution computation)
and combinations thereof
clasp allows for
ASP solving (smodels format)
MaxSAT and SAT solving (extended dimacs format)
PB solving (opb and wbo format)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 143 / 178
clasp
Parallel search in clasp
clasp
pursues a coarse-grained, task-parallel approach to parallel search
via shared memory multi-threading
up to 64 configurable (non-hierarchic) threads
allows for parallel solving via search space splitting
and/or competing strategies
both supported by solver portfolios
features different nogood exchange policies
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 144 / 178
clasp
Parallel search in clasp
clasp
pursues a coarse-grained, task-parallel approach to parallel search
via shared memory multi-threading
up to 64 configurable (non-hierarchic) threads
allows for parallel solving via search space splitting
and/or competing strategies
both supported by solver portfolios
features different nogood exchange policies
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 144 / 178
clasp
Parallel search in clasp
clasp
pursues a coarse-grained, task-parallel approach to parallel search
via shared memory multi-threading
up to 64 configurable (non-hierarchic) threads
allows for parallel solving via search space splitting
and/or competing strategies
both supported by solver portfolios
features different nogood exchange policies
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 144 / 178
clasp
Parallel search in clasp
clasp
pursues a coarse-grained, task-parallel approach to parallel search
via shared memory multi-threading
up to 64 configurable (non-hierarchic) threads
allows for parallel solving via search space splitting
and/or competing strategies
both supported by solver portfolios
features different nogood exchange policies
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 144 / 178
clasp
Sequential CDCL-style solving
loop
propagate // deterministically assign literals
if no conflict then
if all variables assigned then return solution
else decide // non-deterministically assign some literal
else
if top-level conflict then return unsatisfiable
else
analyze // analyze conflict and add conflict constraint
backjump // unassign literals until conflict constraint is unit
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 145 / 178
clasp
Parallel CDCL-style solving in clasp
while work available
while no (result) message to send
communicate // exchange information with other solver
propagate // deterministically assign literals
if no conflict then
if all variables assigned then send solution
else decide // non-deterministically assign some literal
else
if root-level conflict then send unsatisfiable
else if external conflict then send unsatisfiable
else
analyze // analyze conflict and add conflict constraint
backjump // unassign literals until conflict constraint is unit
communicate // exchange results (and receive work)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 146 / 178
clasp
Parallel CDCL-style solving in clasp
while work available
while no (result) message to send
communicate // exchange information with other solver
propagate // deterministically assign literals
if no conflict then
if all variables assigned then send solution
else decide // non-deterministically assign some literal
else
if root-level conflict then send unsatisfiable
else if external conflict then send unsatisfiable
else
analyze // analyze conflict and add conflict constraint
backjump // unassign literals until conflict constraint is unit
communicate // exchange results (and receive work)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 146 / 178
clasp
Parallel CDCL-style solving in clasp
while work available
while no (result) message to send
communicate // exchange information with other solver
propagate // deterministically assign literals
if no conflict then
if all variables assigned then send solution
else decide // non-deterministically assign some literal
else
if root-level conflict then send unsatisfiable
else if external conflict then send unsatisfiable
else
analyze // analyze conflict and add conflict constraint
backjump // unassign literals until conflict constraint is unit
communicate // exchange results (and receive work)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 146 / 178
clasp
Parallel CDCL-style solving in clasp
while work available
while no (result) message to send
communicate // exchange information with other solver
propagate // deterministically assign literals
if no conflict then
if all variables assigned then send solution
else decide // non-deterministically assign some literal
else
if root-level conflict then send unsatisfiable
else if external conflict then send unsatisfiable
else
analyze // analyze conflict and add conflict constraint
backjump // unassign literals until conflict constraint is unit
communicate // exchange results (and receive work)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 146 / 178
clasp
Parallel CDCL-style solving in clasp
while work available
while no (result) message to send
communicate // exchange information with other solver
propagate // deterministically assign literals
if no conflict then
if all variables assigned then send solution
else decide // non-deterministically assign some literal
else
if root-level conflict then send unsatisfiable
else if external conflict then send unsatisfiable
else
analyze // analyze conflict and add conflict constraint
backjump // unassign literals until conflict constraint is unit
communicate // exchange results (and receive work)
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 146 / 178
clasp
Multi-threaded architecture of clasp
Coordination
Preprocessing SharedContext ParallelContext
Propositional Enumerator Threads S1 S2 . . . Sn
Program Variables
Builder Counter T W . . . S
Atoms Bodies Queue P1 P2 . . . Pn
Preprocessor
Preprocessor Static Nogoods
Shared Nogoods
Implication Graph Nogood
Distributor
Logic Solver 1. . . n
Program Conflict Recorded Nogoods
Resolution
Decision
Heuristic Propagation
Assignment Unit Post
Post
Propagation Propagation
Propagation
Atoms/Bodies
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 147 / 178
clasp
Multi-threaded architecture of clasp
Coordination
Preprocessing SharedContext ParallelContext
Propositional Enumerator Threads S1 S2 . . . Sn
Program Variables
Builder Counter T W . . . S
Atoms Bodies Queue P1 P2 . . . Pn
Preprocessor
Preprocessor Static Nogoods
Shared Nogoods
Implication Graph Nogood
Distributor
Logic Solver 1. . . n
Program Conflict Recorded Nogoods
Resolution
Decision
Heuristic Propagation
Assignment Unit Post
Post
Propagation Propagation
Propagation
Atoms/Bodies
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 147 / 178
clasp
Multi-threaded architecture of clasp
Coordination
Preprocessing SharedContext ParallelContext
Propositional Enumerator Threads S1 S2 . . . Sn
Program Variables
Builder Counter T W . . . S
Atoms Bodies Queue P1 P2 . . . Pn
Preprocessor
Preprocessor Static Nogoods
Shared Nogoods
Implication Graph Nogood
Distributor
Logic Solver 1. . . n
Program Conflict Recorded Nogoods
Resolution
Decision
Heuristic Propagation
Assignment Unit Post
Post
Propagation Propagation
Propagation
Atoms/Bodies
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 147 / 178
clasp
Multi-threaded architecture of clasp
Coordination
Preprocessing SharedContext ParallelContext
Propositional Enumerator Threads S1 S2 . . . Sn
Program Variables
Builder Counter T W . . . S
Atoms Bodies Queue P1 P2 . . . Pn
Preprocessor
Preprocessor Static Nogoods
Shared Nogoods
Implication Graph Nogood
Distributor
Logic Solver 1. . . n
Program Conflict Recorded Nogoods
Resolution
Decision
Heuristic Propagation
Assignment Unit Post
Post
Propagation Propagation
Propagation
Atoms/Bodies
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 147 / 178
clasp
clasp in context
Compare clasp (2.0.5) to the multi-threaded SAT solvers
cryptominisat (2.9.2)
manysat (1.1)
miraxt (2009)
plingeling (587f)
all run with four and eight threads in their default settings
160/300 benchmarks from crafted category at SAT’11
all solvable by ppfolio in 1000 seconds
crafted SAT benchmarks are closest to ASP benchmarks
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 148 / 178
clasp
clasp in context
clasp-t1
-t4
120 -t8
cryptominisat-2.9.2-t4
-t8
miraxt-2009-t4
-t8
plingeling-587-t4
100 -t8
manysat-1.1-t4
-t8
Solved instances
80
60
40
20
1 10 100 1000
Time in seconds
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 149 / 178
clasp
Using clasp
--help[=<n>],-h : Print {1=basic|2=more|3=full} help and exit
--parallel-mode,-t <arg>: Run parallel search with given number of threads
<arg>: <n {1..64}>[,<mode {compete|split}>]
<n> : Number of threads to use in search
<mode>: Run competition or splitting based search [compete]
--configuration=<arg> : Configure default configuration [frumpy]
<arg>: {frumpy|jumpy|handy|crafty|trendy|chatty}
frumpy: Use conservative defaults
jumpy : Use aggressive defaults
handy : Use defaults geared towards large problems
crafty: Use defaults geared towards crafted problems
trendy: Use defaults geared towards industrial problems
chatty: Use 4 competing threads initialized via the default portfolio
--print-portfolio,-g : Print default portfolio and exit
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 150 / 178
clasp
Using clasp
--help[=<n>],-h : Print {1=basic|2=more|3=full} help and exit
--parallel-mode,-t <arg>: Run parallel search with given number of threads
<arg>: <n {1..64}>[,<mode {compete|split}>]
<n> : Number of threads to use in search
<mode>: Run competition or splitting based search [compete]
--configuration=<arg> : Configure default configuration [frumpy]
<arg>: {frumpy|jumpy|handy|crafty|trendy|chatty}
frumpy: Use conservative defaults
jumpy : Use aggressive defaults
handy : Use defaults geared towards large problems
crafty: Use defaults geared towards crafted problems
trendy: Use defaults geared towards industrial problems
chatty: Use 4 competing threads initialized via the default portfolio
--print-portfolio,-g : Print default portfolio and exit
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 150 / 178
clasp
Using clasp
--help[=<n>],-h : Print {1=basic|2=more|3=full} help and exit
--parallel-mode,-t <arg>: Run parallel search with given number of threads
<arg>: <n {1..64}>[,<mode {compete|split}>]
<n> : Number of threads to use in search
<mode>: Run competition or splitting based search [compete]
--configuration=<arg> : Configure default configuration [frumpy]
<arg>: {frumpy|jumpy|handy|crafty|trendy|chatty}
frumpy: Use conservative defaults
jumpy : Use aggressive defaults
handy : Use defaults geared towards large problems
crafty: Use defaults geared towards crafted problems
trendy: Use defaults geared towards industrial problems
chatty: Use 4 competing threads initialized via the default portfolio
--print-portfolio,-g : Print default portfolio and exit
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 150 / 178
clasp
Using clasp
--help[=<n>],-h : Print {1=basic|2=more|3=full} help and exit
--parallel-mode,-t <arg>: Run parallel search with given number of threads
<arg>: <n {1..64}>[,<mode {compete|split}>]
<n> : Number of threads to use in search
<mode>: Run competition or splitting based search [compete]
--configuration=<arg> : Configure default configuration [frumpy]
<arg>: {frumpy|jumpy|handy|crafty|trendy|chatty}
frumpy: Use conservative defaults
jumpy : Use aggressive defaults
handy : Use defaults geared towards large problems
crafty: Use defaults geared towards crafted problems
trendy: Use defaults geared towards industrial problems
chatty: Use 4 competing threads initialized via the default portfolio
--print-portfolio,-g : Print default portfolio and exit
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 150 / 178
clasp
Using clasp
--help[=<n>],-h : Print {1=basic|2=more|3=full} help and exit
--parallel-mode,-t <arg>: Run parallel search with given number of threads
<arg>: <n {1..64}>[,<mode {compete|split}>]
<n> : Number of threads to use in search
<mode>: Run competition or splitting based search [compete]
--configuration=<arg> : Configure default configuration [frumpy]
<arg>: {frumpy|jumpy|handy|crafty|trendy|chatty}
frumpy: Use conservative defaults
jumpy : Use aggressive defaults
handy : Use defaults geared towards large problems
crafty: Use defaults geared towards crafted problems
trendy: Use defaults geared towards industrial problems
chatty: Use 4 competing threads initialized via the default portfolio
--print-portfolio,-g : Print default portfolio and exit
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 150 / 178
Siblings
Outline
23 Potassco
24 gringo
25 clasp
26 Siblings
claspfolio
clingcon
iclingo
oclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 151 / 178
Siblings claspfolio
Outline
23 Potassco
24 gringo
25 clasp
26 Siblings
claspfolio
clingcon
iclingo
oclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 152 / 178
Siblings claspfolio
claspfolio
Automatic selection of clasp configuration
among 25 configuration via (learned) classifiers
Basic architecture of claspfolio:
gringo clasp Prediction clasp
Models claspfolio
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 153 / 178
Siblings claspfolio
Solving with clasp (as usual)
$ clasp queens500 --quiet
clasp version 2.0.2
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 11.445s (Solving: 10.58s 1st Model: 10.55s Unsat: 0.00s)
CPU Time : 11.410s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 154 / 178
Siblings claspfolio
Solving with clasp (as usual)
$ clasp queens500 --quiet
clasp version 2.0.2
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 11.445s (Solving: 10.58s 1st Model: 10.55s Unsat: 0.00s)
CPU Time : 11.410s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 154 / 178
Siblings claspfolio
Solving with claspfolio
$ claspfolio queens500 --quiet
PRESOLVING
Reading from queens500
Solving...
claspfolio version 1.0.1 (based on clasp version 2.0.2)
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 4.785s (Solving: 3.96s 1st Model: 3.92s Unsat: 0.00s)
CPU Time : 4.780s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 155 / 178
Siblings claspfolio
Solving with claspfolio
$ claspfolio queens500 --quiet
PRESOLVING
Reading from queens500
Solving...
claspfolio version 1.0.1 (based on clasp version 2.0.2)
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 4.785s (Solving: 3.96s 1st Model: 3.92s Unsat: 0.00s)
CPU Time : 4.780s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 155 / 178
Siblings claspfolio
Solving with claspfolio
$ claspfolio queens500 --quiet
PRESOLVING
Reading from queens500
Solving...
claspfolio version 1.0.1 (based on clasp version 2.0.2)
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 4.785s (Solving: 3.96s 1st Model: 3.92s Unsat: 0.00s)
CPU Time : 4.780s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 155 / 178
Siblings claspfolio
Solving with claspfolio
$ claspfolio queens500 --quiet
PRESOLVING
Reading from queens500
Solving...
claspfolio version 1.0.1 (based on clasp version 2.0.2)
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 4.785s (Solving: 3.96s 1st Model: 3.92s Unsat: 0.00s)
CPU Time : 4.780s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 155 / 178
Siblings claspfolio
Feature-extraction with claspfolio
$ claspfolio --features queens500
PRESOLVING
Reading from queens500
Solving...
UNKNOWN
Features : 84998,3994,0,250000,1.020,62.594,63.844,21.281,84998, \
3994,100,250000,1.020,62.594,63.844,21.281,84998,3994,250,250000, \
1.020,62.594,63.844,21.281,84998,3994,475,250000,1.020,62.594, \
63.844,21.281,757989,757989,0,510983,506992,3990,1,0,127.066,9983, \
1023958,502993,1994,518971,1,0,0,254994,0,3990,0.100,0.000,99.900, \
0,270303,812,4,0,812,2223,2223,262,262,2.738,2.738,0.000,812,812, \
2270.982,0,0.000
$ claspfolio --list-features
maxLearnt,Constraints,LearntConstraints,FreeVars,Vars/FreeVars, ...
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 156 / 178
Siblings claspfolio
Feature-extraction with claspfolio
$ claspfolio --features queens500
PRESOLVING
Reading from queens500
Solving...
UNKNOWN
Features : 84998,3994,0,250000,1.020,62.594,63.844,21.281,84998, \
3994,100,250000,1.020,62.594,63.844,21.281,84998,3994,250,250000, \
1.020,62.594,63.844,21.281,84998,3994,475,250000,1.020,62.594, \
63.844,21.281,757989,757989,0,510983,506992,3990,1,0,127.066,9983, \
1023958,502993,1994,518971,1,0,0,254994,0,3990,0.100,0.000,99.900, \
0,270303,812,4,0,812,2223,2223,262,262,2.738,2.738,0.000,812,812, \
2270.982,0,0.000
$ claspfolio --list-features
maxLearnt,Constraints,LearntConstraints,FreeVars,Vars/FreeVars, ...
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 156 / 178
Siblings claspfolio
Feature-extraction with claspfolio
$ claspfolio --features queens500
PRESOLVING
Reading from queens500
Solving...
UNKNOWN
Features : 84998,3994,0,250000,1.020,62.594,63.844,21.281,84998, \
3994,100,250000,1.020,62.594,63.844,21.281,84998,3994,250,250000, \
1.020,62.594,63.844,21.281,84998,3994,475,250000,1.020,62.594, \
63.844,21.281,757989,757989,0,510983,506992,3990,1,0,127.066,9983, \
1023958,502993,1994,518971,1,0,0,254994,0,3990,0.100,0.000,99.900, \
0,270303,812,4,0,812,2223,2223,262,262,2.738,2.738,0.000,812,812, \
2270.982,0,0.000
$ claspfolio --list-features
maxLearnt,Constraints,LearntConstraints,FreeVars,Vars/FreeVars, ...
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 156 / 178
Siblings claspfolio
Prediction with claspfolio
$ claspfolio queens500 --decisionvalues
PRESOLVING
Reading from queens500
Solving...
Portfolio Decision Values:
[1] : 3.437538 [10] : 3.639444 [19] : 3.726391
[2] : 3.501728 [11] : 3.483334 [20] : 3.020325
[3] : 3.784733 [12] : 3.271890 [21] : 3.220219
[4] : 3.672955 [13] : 3.344085 [22] : 3.998709
[5] : 3.557408 [14] : 3.315235 [23] : 3.961214
[6] : 3.942037 [15] : 3.620479 [24] : 3.512924
[7] : 3.335304 [16] : 3.396838 [25] : 3.078143
[8] : 3.375315 [17] : 3.238764
[9] : 3.432931 [18] : 3.403484
UNKNOWN
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 157 / 178
Siblings claspfolio
Prediction with claspfolio
$ claspfolio queens500 --decisionvalues
PRESOLVING
Reading from queens500
Solving...
Portfolio Decision Values:
[1] : 3.437538 [10] : 3.639444 [19] : 3.726391
[2] : 3.501728 [11] : 3.483334 [20] : 3.020325
[3] : 3.784733 [12] : 3.271890 [21] : 3.220219
[4] : 3.672955 [13] : 3.344085 [22] : 3.998709
[5] : 3.557408 [14] : 3.315235 [23] : 3.961214
[6] : 3.942037 [15] : 3.620479 [24] : 3.512924
[7] : 3.335304 [16] : 3.396838 [25] : 3.078143
[8] : 3.375315 [17] : 3.238764
[9] : 3.432931 [18] : 3.403484
UNKNOWN
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 157 / 178
Siblings claspfolio
Prediction with claspfolio
$ claspfolio queens500 --decisionvalues
PRESOLVING
Reading from queens500
Solving...
Portfolio Decision Values:
[1] : 3.437538 [10] : 3.639444 [19] : 3.726391
[2] : 3.501728 [11] : 3.483334 [20] : 3.020325
[3] : 3.784733 [12] : 3.271890 [21] : 3.220219
[4] : 3.672955 [13] : 3.344085 [22] : 3.998709
[5] : 3.557408 [14] : 3.315235 [23] : 3.961214
[6] : 3.942037 [15] : 3.620479 [24] : 3.512924
[7] : 3.335304 [16] : 3.396838 [25] : 3.078143
[8] : 3.375315 [17] : 3.238764
[9] : 3.432931 [18] : 3.403484
UNKNOWN
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 157 / 178
Siblings claspfolio
Solving with claspfolio (slightly verbosely)
$ claspfolio queens500 --quiet --autoverbose=1
PRESOLVING
Reading from queens500
Solving...
Chosen configuration: [20]
clasp --configurations=./models/portfolio.txt \
--modelpath=./models/ \
queens500 --quiet --autoverbose=1 \
--heu=VSIDS --sat-pre=20,25,120 --trans-ext=integ
claspfolio version 1.0.1 (based on clasp version 2.0.2)
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 4.783s (Solving: 3.96s 1st Model: 3.93s Unsat: 0.00s)
CPU Time : 4.760s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 158 / 178
Siblings claspfolio
Solving with claspfolio (slightly verbosely)
$ claspfolio queens500 --quiet --autoverbose=1
PRESOLVING
Reading from queens500
Solving...
Chosen configuration: [20]
clasp --configurations=./models/portfolio.txt \
--modelpath=./models/ \
queens500 --quiet --autoverbose=1 \
--heu=VSIDS --sat-pre=20,25,120 --trans-ext=integ
claspfolio version 1.0.1 (based on clasp version 2.0.2)
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 4.783s (Solving: 3.96s 1st Model: 3.93s Unsat: 0.00s)
CPU Time : 4.760s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 158 / 178
Siblings claspfolio
Solving with claspfolio (slightly verbosely)
$ claspfolio queens500 --quiet --autoverbose=1
PRESOLVING
Reading from queens500
Solving...
Chosen configuration: [20]
clasp --configurations=./models/portfolio.txt \
--modelpath=./models/ \
queens500 --quiet --autoverbose=1 \
--heu=VSIDS --sat-pre=20,25,120 --trans-ext=integ
claspfolio version 1.0.1 (based on clasp version 2.0.2)
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 4.783s (Solving: 3.96s 1st Model: 3.93s Unsat: 0.00s)
CPU Time : 4.760s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 158 / 178
Siblings claspfolio
Solving with claspfolio (slightly verbosely)
$ claspfolio queens500 --quiet --autoverbose=1
PRESOLVING
Reading from queens500
Solving...
Chosen configuration: [20]
clasp --configurations=./models/portfolio.txt \
--modelpath=./models/ \
queens500 --quiet --autoverbose=1 \
--heu=VSIDS --sat-pre=20,25,120 --trans-ext=integ
claspfolio version 1.0.1 (based on clasp version 2.0.2)
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 4.783s (Solving: 3.96s 1st Model: 3.93s Unsat: 0.00s)
CPU Time : 4.760s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 158 / 178
Siblings claspfolio
Solving with claspfolio (slightly verbosely)
$ claspfolio queens500 --quiet --autoverbose=1
PRESOLVING
Reading from queens500
Solving...
Chosen configuration: [20]
clasp --configurations=./models/portfolio.txt \
--modelpath=./models/ \
queens500 --quiet --autoverbose=1 \
--heu=VSIDS --sat-pre=20,25,120 --trans-ext=integ
claspfolio version 1.0.1 (based on clasp version 2.0.2)
Reading from queens500
Solving...
SATISFIABLE
Models : 1+
Time : 4.783s (Solving: 3.96s 1st Model: 3.93s Unsat: 0.00s)
CPU Time : 4.760s
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 158 / 178
Siblings clingcon
Outline
23 Potassco
24 gringo
25 clasp
26 Siblings
claspfolio
clingcon
iclingo
oclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 159 / 178
Siblings clingcon
clingcon
Hybrid grounding and solving
Solving in hybrid domains, like Bio-Informatics
Basic architecture of clingcon:
clingcon
gringo clasp
Theory Theory Theory
Language Propagator Solver
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 160 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
time(0..t). $domain(0..500).
bucket(a). volume(a,0) $== 0.
bucket(b). volume(b,0) $== 100.
1 { pour(B,T) : bucket(B) } 1 :- time(T), T < t.
1 $<= amount(B,T) :- pour(B,T), T < t.
amount(B,T) $<= 30 :- pour(B,T), T < t.
amount(B,T) $== 0 :- not pour(B,T), bucket(B), time(T), T < t.
volume(B,T+1) $== volume(B,T) $+ amount(B,T) :- bucket(B), time(T), T < t.
down(B,T) :- volume(C,T) $< volume(B,T), bucket(B;C), time(T).
up(B,T) :- not down(B,T), bucket(B), time(T).
:- up(a,t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 161 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
time(0..t). $domain(0..500).
bucket(a). volume(a,0) $== 0.
bucket(b). volume(b,0) $== 100.
1 { pour(B,T) : bucket(B) } 1 :- time(T), T < t.
1 $<= amount(B,T) :- pour(B,T), T < t.
amount(B,T) $<= 30 :- pour(B,T), T < t.
amount(B,T) $== 0 :- not pour(B,T), bucket(B), time(T), T < t.
volume(B,T+1) $== volume(B,T) $+ amount(B,T) :- bucket(B), time(T), T < t.
down(B,T) :- volume(C,T) $< volume(B,T), bucket(B;C), time(T).
up(B,T) :- not down(B,T), bucket(B), time(T).
:- up(a,t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 161 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
time(0..t). $domain(0..500).
bucket(a). volume(a,0) $== 0.
bucket(b). volume(b,0) $== 100.
1 { pour(B,T) : bucket(B) } 1 :- time(T), T < t.
1 $<= amount(B,T) :- pour(B,T), T < t.
amount(B,T) $<= 30 :- pour(B,T), T < t.
amount(B,T) $== 0 :- not pour(B,T), bucket(B), time(T), T < t.
volume(B,T+1) $== volume(B,T) $+ amount(B,T) :- bucket(B), time(T), T < t.
down(B,T) :- volume(C,T) $< volume(B,T), bucket(B;C), time(T).
up(B,T) :- not down(B,T), bucket(B), time(T).
:- up(a,t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 161 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
time(0..t). $domain(0..500).
bucket(a). volume(a,0) $== 0.
bucket(b). volume(b,0) $== 100.
1 { pour(B,T) : bucket(B) } 1 :- time(T), T < t.
1 $<= amount(B,T) :- pour(B,T), T < t.
amount(B,T) $<= 30 :- pour(B,T), T < t.
amount(B,T) $== 0 :- not pour(B,T), bucket(B), time(T), T < t.
volume(B,T+1) $== volume(B,T) $+ amount(B,T) :- bucket(B), time(T), T < t.
down(B,T) :- volume(C,T) $< volume(B,T), bucket(B;C), time(T).
up(B,T) :- not down(B,T), bucket(B), time(T).
:- up(a,t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 161 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
time(0..t). $domain(0..500).
bucket(a). volume(a,0) $== 0.
bucket(b). volume(b,0) $== 100.
1 { pour(B,T) : bucket(B) } 1 :- time(T), T < t.
:- pour(B,T), T < t, not (1 $<= amount(B,T)).
amount(B,T) $<= 30 :- pour(B,T), T < t.
amount(B,T) $== 0 :- not pour(B,T), bucket(B), time(T), T < t.
volume(B,T+1) $== volume(B,T) $+ amount(B,T) :- bucket(B), time(T), T < t.
down(B,T) :- volume(C,T) $< volume(B,T), bucket(B;C), time(T).
up(B,T) :- not down(B,T), bucket(B), time(T).
:- up(a,t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 161 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
time(0..t). $domain(0..500).
bucket(a). volume(a,0) $== 0.
bucket(b). volume(b,0) $== 100.
1 { pour(B,T) : bucket(B) } 1 :- time(T), T < t.
:- pour(B,T), T < t, 1 $> amount(B,T).
amount(B,T) $<= 30 :- pour(B,T), T < t.
amount(B,T) $== 0 :- not pour(B,T), bucket(B), time(T), T < t.
volume(B,T+1) $== volume(B,T) $+ amount(B,T) :- bucket(B), time(T), T < t.
down(B,T) :- volume(C,T) $< volume(B,T), bucket(B;C), time(T).
up(B,T) :- not down(B,T), bucket(B), time(T).
:- up(a,t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 161 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
time(0..t). $domain(0..500).
bucket(a). volume(a,0) $== 0.
bucket(b). volume(b,0) $== 100.
1 { pour(B,T) : bucket(B) } 1 :- time(T), T < t.
:- pour(B,T), T < t, 1 $> amount(B,T).
:- pour(B,T), T < t, amount(B,T) $> 30.
amount(B,T) $== 0 :- not pour(B,T), bucket(B), time(T), T < t.
volume(B,T+1) $== volume(B,T) $+ amount(B,T) :- bucket(B), time(T), T < t.
down(B,T) :- volume(C,T) $< volume(B,T), bucket(B;C), time(T).
up(B,T) :- not down(B,T), bucket(B), time(T).
:- up(a,t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 161 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
time(0..t). $domain(0..500).
bucket(a). volume(a,0) $== 0.
bucket(b). volume(b,0) $== 100.
1 { pour(B,T) : bucket(B) } 1 :- time(T), T < t.
:- pour(B,T), T < t, 1 $> amount(B,T).
:- pour(B,T), T < t, amount(B,T) $> 30.
:- not pour(B,T), bucket(B), time(T), T < t, amount(B,T) $!= 0.
volume(B,T+1) $== volume(B,T) $+ amount(B,T) :- bucket(B), time(T), T < t.
down(B,T) :- volume(C,T) $< volume(B,T), bucket(B;C), time(T).
up(B,T) :- not down(B,T), bucket(B), time(T).
:- up(a,t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 161 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
time(0..t). $domain(0..500).
bucket(a). volume(a,0) $== 0.
bucket(b). volume(b,0) $== 100.
1 { pour(B,T) : bucket(B) } 1 :- time(T), T < t.
:- pour(B,T), T < t, 1 $> amount(B,T).
:- pour(B,T), T < t, amount(B,T) $> 30.
:- not pour(B,T), bucket(B), time(T), T < t, amount(B,T) $!= 0.
:- bucket(B), time(T), T < t, volume(B,T+1) $!= volume(B,T)$+amount(B,T).
down(B,T) :- volume(C,T) $< volume(B,T), bucket(B;C), time(T).
up(B,T) :- not down(B,T), bucket(B), time(T).
:- up(a,t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 161 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp --text
time(0). ... time(4). $domain(0..500).
bucket(a). :- volume(a,0) $!= 0.
bucket(b). :- volume(b,0) $!= 100.
1 { pour(b,0), pour(a,0) } 1. ... 1 { pour(b,3), pour(a,3) } 1.
:- pour(a,0), 1 $> amount(a,0). ... :- pour(a,3), 1 $> amount(a,3).
:- pour(b,0), 1 $> amount(b,0). ... :- pour(b,3), 1 $> amount(b,3).
:- pour(a,0), amount(a,0) $> 30. ... :- pour(a,3), amount(a,3) $> 30.
:- pour(b,0), amount(b,0) $> 30. ... :- pour(b,3), amount(b,3) $> 30.
:- not pour(a,0), amount(a,0) $!= 0. ... :- not pour(a,3), amount(a,3) $!= 0.
:- not pour(b,0), amount(b,0) $!= 0. ... :- not pour(b,3), amount(b,3) $!= 0.
:- volume(a,1) $!= (volume(a,0) $+ amount(a,0)). ... :- volume(a,4) $!= (volume(a,3) $+ amount(a,3)).
:- volume(b,1) $!= (volume(b,0) $+ amount(b,0)). ... :- volume(b,4) $!= (volume(b,3) $+ amount(b,3)).
down(a,0) :- volume(a,0) $< volume(a,0). ... down(a,4) :- volume(a,4) $< volume(a,4).
down(a,0) :- volume(b,0) $< volume(a,0). ... down(a,4) :- volume(b,4) $< volume(a,4).
down(b,0) :- volume(a,0) $< volume(b,0). ... down(b,4) :- volume(a,4) $< volume(b,4).
down(b,0) :- volume(b,0) $< volume(b,0). ... down(b,4) :- volume(b,4) $< volume(b,4).
up(a,0) :- not down(a,0). ... up(a,4) :- not down(a,4).
up(b,0) :- not down(b,0). ... up(b,4) :- not down(b,4).
:- up(a,4).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 162 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp --text
time(0). ... time(4). $domain(0..500).
bucket(a). :- volume(a,0) $!= 0.
bucket(b). :- volume(b,0) $!= 100.
1 { pour(b,0), pour(a,0) } 1. ... 1 { pour(b,3), pour(a,3) } 1.
:- pour(a,0), 1 $> amount(a,0). ... :- pour(a,3), 1 $> amount(a,3).
:- pour(b,0), 1 $> amount(b,0). ... :- pour(b,3), 1 $> amount(b,3).
:- pour(a,0), amount(a,0) $> 30. ... :- pour(a,3), amount(a,3) $> 30.
:- pour(b,0), amount(b,0) $> 30. ... :- pour(b,3), amount(b,3) $> 30.
:- not pour(a,0), amount(a,0) $!= 0. ... :- not pour(a,3), amount(a,3) $!= 0.
:- not pour(b,0), amount(b,0) $!= 0. ... :- not pour(b,3), amount(b,3) $!= 0.
:- volume(a,1) $!= (volume(a,0) $+ amount(a,0)). ... :- volume(a,4) $!= (volume(a,3) $+ amount(a,3)).
:- volume(b,1) $!= (volume(b,0) $+ amount(b,0)). ... :- volume(b,4) $!= (volume(b,3) $+ amount(b,3)).
down(a,0) :- volume(a,0) $< volume(a,0). ... down(a,4) :- volume(a,4) $< volume(a,4).
down(a,0) :- volume(b,0) $< volume(a,0). ... down(a,4) :- volume(b,4) $< volume(a,4).
down(b,0) :- volume(a,0) $< volume(b,0). ... down(b,4) :- volume(a,4) $< volume(b,4).
down(b,0) :- volume(b,0) $< volume(b,0). ... down(b,4) :- volume(b,4) $< volume(b,4).
up(a,0) :- not down(a,0). ... up(a,4) :- not down(a,4).
up(b,0) :- not down(b,0). ... up(b,4) :- not down(b,4).
:- up(a,4).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 162 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp --text
time(0). ... time(4). $domain(0..500).
bucket(a). :- volume(a,0) $!= 0.
bucket(b). :- volume(b,0) $!= 100.
1 { pour(b,0), pour(a,0) } 1. ... 1 { pour(b,3), pour(a,3) } 1.
:- pour(a,0), 1 $> amount(a,0). ... :- pour(a,3), 1 $> amount(a,3).
:- pour(b,0), 1 $> amount(b,0). ... :- pour(b,3), 1 $> amount(b,3).
:- pour(a,0), amount(a,0) $> 30. ... :- pour(a,3), amount(a,3) $> 30.
:- pour(b,0), amount(b,0) $> 30. ... :- pour(b,3), amount(b,3) $> 30.
:- not pour(a,0), amount(a,0) $!= 0. ... :- not pour(a,3), amount(a,3) $!= 0.
:- not pour(b,0), amount(b,0) $!= 0. ... :- not pour(b,3), amount(b,3) $!= 0.
:- volume(a,1) $!= (volume(a,0) $+ amount(a,0)). ... :- volume(a,4) $!= (volume(a,3) $+ amount(a,3)).
:- volume(b,1) $!= (volume(b,0) $+ amount(b,0)). ... :- volume(b,4) $!= (volume(b,3) $+ amount(b,3)).
down(a,0) :- volume(a,0) $< volume(a,0). ... down(a,4) :- volume(a,4) $< volume(a,4).
down(a,0) :- volume(b,0) $< volume(a,0). ... down(a,4) :- volume(b,4) $< volume(a,4).
down(b,0) :- volume(a,0) $< volume(b,0). ... down(b,4) :- volume(a,4) $< volume(b,4).
down(b,0) :- volume(b,0) $< volume(b,0). ... down(b,4) :- volume(b,4) $< volume(b,4).
up(a,0) :- not down(a,0). ... up(a,4) :- not down(a,4).
up(b,0) :- not down(b,0). ... up(b,4) :- not down(b,4).
:- up(a,4).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 162 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp --text
time(0). ... time(4). $domain(0..500).
bucket(a). :- volume(a,0) $!= 0.
bucket(b). :- volume(b,0) $!= 100.
1 { pour(b,0), pour(a,0) } 1. ... 1 { pour(b,3), pour(a,3) } 1.
:- pour(a,0), 1 $> amount(a,0). ... :- pour(a,3), 1 $> amount(a,3).
:- pour(b,0), 1 $> amount(b,0). ... :- pour(b,3), 1 $> amount(b,3).
:- pour(a,0), amount(a,0) $> 30. ... :- pour(a,3), amount(a,3) $> 30.
:- pour(b,0), amount(b,0) $> 30. ... :- pour(b,3), amount(b,3) $> 30.
:- not pour(a,0), amount(a,0) $!= 0. ... :- not pour(a,3), amount(a,3) $!= 0.
:- not pour(b,0), amount(b,0) $!= 0. ... :- not pour(b,3), amount(b,3) $!= 0.
:- volume(a,1) $!= (volume(a,0) $+ amount(a,0)). ... :- volume(a,4) $!= (volume(a,3) $+ amount(a,3)).
:- volume(b,1) $!= (volume(b,0) $+ amount(b,0)). ... :- volume(b,4) $!= (volume(b,3) $+ amount(b,3)).
down(a,0) :- volume(a,0) $< volume(a,0). ... down(a,4) :- volume(a,4) $< volume(a,4).
down(a,0) :- volume(b,0) $< volume(a,0). ... down(a,4) :- volume(b,4) $< volume(a,4).
down(b,0) :- volume(a,0) $< volume(b,0). ... down(b,4) :- volume(a,4) $< volume(b,4).
down(b,0) :- volume(b,0) $< volume(b,0). ... down(b,4) :- volume(b,4) $< volume(b,4).
up(a,0) :- not down(a,0). ... up(a,4) :- not down(a,4).
up(b,0) :- not down(b,0). ... up(b,4) :- not down(b,4).
:- up(a,4).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 162 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp --text
time(0). ... time(4). $domain(0..500).
bucket(a). :- volume(a,0) $!= 0.
bucket(b). :- volume(b,0) $!= 100.
1 { pour(b,0), pour(a,0) } 1. ... 1 { pour(b,3), pour(a,3) } 1.
:- pour(a,0), 1 $> amount(a,0). ... :- pour(a,3), 1 $> amount(a,3).
:- pour(b,0), 1 $> amount(b,0). ... :- pour(b,3), 1 $> amount(b,3).
:- pour(a,0), amount(a,0) $> 30. ... :- pour(a,3), amount(a,3) $> 30.
:- pour(b,0), amount(b,0) $> 30. ... :- pour(b,3), amount(b,3) $> 30.
:- not pour(a,0), amount(a,0) $!= 0. ... :- not pour(a,3), amount(a,3) $!= 0.
:- not pour(b,0), amount(b,0) $!= 0. ... :- not pour(b,3), amount(b,3) $!= 0.
:- volume(a,1) $!= (volume(a,0) $+ amount(a,0)). ... :- volume(a,4) $!= (volume(a,3) $+ amount(a,3)).
:- volume(b,1) $!= (volume(b,0) $+ amount(b,0)). ... :- volume(b,4) $!= (volume(b,3) $+ amount(b,3)).
down(a,0) :- volume(a,0) $< volume(a,0). ... down(a,4) :- volume(a,4) $< volume(a,4).
down(a,0) :- volume(b,0) $< volume(a,0). ... down(a,4) :- volume(b,4) $< volume(a,4).
down(b,0) :- volume(a,0) $< volume(b,0). ... down(b,4) :- volume(a,4) $< volume(b,4).
down(b,0) :- volume(b,0) $< volume(b,0). ... down(b,4) :- volume(b,4) $< volume(b,4).
up(a,0) :- not down(a,0). ... up(a,4) :- not down(a,4).
up(b,0) :- not down(b,0). ... up(b,4) :- not down(b,4).
:- up(a,4).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 162 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp 0
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=[11..30] amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=[11..30] amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=[11..30] amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=[11..30] amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=[11..30] volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=[41..60] volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=[71..90] volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=[101..120] volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 163 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp 0
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=[11..30] amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=[11..30] amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=[11..30] amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=[11..30] amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=[11..30] volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=[41..60] volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=[71..90] volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=[101..120] volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 163 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp 0
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=[11..30] amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=[11..30] amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=[11..30] amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=[11..30] amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=[11..30] volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=[41..60] volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=[71..90] volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=[101..120] volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 163 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp 0
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=[11..30] amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=[11..30] amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=[11..30] amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=[11..30] amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=[11..30] volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=[41..60] volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=[71..90] volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=[101..120] volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 163 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp 0
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=[11..30] amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=[11..30] amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=[11..30] amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=[11..30] amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=[11..30] volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=[41..60] volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=[71..90] volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=[101..120] volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1
Time : 0.000 Boolean variables
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 163 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp 0
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=[11..30] amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=[11..30] amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=[11..30] amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=[11..30] amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=[11..30] volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=[41..60] volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=[71..90] volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=[101..120] volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1
Time : 0.000 Non-Boolean variables
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 163 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp --csp-num-as=1
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=11 amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=30 amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=30 amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=30 amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=11 volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=41 volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=71 volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=101 volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1+
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 164 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp --csp-num-as=1
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=11 amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=30 amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=30 amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=30 amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=11 volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=41 volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=71 volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=101 volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1+
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 164 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp --csp-num-as=1
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=11 amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=30 amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=30 amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=30 amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=11 volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=41 volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=71 volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=101 volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1+
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 164 / 178
Siblings clingcon
Pouring Water into Buckets on a Scale
$ clingcon --const t=4 balance.lp --csp-num-as=1
Answer: 1
pour(a,0) pour(a,1) pour(a,2) pour(a,3)
amount(a,0)=11 amount(b,0)=0 1 $> amount(b,0) amount(a,0) $!= 0
amount(a,1)=30 amount(b,1)=0 1 $> amount(b,1) amount(a,1) $!= 0
amount(a,2)=30 amount(b,2)=0 1 $> amount(b,2) amount(a,2) $!= 0
amount(a,3)=30 amount(b,3)=0 1 $> amount(b,3) amount(a,3) $!= 0
volume(a,0)=0 volume(b,0)=100 volume(a,0) $< volume(b,0)
volume(a,1)=11 volume(b,1)=100 volume(a,1) $< volume(b,1)
volume(a,2)=41 volume(b,2)=100 volume(a,2) $< volume(b,2)
volume(a,3)=71 volume(b,3)=100 volume(a,3) $< volume(b,3)
volume(a,4)=101 volume(b,4)=100 volume(b,4) $< volume(a,4)
SATISFIABLE
Models : 1+
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 164 / 178
Siblings iclingo
Outline
23 Potassco
24 gringo
25 clasp
26 Siblings
claspfolio
clingcon
iclingo
oclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 165 / 178
Siblings iclingo
iclingo
Incremental grounding and solving
Offline solving in dynamic domains, like Automated Planning
Basic architecture of iclingo:
gringo clasp
iclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 166 / 178
Siblings iclingo
Incremental ASP Solving Process
Logic - Stable
Program
- Grounder - Solver Models
6
Modeling
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
Logic - Stable
Program
- Grounder - Solver Models
6
Modeling
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
B
Pk - Grounder - Solver - Stable
Models
Qk
6
Modeling
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
B
Pk - Grounder - Solver - Stable
Models
Qk
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
B
Grounder Pk Solver - Stable
Models
Qk
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
B
Grounder P1 Solver - Stable
Models
Q1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
B
Grounder P1
Q1
Solver 8
- Stable
Models
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1
Q1
Solver 8
- Stable
Models
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1 Solver - Stable
Models
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1 Solver - Stable
Models
P2
Q2
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1
P2
Solver 8
- Stable
Models
Q2
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1 Solver - Stable
Models
P2
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1 Solver - Stable
Models
P2
P3
Q3
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1
P2
Solver 8
- Stable
Models
P3
Q3
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1 Solver - Stable
Models
P2
P3
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1 Solver - Stable
Models
P2
P3
..
.
Pn
Qn
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Incremental ASP Solving Process
?
B
Grounder P1
P2
Solver 4
- Stable
Models
P3
..
.
Pn
Qn
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 167 / 178
Siblings iclingo
Simplistic STRIPS Planning
#base.
fluent(p). action(a). action(b). init(p).
fluent(q). pre(a,p). pre(b,q).
fluent(r). add(a,q). add(b,r). query(r).
del(a,p). del(b,q).
holds(P,0) :- init(P).
#cumulative t.
1 { occ(A,t) : action(A) } 1.
:- occ(A,t), pre(A,F), not holds(F,t-1).
ocdel(F,t) :- occ(A,t), del(A,F).
holds(F,t) :- occ(A,t), add(A,F).
holds(F,t) :- holds(F,t-1), not ocdel(F,t).
#volatile t.
:- query(F), not holds(F,t).
#hide. #show occ/2.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 168 / 178
Siblings iclingo
Simplistic STRIPS Planning
#base.
fluent(p). action(a). action(b). init(p).
fluent(q). pre(a,p). pre(b,q).
fluent(r). add(a,q). add(b,r). query(r).
del(a,p). del(b,q).
holds(P,0) :- init(P).
#cumulative t.
1 { occ(A,t) : action(A) } 1.
:- occ(A,t), pre(A,F), not holds(F,t-1).
ocdel(F,t) :- occ(A,t), del(A,F).
holds(F,t) :- occ(A,t), add(A,F).
holds(F,t) :- holds(F,t-1), not ocdel(F,t).
#volatile t.
:- query(F), not holds(F,t).
#hide. #show occ/2.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 168 / 178
Siblings iclingo
Simplistic STRIPS Planning
#base.
fluent(p). action(a). action(b). init(p).
fluent(q). pre(a,p). pre(b,q).
fluent(r). add(a,q). add(b,r). query(r).
del(a,p). del(b,q).
holds(P,0) :- init(P).
#cumulative t.
1 { occ(A,t) : action(A) } 1.
:- occ(A,t), pre(A,F), not holds(F,t-1).
ocdel(F,t) :- occ(A,t), del(A,F).
holds(F,t) :- occ(A,t), add(A,F).
holds(F,t) :- holds(F,t-1), not ocdel(F,t).
#volatile t.
:- query(F), not holds(F,t).
#hide. #show occ/2.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 168 / 178
Siblings iclingo
Simplistic STRIPS Planning
#base.
fluent(p). action(a). action(b). init(p).
fluent(q). pre(a,p). pre(b,q).
fluent(r). add(a,q). add(b,r). query(r).
del(a,p). del(b,q).
holds(P,0) :- init(P).
#cumulative t.
1 { occ(A,t) : action(A) } 1.
:- occ(A,t), pre(A,F), not holds(F,t-1).
ocdel(F,t) :- occ(A,t), del(A,F).
holds(F,t) :- occ(A,t), add(A,F).
holds(F,t) :- holds(F,t-1), not ocdel(F,t).
#volatile t.
:- query(F), not holds(F,t).
#hide. #show occ/2.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 168 / 178
Siblings iclingo
Simplistic STRIPS Planning
$ iclingo iplanning.lp
Answer: 1
occ(a,1) occ(b,2)
SATISFIABLE
Models : 1
Total Steps : 2
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 169 / 178
Siblings iclingo
Simplistic STRIPS Planning
$ iclingo iplanning.lp
Answer: 1
occ(a,1) occ(b,2)
SATISFIABLE
Models : 1
Total Steps : 2
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 169 / 178
Siblings iclingo
Simplistic STRIPS Planning
$ iclingo iplanning.lp --istats
=============== step 1 ===============
Models : 0
Time : 0.000 (g: 0.000, p: 0.000, s: 0.000)
Rules : 27
Choices : 0
Conflicts: 0
=============== step 2 ===============
Answer: 1
occ(a,1) occ(b,2)
Models : 1
Time : 0.000 (g: 0.000, p: 0.000, s: 0.000)
Rules : 16
Choices : 0
Conflicts: 0
=============== Summary ===============
SATISFIABLE
Models : 1
Total Steps : 2
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 170 / 178
Siblings iclingo
Simplistic STRIPS Planning
$ iclingo iplanning.lp --istats
=============== step 1 ===============
Models : 0
Time : 0.000 (g: 0.000, p: 0.000, s: 0.000)
Rules : 27
Choices : 0
Conflicts: 0
=============== step 2 ===============
Answer: 1
occ(a,1) occ(b,2)
Models : 1
Time : 0.000 (g: 0.000, p: 0.000, s: 0.000)
Rules : 16
Choices : 0
Conflicts: 0
=============== Summary ===============
SATISFIABLE
Models : 1
Total Steps : 2
Time : 0.000
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 170 / 178
Siblings oclingo
Outline
23 Potassco
24 gringo
25 clasp
26 Siblings
claspfolio
clingcon
iclingo
oclingo
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 171 / 178
Siblings oclingo
oclingo
Reactive grounding and solving
Online solving in dynamic domains, like Robotics
Basic architecture of oclingo:
gringo clasp
oclingo
Controller
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 172 / 178
Siblings oclingo
Reactive ASP Solving Process
Logic - Stable
Program
- Grounder - Solver Models
6
Modeling
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
Logic - Stable
Program
- Grounder - Solver Models
6
Modeling
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
B
Pk - Grounder - Solver - Stable
Models
Qk
6
Modeling
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
B
Pk - Grounder - Solver - Stable
Models
Qk
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
B
Grounder Pk Solver - Stable
Models
Qk
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
B
Grounder Pk Solver - Stable
Models
Qk
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
B
Grounder Pk Solver - Stable
Models
Qk
6
E1
F1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F1
E1
B
Grounder Pk Solver - Stable
Models
Qk
6
E1
F1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F1
E1
B
Grounder P1
..
.
Solver 4
- Stable
Models
6 Pn 1
Qn1
E1
F1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F1
E1
B
Grounder P1 Solver - Stable
.. Models
.
6 Pn 1
Qn1
E2 E1
F2 F1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F2
E2
E1
B
Grounder P1 Solver - Stable
.. Models
.
6 Pn 1
Qn1
E2 E1
F2 F1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F2
E2
E1
B
Grounder P1
..
.
Solver 4
- Stable
Models
6 Pn 2
Qn2
E2 E1
F2 F1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F2
E2
E1
B
Grounder P1 Solver - Stable
.. Models
.
6 Pn 2
Qn2
E3 E2 E1
F3 F2 F1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F3
E3
E2
E1
B
Grounder P1 Solver - Stable
.. Models
.
6 Pn 2
Qn2
E3 E2 E1
F3 F2 F1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F3
E3
E2
E1
B
Grounder P1
..
.
Solver 4
- Stable
Models
6 Pn 3
Qn3
E3 E2 E1
F3 F2 F1
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F42
E42
..
.
E1
B
Grounder P1 Solver - Stable
.. Models
.
6 Pn41
Qn41
E42 E41 E40 E39 E38 E37 E36 E
F42 F41 F40 F39 F38 F37 F36 F
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F42
E42
..
.
E1
B
Grounder P1
..
.
Solver 4
- Stable
Models
6 Pn42
Qn42
E42 E41 E40 E39 E38 E37 E36 E
F42 F41 F40 F39 F38 F37 F36 F
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F42
E42
Update
..
.
E1
B
Grounder P1 Solver - Stable
.. Models
.
6 Pn42
Qn42
E42 E41 E40 E39 E38 E37 E36 E
F42 F41 F40 F39 F38 F37 F36 F
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F42
E42
Query
..
.
E1
B
Grounder P1 Solver - Stable
.. Models
.
6 Pn42
Qn42
E42 E41 E40 E39 E38 E37 E36 E
F42 F41 F40 F39 F38 F37 F36 F
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Reactive ASP Solving Process
F42
E42
Erasure
..
.
8
E1
B
Grounder P1 Solver - Stable
.. Models
.
6 Pn42
Qn42
E42 E41 E40 E39 E38 E37 E36 E
F42 F41 F40 F39 F38 F37 F36 F
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 173 / 178
Siblings oclingo
Elevator Control
#base.
floor(1..3).
atFloor(1,0).
#cumulative t.
#external request(F,t) : floor(F).
1 { atFloor(F-1;F+1,t) } 1 :- atFloor(F,t-1), floor(F).
:- atFloor(F,t), not floor(F).
requested(F,t) :- request(F,t), floor(F), not atFloor(F,t).
requested(F,t) :- requested(F,t-1), floor(F), not atFloor(F,t).
goal(t) :- not requested(F,t) : floor(F).
#volatile t.
:- not goal(t).
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 174 / 178
Siblings oclingo
Pushing a button
oClingo acts as a server listening on a port
waiting for client requests
To issue such requests, a separate controller program
sends online progressions using network sockets
For instance,
#step 1.
request(3,1).
#endstep.
This process terminates when the client sends
#stop.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 175 / 178
Siblings oclingo
Pushing a button
oClingo acts as a server listening on a port
waiting for client requests
To issue such requests, a separate controller program
sends online progressions using network sockets
For instance,
#step 1.
request(3,1).
#endstep.
This process terminates when the client sends
#stop.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 175 / 178
Siblings oclingo
Pushing a button
oClingo acts as a server listening on a port
waiting for client requests
To issue such requests, a separate controller program
sends online progressions using network sockets
For instance,
#step 1.
request(3,1).
#endstep.
This process terminates when the client sends
#stop.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 175 / 178
Siblings oclingo
Pushing a button
oClingo acts as a server listening on a port
waiting for client requests
To issue such requests, a separate controller program
sends online progressions using network sockets
For instance,
#step 1.
request(3,1).
#endstep.
This process terminates when the client sends
#stop.
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 175 / 178
Summary
Outline
27 Summary
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 176 / 178
Summary
Summary
ASP is emerging as a viable tool for Knowledge Representation
and Reasoning
ASP offers efficient and versatile off-the-shelf solving technology
http://potassco.sourceforge.net
ASP, CASC, MISC, PB, and SAT competitions
ASP offers an expanding functionality and ease of use
Rapid application development tool
ASP has a growing range of applications
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 177 / 178
Summary
Summary
ASP is emerging as a viable tool for Knowledge Representation
and Reasoning
ASP offers efficient and versatile off-the-shelf solving technology
http://potassco.sourceforge.net
ASP, CASC, MISC, PB, and SAT competitions
ASP offers an expanding functionality and ease of use
Rapid application development tool
ASP has a growing range of applications
ASP = DB+LP+KR+SAT
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 177 / 178
Summary
The (forthcoming) Potassco Book
1. Motivation
2. Introduction
3. Basic modeling Answer Set Solving in Practice
4. Grounding Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub
University of Potsdam
5. Characterizations
6. Solving
7. Systems SYNTHESIS LECTURES ON SAMPLE SERIES #1
M
8. Advanced modeling &C Morgan & cLaypool publishers
9. Conclusions
Visit the Potassco project !
Sourceforge http://potassco.sourceforge.net
Google+ https://plus.google.com/102537396696345299260
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 178 / 178
Summary
The (forthcoming) Potassco Book
1. Motivation
2. Introduction
3. Basic modeling Answer Set Solving in Practice
4. Grounding Martin Gebser, Roland Kaminski, Benjamin Kaufmann, and Torsten Schaub
University of Potsdam
5. Characterizations
6. Solving
7. Systems SYNTHESIS LECTURES ON SAMPLE SERIES #1
M
8. Advanced modeling &C Morgan & cLaypool publishers
9. Conclusions
Visit the Potassco project !
Sourceforge http://potassco.sourceforge.net
Google+ https://plus.google.com/102537396696345299260
Torsten Schaub (KRR@UP) ASP FMCAD@Cambridge 178 / 178
You might also like
- Intelligence Artificial: Search and Constraint SatisfactionNo ratings yetIntelligence Artificial: Search and Constraint Satisfaction17 pages
- Problem Solving & Problem Design Using C: Introduction & OverviewNo ratings yetProblem Solving & Problem Design Using C: Introduction & Overview14 pages
- ASP and Subset Minimality Enumeration Cautious Reas - 2023 - Artificial IntellNo ratings yetASP and Subset Minimality Enumeration Cautious Reas - 2023 - Artificial Intell25 pages
- GE8151-Notes - by WWW - EasyEngineering.net 5No ratings yetGE8151-Notes - by WWW - EasyEngineering.net 539 pages
- Chapter 5 Introduction Problem Solving Part-1No ratings yetChapter 5 Introduction Problem Solving Part-19 pages
- Introduction Programming and Problem SolvingNo ratings yetIntroduction Programming and Problem Solving24 pages
- Ingeniería Del Conocimiento: Msc. Jorge EspinosaNo ratings yetIngeniería Del Conocimiento: Msc. Jorge Espinosa103 pages
- W1L2 Introduction Programming and Problem SolvingNo ratings yetW1L2 Introduction Programming and Problem Solving24 pages
- COMP102 Introduction To Problem Solving - 160514No ratings yetCOMP102 Introduction To Problem Solving - 16051438 pages
- Lecture1 - 308 of Alll Please Let Me Earn MyNo ratings yetLecture1 - 308 of Alll Please Let Me Earn My20 pages
- An Introduction To Answer Set Programming: Paul Vicol October 14, 2015 (Based On Slides by Torsten Schaub)No ratings yetAn Introduction To Answer Set Programming: Paul Vicol October 14, 2015 (Based On Slides by Torsten Schaub)51 pages
- Object Oriented Programming With C++ (2140705) 2017-18 Student Lab ManualNo ratings yetObject Oriented Programming With C++ (2140705) 2017-18 Student Lab Manual8 pages
- Generated by "Markdown To PDF Fast Converter" Https://Dub - Sh/79WtusyNo ratings yetGenerated by "Markdown To PDF Fast Converter" Https://Dub - Sh/79Wtusy7 pages
- Algorithmic Thinking and Problem Solving - Test 1docxNo ratings yetAlgorithmic Thinking and Problem Solving - Test 1docx14 pages
- Features of Java: A List of Most Important Features of Java Language Is Given Below100% (1)Features of Java: A List of Most Important Features of Java Language Is Given Below14 pages
- 01 Problem Solving and Algorithm DesignNo ratings yet01 Problem Solving and Algorithm Design27 pages
- Implementation of Sequence and Associative Containers For Different Algorithms Using Their IteratorsNo ratings yetImplementation of Sequence and Associative Containers For Different Algorithms Using Their Iterators50 pages
- Java Circle - JVM Alternative LanguagesNo ratings yetJava Circle - JVM Alternative Languages46 pages
- Basics of Dev C++: Structure of A ProgramNo ratings yetBasics of Dev C++: Structure of A Program29 pages
- Introduction To Object Oriented TechnologyNo ratings yetIntroduction To Object Oriented Technology23 pages
- Data Abstraction Problem Solving With C 7th Edition Frank M. Carrano and Timothy M. HenryNo ratings yetData Abstraction Problem Solving With C 7th Edition Frank M. Carrano and Timothy M. Henry50 pages
- Introduction To Programming and Problem SolvingNo ratings yetIntroduction To Programming and Problem Solving33 pages
- Abstraction, Encapsulation, and Information HidingNo ratings yetAbstraction, Encapsulation, and Information Hiding4 pages
- ExcelR Selenium Course Agenda With Value Added CoursesNo ratings yetExcelR Selenium Course Agenda With Value Added Courses24 pages
- Fill Data: Qno O1 O2 O3 O4 Ans1 Ans2 Ans3 Ans4No ratings yetFill Data: Qno O1 O2 O3 O4 Ans1 Ans2 Ans3 Ans410 pages
