9 Oct, 2019 [LOPSTR’19] Modeling and Reasoning in Event Calculus Using Goal-Directed Constraint Answer Set Programming Joaqu´ınArias1,2 Zhuo Chen3 Manuel Carro1,2 Gopal Gupta3 1IMDEA Software Institute, 2Universidad Politecnica´ de Madrid 3University of Texas at Dallas

madrid institute for advanced studies in software development technologies www.software.imdea.org

Introduction Example: Commonsense Reasoning (CR) • Requires modelling: • Non-monotonicity. • Continuous (i.e., non-discrete) characteristics of the world. • Event Calculus (EC): formalism that represents continuous change and captures law of inertia. • EC components: Narrative A description of the world we want to model.

Assumes circumscription. A tap fills a vessel [Shanahan 1999]. Axioms A generic description of how the world behaves given a narrative. • Implementing EC: logic reasoning + continuous domains.

madrid institute for advanced studies in software development technologies 1 / 12 www.software.imdea.org

Introduction Example:

Reasoning on EC: deduction / proving in first order logic (+ circumscription).

Approaches • Non-interactive theorem prover: likely won’t always answer [12]. • Prolog: incomplete implementations [15; 10; 2]. • Constraint Answer Set Programming (CASP): requires grounding. • Has been used to model (discrete) EC [8; 9]. A tap fills a vessel [Shanahan 1999]. • Limited to variables ranging over discrete, finite domains.

madrid institute for advanced studies in software development technologies 1 / 12 The program: Has two models: p ← ¬q. {p,¬q} or {q,¬p} q ← ¬p.

• (Constraint) Answer Set Programming systems compute those stable models. • However, most (C)ASP systems require a grounding phase that restricts the domains and constraints supported.

www.software.imdea.org

(Constraint) Logic Programming + negation

• A logic program P is a set of First Order Logic clauses. • Programs with negation in the body can have different, incomparable models: stable model semantics [Gelfond and Lifschitz 1988].

madrid institute for advanced studies in software development technologies 2 / 12 • (Constraint) Answer Set Programming systems compute those stable models. • However, most (C)ASP systems require a grounding phase that restricts the domains and constraints supported.

www.software.imdea.org

(Constraint) Logic Programming + negation

• A logic program P is a set of First Order Logic clauses. • Programs with negation in the body can have different, incomparable models: stable model semantics [Gelfond and Lifschitz 1988]. The program: Has two models: p ← ¬q. {p,¬q} or {q,¬p} q ← ¬p.

madrid institute for advanced studies in software development technologies 2 / 12 www.software.imdea.org

(Constraint) Logic Programming + negation

• A logic program P is a set of First Order Logic clauses. • Programs with negation in the body can have different, incomparable models: stable model semantics [Gelfond and Lifschitz 1988]. The program: Has two models: p ← ¬q. {p,¬q} or {q,¬p} q ← ¬p.

• (Constraint) Answer Set Programming systems compute those stable models. • However, most (C)ASP systems require a grounding phase that restricts the domains and constraints supported.

madrid institute for advanced studies in software development technologies 2 / 12 • Provides a constructive and sound default negation: • Make deductions in the absence of positive information. cross(T):- not train(T). • Dual rules (synthesized by s(CASP) compiler) infer conditions for goal to fail.

• Provides support for classical negation. • Represent explicit (negative) knowledge. cross(T):--train(T) . • Allows rules with negated heads. -train(T):- not barrier(up,T). • Global constraints ensure consistency. :- train(T),-train(T) .

www.software.imdea.org s(CASP)

• Goal directed execution of CASP programs without grounding. • The execution starts with a query. ?-T #>5,T #<8, cross(T) . • Returns (partial) stable models [Gelfond and Lifschitz 1988] Only literals supporting the query. • For each successful top-down derivation, on backtracking returns: • A justification tree. Explanation for observations. • Bindings and constraints as part of the model. {T #> 5, T #< 7/3, cross(T), train(7.3)}.

madrid institute for advanced studies in software development technologies 3 / 12 • Provides support for classical negation. • Represent explicit (negative) knowledge. cross(T):--train(T) . • Allows rules with negated heads. -train(T):- not barrier(up,T). • Global constraints ensure consistency. :- train(T),-train(T) .

www.software.imdea.org s(CASP)

• Goal directed execution of CASP programs without grounding. • The execution starts with a query. ?-T #>5,T #<8, cross(T) . • Returns (partial) stable models [Gelfond and Lifschitz 1988] Only literals supporting the query. • For each successful top-down derivation, on backtracking returns: • A justification tree. Explanation for observations. • Bindings and constraints as part of the model. {T #> 5, T #< 7/3, cross(T), train(7.3)}.

• Provides a constructive and sound default negation: • Make deductions in the absence of positive information. cross(T):- not train(T). • Dual rules (synthesized by s(CASP) compiler) infer conditions for goal to fail.

madrid institute for advanced studies in software development technologies 3 / 12 www.software.imdea.org s(CASP)

• Goal directed execution of CASP programs without grounding. • The execution starts with a query. ?-T #>5,T #<8, cross(T) . • Returns (partial) stable models [Gelfond and Lifschitz 1988] Only literals supporting the query. • For each successful top-down derivation, on backtracking returns: • A justification tree. Explanation for observations. • Bindings and constraints as part of the model. {T #> 5, T #< 7/3, cross(T), train(7.3)}.

• Provides a constructive and sound default negation: • Make deductions in the absence of positive information. cross(T):- not train(T). • Dual rules (synthesized by s(CASP) compiler) infer conditions for goal to fail.

• Provides support for classical negation. • Represent explicit (negative) knowledge. cross(T):--train(T) . • Allows rules with negated heads. -train(T):- not barrier(up,T). • Global constraints ensure consistency. :- train(T),-train(T) .

madrid institute for advanced studies in software development technologies 3 / 12 • State constraints are introduced to capture restrictions on the model: • Ensure consistency of the narrative w.r.t. the axioms. :- holds(F,T),-holds(F,T) . • Trajectories: a fluent depends on the time elapsed since another fluent: • The level of water level(L2) correspond directly to the time elapsed T2-T1. L2 = L1 + T2-T1 • Support for non-monotonic reasoning • EC theory includes negation in rules and infers negative knowledge. • Therefore, alternative worlds can appear. Vessel size either max_level(10) or max_level(16).

www.software.imdea.org

Event Calculus

• EC uses a universal theory (axioms) to reason about scenarios (narrative). • An event happens at a time point. tapOn: The tap opens. • A fluent is a time-varying property of the world. filling: The vessel is being filled. • Time and/or fluents may have continuous quantities associated. level(X) Level of water.

madrid institute for advanced studies in software development technologies 4 / 12 • Trajectories: a fluent depends on the time elapsed since another fluent: • The level of water level(L2) correspond directly to the time elapsed T2-T1. L2 = L1 + T2-T1 • Support for non-monotonic reasoning • EC theory includes negation in rules and infers negative knowledge. • Therefore, alternative worlds can appear. Vessel size either max_level(10) or max_level(16).

www.software.imdea.org

Event Calculus

• EC uses a universal theory (axioms) to reason about scenarios (narrative). • An event happens at a time point. tapOn: The tap opens. • A fluent is a time-varying property of the world. filling: The vessel is being filled. • Time and/or fluents may have continuous quantities associated. level(X) Level of water. • State constraints are introduced to capture restrictions on the model: • Ensure consistency of the narrative w.r.t. the axioms. :- holds(F,T),-holds(F,T) .

madrid institute for advanced studies in software development technologies 4 / 12 • Support for non-monotonic reasoning • EC theory includes negation in rules and infers negative knowledge. • Therefore, alternative worlds can appear. Vessel size either max_level(10) or max_level(16).

www.software.imdea.org

Event Calculus

• EC uses a universal theory (axioms) to reason about scenarios (narrative). • An event happens at a time point. tapOn: The tap opens. • A fluent is a time-varying property of the world. filling: The vessel is being filled. • Time and/or fluents may have continuous quantities associated. level(X) Level of water. • State constraints are introduced to capture restrictions on the model: • Ensure consistency of the narrative w.r.t. the axioms. :- holds(F,T),-holds(F,T) . • Trajectories: a fluent depends on the time elapsed since another fluent: • The level of water level(L2) correspond directly to the time elapsed T2-T1. L2 = L1 + T2-T1

madrid institute for advanced studies in software development technologies 4 / 12 www.software.imdea.org

Event Calculus

• EC uses a universal theory (axioms) to reason about scenarios (narrative). • An event happens at a time point. tapOn: The tap opens. • A fluent is a time-varying property of the world. filling: The vessel is being filled. • Time and/or fluents may have continuous quantities associated. level(X) Level of water. • State constraints are introduced to capture restrictions on the model: • Ensure consistency of the narrative w.r.t. the axioms. :- holds(F,T),-holds(F,T) . • Trajectories: a fluent depends on the time elapsed since another fluent: • The level of water level(L2) correspond directly to the time elapsed T2-T1. L2 = L1 + T2-T1 • Support for non-monotonic reasoning • EC theory includes negation in rules and infers negative knowledge. • Therefore, alternative worlds can appear. Vessel size either max_level(10) or max_level(16).

madrid institute for advanced studies in software development technologies 4 / 12 www.software.imdea.org

Event Calculus Basics: Narrative Predicate Meaning InitiallyN(f) fluent f is false at time 0 InitiallyP(f) fluent f is true at time 0 Happens(e,t) event e occurs at time t Initiates(e,f,t) if e happens at time t, f is true after t Terminates(e,f,t) if e occurs at time t, f is false after t Releases(e,f,t) if e occurs at time t, f is released after t

Trajectory(f1,t 1,f 2,t 2) if f1 is initiated at t1, then f2 is true at t2

StoppedIn(t1,f,t 2)f is stopped between t1 and t2

StartedIn(t1,f,t 2)f starts between t1 and t2 HoldsAt(f,t) fluent f is true at time t

Basic event calculus (BEC) predicates

e = event, f, f1, f2 = fluents and t, t1, t2 = timepoints

madrid institute for advanced studies in software development technologies 5 / 12 www.software.imdea.org

Event Calculus Basics: Axioms

BEC1. StoppedIn(t1,f ,t2) ≡ ∃e,t ( Happens(e,t) ∧ t1 < t < t2 ∧ ( Terminates(e,f ,t) ∨ Releases(e,f ,t)))

BEC2. StartedIn(t1,f ,t2) ≡ ∃e,t ( Happens(e,t) ∧ t1 < t < t2 ∧ ( Initiates(e,f ,t) ∨ Releases(e,f ,t)))

BEC3. HoldsAt(f2,t2) ← Happens(e,t1) ∧ Initiates(e,f1,t1) ∧ Trajectory(f1,t1,f2,t2) ∧ ¬StoppedIn(t1,f1,t2) BEC4. HoldsAt(f ,t) ← InitiallyP(f ) ∧ ¬StoppedIn(0,f ,t)

BEC5. ¬HoldsAt(f ,t) ← InitiallyN(f ) ∧ ¬StartedIn(0,f ,t)

BEC6. HoldsAt(f ,t2) ← Happens(e,t1) ∧ Initiates(e,f ,t1) ∧ t1 < t2 ∧ ¬StoppedIn(t1,f ,t2)

BEC7. ¬HoldsAt(f ,t2) ← Happens(e,t1) ∧ Terminates(e,f ,t1) ∧ t1 < t2 ∧ ¬StartedIn(t1,f ,t2)

Formalization of BEC axioms [Mueller 2014]

madrid institute for advanced studies in software development technologies 6 / 12 www.software.imdea.org

Translating Event Calculus into s(CASP): Scheme

Atoms and Constants: Uniqueness of names [Shanahan 1999] % By default ins(CASP)

Constraints: t1 < t2 T1 #< T2% handled by CLP(Q)

d(X):-b(X ,Y).%+ dual Definitions: D(x) ≡ ∃yB(x,y) not d(X):- c_forall(Y,notb(X ,Y)). Rules with positive head: ∀x(H(x) ← ∃y(A(y) ∧ ¬B(x,y) ∧ x < y)) h(X):-X #

madrid institute for advanced studies in software development technologies 7 / 12 holdsAt(F,T2):- T1 #< T2 , initiates(E,F,T1), happens(E,T1), not stoppedIn(T1,F,T2).

BEC1: StoppedIn(t1,f ,t2) ≡ ∃e,t(Happens(e,t) ∧ t1 < t < t2 ∧ [Terminates(e,f ,t) ∨ Releases(e,f ,t)]) stoppedIn(T1,F,T2):- T1 #

Dual (not stoppedIn/3): introduced by the s(CASP) compiler not stoppedIn(T1,F,T2) :- not o_stoppedIn1(T1,F,T2), not o_stoppedIn2(T1,F,T2).

not o_stoppedIn1(T1,F,T2) :- forall(T,forall(E, not o_stoppedIn1(T1,F,T2,T,E))).

not o_stoppedIn1(T1,F,T2,T,E) :- T1 #>=T. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #= T2. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #

www.software.imdea.org

Translating Event Calculus into s(CASP): Examples

BEC6: HoldsAt(f ,t2) ← Happens(e,t1) ∧ Initiates(e,f ,t1) ∧ t1 < t2 ∧ ¬StoppedIn(t1,f ,t2)

madrid institute for advanced studies in software development technologies 8 / 12 BEC1: StoppedIn(t1,f ,t2) ≡ ∃e,t(Happens(e,t) ∧ t1 < t < t2 ∧ [Terminates(e,f ,t) ∨ Releases(e,f ,t)]) stoppedIn(T1,F,T2):- T1 #

Dual (not stoppedIn/3): introduced by the s(CASP) compiler not stoppedIn(T1,F,T2) :- not o_stoppedIn1(T1,F,T2), not o_stoppedIn2(T1,F,T2).

not o_stoppedIn1(T1,F,T2) :- forall(T,forall(E, not o_stoppedIn1(T1,F,T2,T,E))).

not o_stoppedIn1(T1,F,T2,T,E) :- T1 #>=T. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #= T2. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #

www.software.imdea.org

Translating Event Calculus into s(CASP): Examples

BEC6: HoldsAt(f ,t2) ← Happens(e,t1) ∧ Initiates(e,f ,t1) ∧ t1 < t2 ∧ ¬StoppedIn(t1,f ,t2) holdsAt(F,T2):- T1 #< T2 , initiates(E,F,T1), happens(E,T1), not stoppedIn(T1,F,T2).

madrid institute for advanced studies in software development technologies 8 / 12 stoppedIn(T1,F,T2):- T1 #

Dual (not stoppedIn/3): introduced by the s(CASP) compiler not stoppedIn(T1,F,T2) :- not o_stoppedIn1(T1,F,T2), not o_stoppedIn2(T1,F,T2).

not o_stoppedIn1(T1,F,T2) :- forall(T,forall(E, not o_stoppedIn1(T1,F,T2,T,E))).

not o_stoppedIn1(T1,F,T2,T,E) :- T1 #>=T. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #= T2. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #

www.software.imdea.org

Translating Event Calculus into s(CASP): Examples

BEC6: HoldsAt(f ,t2) ← Happens(e,t1) ∧ Initiates(e,f ,t1) ∧ t1 < t2 ∧ ¬StoppedIn(t1,f ,t2) holdsAt(F,T2):- T1 #< T2 , initiates(E,F,T1), happens(E,T1), not stoppedIn(T1,F,T2).

BEC1: StoppedIn(t1,f ,t2) ≡ ∃e,t(Happens(e,t) ∧ t1 < t < t2 ∧ [Terminates(e,f ,t) ∨ Releases(e,f ,t)])

madrid institute for advanced studies in software development technologies 8 / 12 Dual (not stoppedIn/3): introduced by the s(CASP) compiler not stoppedIn(T1,F,T2) :- not o_stoppedIn1(T1,F,T2), not o_stoppedIn2(T1,F,T2).

not o_stoppedIn1(T1,F,T2) :- forall(T,forall(E, not o_stoppedIn1(T1,F,T2,T,E))).

not o_stoppedIn1(T1,F,T2,T,E) :- T1 #>=T. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #= T2. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #

www.software.imdea.org

Translating Event Calculus into s(CASP): Examples

BEC6: HoldsAt(f ,t2) ← Happens(e,t1) ∧ Initiates(e,f ,t1) ∧ t1 < t2 ∧ ¬StoppedIn(t1,f ,t2) holdsAt(F,T2):- T1 #< T2 , initiates(E,F,T1), happens(E,T1), not stoppedIn(T1,F,T2).

BEC1: StoppedIn(t1,f ,t2) ≡ ∃e,t(Happens(e,t) ∧ t1 < t < t2 ∧ [Terminates(e,f ,t) ∨ Releases(e,f ,t)]) stoppedIn(T1,F,T2):- T1 #

madrid institute for advanced studies in software development technologies 8 / 12 not o_stoppedIn1(T1,F,T2) :- forall(T,forall(E, not o_stoppedIn1(T1,F,T2,T,E))).

not o_stoppedIn1(T1,F,T2,T,E) :- T1 #>=T. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #= T2. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #

www.software.imdea.org

Translating Event Calculus into s(CASP): Examples

BEC6: HoldsAt(f ,t2) ← Happens(e,t1) ∧ Initiates(e,f ,t1) ∧ t1 < t2 ∧ ¬StoppedIn(t1,f ,t2) holdsAt(F,T2):- T1 #< T2 , initiates(E,F,T1), happens(E,T1), not stoppedIn(T1,F,T2).

BEC1: StoppedIn(t1,f ,t2) ≡ ∃e,t(Happens(e,t) ∧ t1 < t < t2 ∧ [Terminates(e,f ,t) ∨ Releases(e,f ,t)]) stoppedIn(T1,F,T2):- T1 #

Dual (not stoppedIn/3): introduced by the s(CASP) compiler not stoppedIn(T1,F,T2) :- not o_stoppedIn1(T1,F,T2), not o_stoppedIn2(T1,F,T2).

madrid institute for advanced studies in software development technologies 8 / 12 not o_stoppedIn1(T1,F,T2,T,E) :- T1 #>=T. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #= T2. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #

www.software.imdea.org

Translating Event Calculus into s(CASP): Examples

BEC6: HoldsAt(f ,t2) ← Happens(e,t1) ∧ Initiates(e,f ,t1) ∧ t1 < t2 ∧ ¬StoppedIn(t1,f ,t2) holdsAt(F,T2):- T1 #< T2 , initiates(E,F,T1), happens(E,T1), not stoppedIn(T1,F,T2).

BEC1: StoppedIn(t1,f ,t2) ≡ ∃e,t(Happens(e,t) ∧ t1 < t < t2 ∧ [Terminates(e,f ,t) ∨ Releases(e,f ,t)]) stoppedIn(T1,F,T2):- T1 #

Dual (not stoppedIn/3): introduced by the s(CASP) compiler not stoppedIn(T1,F,T2) :- not o_stoppedIn1(T1,F,T2), not o_stoppedIn2(T1,F,T2).

not o_stoppedIn1(T1,F,T2) :- forall(T,forall(E, not o_stoppedIn1(T1,F,T2,T,E))).

madrid institute for advanced studies in software development technologies 8 / 12 www.software.imdea.org

Translating Event Calculus into s(CASP): Examples

BEC6: HoldsAt(f ,t2) ← Happens(e,t1) ∧ Initiates(e,f ,t1) ∧ t1 < t2 ∧ ¬StoppedIn(t1,f ,t2) holdsAt(F,T2):- T1 #< T2 , initiates(E,F,T1), happens(E,T1), not stoppedIn(T1,F,T2).

BEC1: StoppedIn(t1,f ,t2) ≡ ∃e,t(Happens(e,t) ∧ t1 < t < t2 ∧ [Terminates(e,f ,t) ∨ Releases(e,f ,t)]) stoppedIn(T1,F,T2):- T1 #

Dual (not stoppedIn/3): introduced by the s(CASP) compiler not stoppedIn(T1,F,T2) :- not o_stoppedIn1(T1,F,T2), not o_stoppedIn2(T1,F,T2).

not o_stoppedIn1(T1,F,T2) :- forall(T,forall(E, not o_stoppedIn1(T1,F,T2,T,E))).

not o_stoppedIn1(T1,F,T2,T,E) :- T1 #>=T. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #= T2. not o_stoppedIn1(T1,F,T2,T,E) :- T1 #

madrid institute for advanced studies in software development technologies 8 / 12 Two alternative worlds

Water level Open tap L2 = L1 + T2-T1 at time 5

Initiate filling the vessel Rim reached, spilling starts

www.software.imdea.org

Example: Encoding Continuous Change.

A vessel is filled with water from a tap [Shanahan 1999]. When the water level reaches the rim, it starts spilling. Note state in fluents.

max_level(10) :- not max_level(16). max_level(16) :- not max_level(10). releases(tapOn,level(0),T) :- happens(tapOn,T). initiallyP(level(0)). trajectory(filling,T1,level(L2),T2) :- happens(overflow,T). T1 #< T2, L2 #= L1+T2-T1, L2 #=< Max, happens(tapOn,5). max_level(Max), holdsAt(level(L1),T1). trajectory(filling,T1,level(overflow),T2) :- terminates(tapOff,filling,T). T1 #< T2, L2 #= L1+T2-T1, L2 #> Max, max_level(Max), holdsAt(level(L1),T1). initiates(tapOn,filling,T). initiates(overflow,spilling,T) :- trajectory(spilling,T1,leak(L1),T2) :- max_level(Max), holdsAt(level(Max),T). holdsAt(filling, T2), T1 #< T2, L1 #= T2-T1.

madrid institute for advanced studies in software development technologies 9 / 12 Water level Open tap L2 = L1 + T2-T1 at time 5

Initiate filling the vessel Rim reached, spilling starts

www.software.imdea.org

Example: Encoding Continuous Change.

Two alternative A vessel is filled with water from a tap [Shanahan 1999]. When the worlds water level reaches the rim, it starts spilling. Note state in fluents.

max_level(10) :- not max_level(16). max_level(16) :- not max_level(10). releases(tapOn,level(0),T) :- happens(tapOn,T). initiallyP(level(0)). trajectory(filling,T1,level(L2),T2) :- happens(overflow,T). T1 #< T2, L2 #= L1+T2-T1, L2 #=< Max, happens(tapOn,5). max_level(Max), holdsAt(level(L1),T1). trajectory(filling,T1,level(overflow),T2) :- terminates(tapOff,filling,T). T1 #< T2, L2 #= L1+T2-T1, L2 #> Max, max_level(Max), holdsAt(level(L1),T1). initiates(tapOn,filling,T). initiates(overflow,spilling,T) :- trajectory(spilling,T1,leak(L1),T2) :- max_level(Max), holdsAt(level(Max),T). holdsAt(filling, T2), T1 #< T2, L1 #= T2-T1.

madrid institute for advanced studies in software development technologies 9 / 12 Two alternative worlds

Water level L2 = L1 + T2-T1

Rim reached, spilling starts

www.software.imdea.org

Example: Encoding Continuous Change.

A vessel is filled with water from a tap [Shanahan 1999]. When the water level reaches the rim, it starts spilling. Note state in fluents.

max_level(10) :- not max_level(16). max_level(16) :- not max_level(10). Open tap releases(tapOn,level(0),T) :- happens(tapOn,T). initiallyP(level(0)at). time 5 trajectory(filling,T1,level(L2),T2) :- happens(overflow,T). T1 #< T2, L2 #= L1+T2-T1, L2 #=< Max, happens(tapOn,5). Initiate max_level(Max), holdsAt(level(L1),T1). filling the vessel trajectory(filling,T1,level(overflow),T2) :- terminates(tapOff,filling,T). T1 #< T2, L2 #= L1+T2-T1, L2 #> Max, max_level(Max), holdsAt(level(L1),T1). initiates(tapOn,filling,T). initiates(overflow,spilling,T) :- trajectory(spilling,T1,leak(L1),T2) :- max_level(Max), holdsAt(level(Max),T). holdsAt(filling, T2), T1 #< T2, L1 #= T2-T1.

madrid institute for advanced studies in software development technologies 9 / 12 Two alternative worlds

Open tap at time 5

Initiate filling the vessel Rim reached, spilling starts

www.software.imdea.org

Example: Encoding Continuous Change.

A vessel is filled with water from a tap [Shanahan 1999]. When the water level reaches the rim, it starts spilling. Note state in fluents.

max_level(10) :- not max_level(16). max_level(16) :- not max_level(10). Water level L2 = L1 + T2-T1releases(tapOn,level(0),T) :- happens(tapOn,T). initiallyP(level(0)). trajectory(filling,T1,level(L2),T2) :- happens(overflow,T). T1 #< T2, L2 #= L1+T2-T1, L2 #=< Max, happens(tapOn,5). max_level(Max), holdsAt(level(L1),T1). trajectory(filling,T1,level(overflow),T2) :- terminates(tapOff,filling,T). T1 #< T2, L2 #= L1+T2-T1, L2 #> Max, max_level(Max), holdsAt(level(L1),T1). initiates(tapOn,filling,T). initiates(overflow,spilling,T) :- trajectory(spilling,T1,leak(L1),T2) :- max_level(Max), holdsAt(level(Max),T). holdsAt(filling, T2), T1 #< T2, L1 #= T2-T1.

madrid institute for advanced studies in software development technologies 9 / 12 Two alternative worlds

Water level Open tap L2 = L1 + T2-T1 at time 5

Initiate filling the vessel

www.software.imdea.org

Example: Encoding Continuous Change.

A vessel is filled with water from a tap [Shanahan 1999]. When the water level reaches the rim, it starts spilling. Note state in fluents.

max_level(10) :- not max_level(16). max_level(16) :- not max_level(10). releases(tapOn,level(0),T) :- happens(tapOn,T). initiallyP(level(0)). trajectory(filling,T1,level(L2),T2) :- happens(overflow,T). T1 #< T2, L2 #= L1+T2-T1, L2 #=< Max, happens(tapOn,5). max_level(Max), holdsAt(level(L1),T1). trajectory(filling,T1,level(overflow),T2) :- Rim reached, terminates(tapOff,filling,T). T1 #< T2, L2 #= L1+T2-T1, L2 #> Max, spilling starts max_level(Max), holdsAt(level(L1),T1). initiates(tapOn,filling,T). initiates(overflow,spilling,T) :- trajectory(spilling,T1,leak(L1),T2) :- max_level(Max), holdsAt(level(Max),T). holdsAt(filling, T2), T1 #< T2, L1 #= T2-T1.

madrid institute for advanced studies in software development technologies 9 / 12 • Same, plus instantiating query variables – note: dense domain. • ?- holdsAt(level(H),15/2) { H #= 5/2, ... } • ?- holdsAt(level(5/2),T) { T #= 15/2, ... } • Model(s) can be read as sequences of events: • ?- holdsAt(spilling,T) returns two models:

{ T #> 15, 5 #< U #< 15, max_level(10), happens(tapOn,5), not happens(TapOff,U), ... } { T #> 21, 5 #< U #< 21, max_level(16), happens(tapOn,5), not happens(TapOff,U), ... }

www.software.imdea.org

Example: Reasoning with Continuous Change.

• Constructs a world consistent with a query: • ?- holdsAt(level(14),19) returns a single model with max_level(16)

madrid institute for advanced studies in software development technologies 10 / 12 • Model(s) can be read as sequences of events: • ?- holdsAt(spilling,T) returns two models:

{ T #> 15, 5 #< U #< 15, max_level(10), happens(tapOn,5), not happens(TapOff,U), ... } { T #> 21, 5 #< U #< 21, max_level(16), happens(tapOn,5), not happens(TapOff,U), ... }

www.software.imdea.org

Example: Reasoning with Continuous Change.

• Constructs a world consistent with a query: • ?- holdsAt(level(14),19) returns a single model with max_level(16) • Same, plus instantiating query variables – note: dense domain. • ?- holdsAt(level(H),15/2) { H #= 5/2, ... } • ?- holdsAt(level(5/2),T) { T #= 15/2, ... }

madrid institute for advanced studies in software development technologies 10 / 12 www.software.imdea.org

Example: Reasoning with Continuous Change.

• Constructs a world consistent with a query: • ?- holdsAt(level(14),19) returns a single model with max_level(16) • Same, plus instantiating query variables – note: dense domain. • ?- holdsAt(level(H),15/2) { H #= 5/2, ... } • ?- holdsAt(level(5/2),T) { T #= 15/2, ... } • Model(s) can be read as sequences of events: • ?- holdsAt(spilling,T) returns two models:

{ T #> 15, 5 #< U #< 15, max_level(10), happens(tapOn,5), not happens(TapOff,U), ... } { T #> 21, 5 #< U #< 21, max_level(16), happens(tapOn,5), not happens(TapOff,U), ... }

madrid institute for advanced studies in software development technologies 10 / 12 www.software.imdea.org

Evaluation We evaluate the advantage of providing constraints over continuous domains. • We compare our implementation with constraints with a similar program with: • No constraints. • Conditions checked when variables are instantiated – in particular, time. • Instantiation simulates grounding. • For optimality, values to be assigned to time depend on initial query. • N.B. This is the usual ASP approach.

Run time (ms) comparison for the light scenario [Mueller 2014].

Queries s(CASP) s(ASP) holdsAt(light_on,2) 233 8,320 -holdsAt(light_on,5) 314 7,952 holdsAt(light_red,2) 231 8,214 holdsAt(light_red,9/4) 234 51,548

madrid institute for advanced studies in software development technologies 11 / 12 THANKS!

• s(CASP) gives explanations via justification tree • Interpreter keeps track of applied rules. • Can return them together with the model as a trace of the deduction associated with the proof.

Future Work • Apply the s(CASP) system to solve planning problems: • Generated plans must obey continuous- and real- time constraints.

www.software.imdea.org

Conclusions

• EC can be naturally and directly encoded in s(CASP). • s(CASP) captures the notion of continuous change in EC: • Thanks to its grounding-free top-down evaluation strategy. • s(CASP) can represent complex models & answer queries: • In a flexible manner. • Thanks to the use of constraints.

madrid institute for advanced studies in software development technologies 12 / 12 THANKS!

Future Work • Apply the s(CASP) system to solve planning problems: • Generated plans must obey continuous- and real- time constraints.

www.software.imdea.org

Conclusions

• EC can be naturally and directly encoded in s(CASP). • s(CASP) captures the notion of continuous change in EC: • Thanks to its grounding-free top-down evaluation strategy. • s(CASP) can represent complex models & answer queries: • In a flexible manner. • Thanks to the use of constraints. • s(CASP) gives explanations via justification tree • Interpreter keeps track of applied rules. • Can return them together with the model as a trace of the deduction associated with the proof.

madrid institute for advanced studies in software development technologies 12 / 12 THANKS!

www.software.imdea.org

Conclusions

• EC can be naturally and directly encoded in s(CASP). • s(CASP) captures the notion of continuous change in EC: • Thanks to its grounding-free top-down evaluation strategy. • s(CASP) can represent complex models & answer queries: • In a flexible manner. • Thanks to the use of constraints. • s(CASP) gives explanations via justification tree • Interpreter keeps track of applied rules. • Can return them together with the model as a trace of the deduction associated with the proof.

Future Work • Apply the s(CASP) system to solve planning problems: • Generated plans must obey continuous- and real- time constraints. madrid institute for advanced studies in software development technologies 12 / 12 www.software.imdea.org

Conclusions

• EC can be naturally and directly encoded in s(CASP). • s(CASP) captures the notion of continuous change in EC: • Thanks to its grounding-free top-down evaluation strategy. • s(CASP) can represent complex models & answer queries: • In a flexible manner. THANKS! • Thanks to the use of constraints. • s(CASP) gives explanations via justification tree • Interpreter keeps track of applied rules. • Can return them together with the model as a trace of the deduction associated with the proof.

Future Work • Apply the s(CASP) system to solve planning problems: • Generated plans must obey continuous- and real- time constraints. madrid institute for advanced studies in software development technologies 12 / 12 www.software.imdea.org

BibliographyI

Balduccini, M., Magazzeni, D., and Maratea, M. (2016). PDDL+ planning via constraint answer set programming. In 9th Workshop on Answer Set Programming and Other Computing Paradigms. http://arxiv.org/abs/1609.00030. Chittaro, L. and Montanari, A. (1996). Efficient Temporal Reasoning in the Cached Event Calculus. Computational Intelligence, 12:359–382. Clark, K. L. (1978). Negation as Failure. In Gallaire, H. and Minker, J., editors, Logic and Data Bases, pages 293–322. Springer. Fox, M. and Long, D. (2002). PDDL+: Modeling continuous time dependent effects. In Proceedings of the 3rd International NASA Workshop on Planning and Scheduling for Space, volume 4, page 34. Gelfond, M. and Lifschitz, V. (1988). The Stable Model Semantics for Logic Programming. In 5th International Conference on Logic Programming, pages 1070–1080. Gelfond, M. and Lifschitz, V. (1993). Representing Action and Change by Logic Programs. The Journal of Logic Programming, 17(2-4):301–321.

madrid institute for advanced studies in software development technologies 13 / 12 www.software.imdea.org

BibliographyII Lee, J. and Meng, Y. (2013). Answer set programming modulo theories and reasoning about continuous changes. In IJCAI 2013, pages 990–996. Lee, J. and Palla, R. (2012). Reformulating the Situation Calculus and the Event Calculus in the General Theory of Stable Models and in Answer Set Programming. J. of Artif. Intell. Research, 43:571–620. Lee, J. and Palla, R. (2019). F2LP: Computing Answer Sets of First Order Formulas. http://reasoning.eas.asu.edu/f2lp/. Last accessed: Feb. 22, 2019. Mueller, E. T. (2008). Chapter 17: Event calculus. In van Harmelen, F., Lifschitz, V., and Porter, B., editors, Handbook of Knowledge Representation, volume 3 of Foundations of AI, pages 671 – 708. Elsevier. Mueller, E. T. (2014). Commonsense reasoning: an event calculus based approach. Morgan Kaufmann. Mueller, E. T. and Sutcliffe, G. (2005). Reasoning in the Event Calculus Using First-Order Automated Theorem Proving. In Proceedings of the Eighteenth International Florida Artificial Intelligence Research Society Conference, Clearwater Beach, Florida, USA, pages 840–841.

madrid institute for advanced studies in software development technologies 14 / 12 www.software.imdea.org

Bibliography III Robinson, J. A. (1965). A Machine Oriented Logic Based on the Resolution Principle. Journal of the ACM, 12(23):23–41. Shanahan, M. (1999). The Event Calculus Explained. In Artificial Intelligence Today, pages 409–430. Springer. Shanahan, M. (2000). An Abductive Event Calculus Planner. The Journal of Logic Programming, 44(1-3):207–240.

madrid institute for advanced studies in software development technologies 15 / 12