A parallel memory-efficient epistemic logic program solver: harder, better, faster

Abstract

As the practical use of answer set programming (ASP) has grown with the development of efficient solvers, we expect a growing interest in extensions of ASP as their semantics stabilize and solvers supporting them mature. Epistemic Specifications, which adds modal operators K and M to the language of ASP, is one such extension. We call a program in this language an epistemic logic program (ELP). Solvers have thus far been practical for only the simplest ELPs due to exponential growth of the search space. We describe a solver that, at the time of its development (mid-2016), was able to solve harder problems better (e.g., without exponentially-growing memory needs w.r.t. K and M occurrences) and faster than any other known ELP solver.

Appendices

Appendix A: Comparison to Shen-Eiter Semantics

In this appendix, we compare the (updated) semantics of epistemic logic programs as presented in Section 2 and the semantics of logic programs with epistemic negation as defined by Shen and Eiter in [30]. These semantics can be considered equivalent provided (1) nested expressions of the form not not ℓ are equated to ℓ, and (2) programs are restricted to those expressible using our syntax. We note that ELPs without positive (i.e., non-negated) subjective literals of the form M ℓ are equivalent to their syntactic counterparts under Shen-Eiter semantics since the modal reducts of such programs will not result in nested default negation. Both semantics have the maximality requirement w.r.t. guesses and world views.

For the benefit of the reader, Table 1 summarizes the notational differences between our (KLS) language and that of Shen and Eiter (SE) for different negation/modal operators.

Table 1 Notational differences between KLS and SE

Shen and Eiter call the form notF an epistemic negation where F is a formula. Restricting F to a literal ℓ or a default-negated literal ¬ℓ makes this, after syntactic translation, equivalent to that described in Definition 3.¹

We now compare our definition of the modal reduct (Definition 2) with the epistemic reduct of Shen and Eiter. We start by giving Shen and Eiter’s version, though we refer the reader to [30] for clarification as to what is meant by a logic program with epistemic negation, though for our purposes, it can be viewed informally as simply an ASP program extended with epistemic negations. For ease of discussion, we will assume the notation and terminology (SE or KLS) is clear from the context.

Definition 7

[Epistemic Reduct—Shen-Eiter Version] Let Π be a ground logic program with epistemic negation, E_P(Π ) be the set of epistemic negations in Π, and Φ ⊆ E_P(Π ) be a guess of epistemic negations true in Π. Shen and Eiter define the epistemic reduct Π^Φ of Π w.r.t. Φ as the logic program created from Π such that each occurrence of an epistemic negation of the form notF (where F is a formula) is replaced with either ⊤ (if notF ∈Φ) or ¬F (if notF ∈ E_P(Π ) ∖Φ), where ⊤ denotes a special atom that is always satisfied; thus, ¬⊤ (often denoted as ⊥) is never satisfied.

For comparative purposes, we give below the Shen-Eiter epistemic reduct in the form of a table:

epistemic negation φ	ifφ ∈Φthen...	if φ ∈ EP(Π ) ∖Φ then...
not F	replace notF with ⊤	replace notF with ¬F

Since E_P(Π ) contains all epistemic negations occurring in Π and Φ ⊆ E_P(Π ), we can simplify the table:

epistemic negation φ	ifφ ∈Φthen...	ifφ∉Φthen...
not F	replace notF with ⊤	replace notF with ¬F

Note that these tables apply to occurrences of each epistemic negation φ, regardless of whether or not they are negated. In order to directly translate SE notation to our more limited syntax, F must be restricted to a literal ℓ or default-negated literal ¬ℓ:

epistemic negation φ	ifφ ∈Φthen...	ifφ∉Φthen...
not ℓ	replace notℓ with ⊤	replace notℓ with ¬ℓ
not¬ℓ	replace not¬ℓ with ⊤	replace not¬ℓ with ¬¬ℓ

Through notational translation (see Table 1), we can express this in our syntax as follows:

epistemic negation φ	ifφ ∈Φthen...	ifφ∉Φthen...
not K ℓ	replace not K ℓ with ⊤	replace not K ℓ with not ℓ
M ℓ	replace M ℓ with ⊤	replace M ℓ with not not ℓ

Assuming a corresponding candidate world view W exists² for Φ, we can write this in terms of a modal reduct w.r.t. W where Φ = Φ_W as follows:

subjective literal φ	ifW⊧φthen...	ifW⊮φthen...
not K ℓ	replace not K ℓ with ⊤	replace not K ℓ with not ℓ
M ℓ	replace M ℓ with ⊤	replace M ℓ with not not ℓ

Unlike in Definition 2, the table above applies to occurrences of subjective literals; however, though M ℓ does occur in not M ℓ, it is not the case that not K ℓ occurs in K ℓ. One has to look at the translation of K ℓ to SE notation to see that it is equated to ¬notℓ which, if the notℓ part is translated back to KLS notation, results in not not K ℓ in which not K ℓ does occur.

We prefer a more straightforward approach derived from the fact that not K ℓ and K ℓ are complements, as are M ℓ and not M ℓ. In short, whatever replacement applies to not K ℓ (due to W satisfying or not satisfying it), the complementary replacement (preceded by not) applies to K ℓ. The same is true for M ℓ and not M ℓ, respectively. We can express this with the following table:

subjective literal φ	ifW⊧φthen...	ifW⊮φthen...
not K ℓ	replace not K ℓ with ⊤	replace not K ℓ with not ℓ
K ℓ	replace K ℓ with not not ℓ	replace K ℓ with not⊤
M ℓ	replace M ℓ with ⊤	replace M ℓ with not not ℓ
not M ℓ	replace not M ℓ with not not not ℓ	replace not M ℓ with not⊤

At this point, we will simplify the table by substituting ⊥ for not⊤ (discussed earlier) and not ℓ for not not not ℓ (the standard reduction for nested default negation per [28] and consistent with [30]). We will also reorder the first two subjective literal forms to match the order given in Definition 2:

subjective literal φ	ifW⊧φthen...	ifW⊮φthen...
K ℓ	replace K ℓ with not not ℓ	replace K ℓ with ⊥
not K ℓ	replace not K ℓ with ⊤	replace not K ℓ with not ℓ
M ℓ	replace M ℓ with ⊤	replace M ℓ with not not ℓ
not M ℓ	replace not M ℓ with not ℓ	replace not M ℓ with ⊥

The above table explicitly directs appropriate replacement for each subjective literal form, including when they are default-negated. Since each of these forms represents a conjunct in the body of a rule, the replacement with ⊤ of the (possibly negated) subjective literal is equivalent to its removal from the body of the rule. Likewise, replacement with ⊥ is equivalent to deleting the rule from the program as the rule body can never be satisfied. We thus provide a semantically equivalent table that avoids the use of special atoms ⊤ and ⊥:

subjective literal φ	ifW⊧φthen...	ifW⊮φthen...
K ℓ	replace K ℓ with not not ℓ	delete rule containing K ℓ
not K ℓ	remove not K ℓ	replace not K ℓ with not ℓ
M ℓ	remove M ℓ	replace M ℓ with not not ℓ
not M ℓ	replace not M ℓ with not ℓ	delete rule containing not M ℓ

Comparing the table above with the one from Definition 2, it is clear that they differ only in the replacement for K ℓ when satisfied by W, in which case we replace K ℓ with ℓ. A careful study of Shen and Eiter’s proposed semantics finds that they equate not not ℓ with ℓ (rather than follow the proposed semantics for nested expressions given by Lifschitz, Tang, and Turner in [28]). To faithfully follow Shen and Eiter, we thus simplify the table once more to reflect their choice of semantics for double default negation:

subjective literal φ	ifW⊧φthen...	ifW⊮φthen...
K ℓ	replace K ℓ with ℓ	delete rule containing K ℓ
not K ℓ	remove not K ℓ	replace not K ℓ with not ℓ
M ℓ	remove M ℓ	replace M ℓ with ℓ
not M ℓ	replace not M ℓ with not ℓ	delete rule containing not M ℓ

A comparison with Definition 2 now shows agreement for treatment of K ℓ; however, it is clear that there is a difference in the replacement for M ℓ when not satisfied by W as our version maintains the use of the nested expression not not ℓ and we support its interpretation per [28]. Hence, for programs expressible with our syntax, equatingnot not ℓtoℓin the modal reduct would make the semantics coincide.

The following is an example program (provided by an anonymous reviewer) demonstrating the difference in the two semantics due to different treatment of double default negation.

Example 1

Let Π be the following program (expressed using KLS syntax):

• p ← M p.

• ← K p.

For this program, E_P(Π ) = {M p, not K p}. There are four possible guesses:

• Φ₁ = {M p,not K p}

• Φ₂ = {not K p}

• Φ₃ = {M p}

• Φ₄ = {}

Of these, only the first two will result in consistent programs. Using our semantics (with nested expressions of the form not not ℓ interpreted per [28]), we get the following:

Φ	Π Φ	AS(ΠΦ)	World View?
{M p,not K p}	p.	{{p}}	no
{not K p}	p ←not not p.	{{},{p}}	no

Using Shen-Eiter semantics, we get the following:

Φ	Π Φ	AS(ΠΦ)	World View?
{M p,not K p}	p. ←not⊤.	{{p}}	no
{not K p}	p ← p. ←not⊤.	{{}}	yes

So with our semantics Π has no world view, but with Shen-Eiter semantics {{}} is the world view. Note, however, that if not notp is interpreted as being equivalent to p then $\text {AS}({\Pi }^{{\Phi }_{2}})=\{\{\}\}$ for both with {{}} as the world view.

We provide Example 2a below to demonstrate the difference between our notation and that of Shen and Eiter in [30]. The results are the same under their semantics so far as the epistemic reduct and world view determination are concerned as this was simply a notational translation.

Example 2a

Π in the previous example can be expressed using SE notation as follows:

• p ← not¬p.

• ← ¬notp.

For this program, E_P(Π ) = {not¬p, notp}. There are four possible guesses:

• Φ₁ = {not¬p, notp}

• Φ₂ = {notp}

• Φ₃ = {not¬p}

• Φ₄ = {}

As before, only the first two will result in consistent programs.

Using Shen-Eiter semantics, we get the following:

Φ	Π Φ	AS(ΠΦ)	World View?
{not¬p, notp}	p. ←¬⊤.	{{p}}	no
{notp}	p ← p. ←¬⊤.	{{}}	yes

Appendix B: Programs used to obtain test results

In this appendix, we provide programs that represent those used to compile the test results given in Section 4. Our choice of test programs was guided by a number of considerations including the desire for scalability, coverage of modal operators, a range in number of world views and belief sets, community interest, and ease of validation.

As stated in Section 4, each program used for testing was encoded as an Epistemic Logic Program with Sorts (ELPS). An ELPS adds headers to the base program for specifying various parts of the program signature. As this differs somewhat from that given in the text, we give them here in the syntax presented in Section 2. Note that program comments begin with a percent sign (%) and continue to the end of the line. The actual program files are available from the authors on request.

2.1 B.1: Encoding of the scholarship eligibility problem

The following represents the program elig10 that was used in comparing the performance of ELPsolve with ELPS. This is an example of an eligNN program where NN represents the number of students. As can be seen, this program is easily scaled by adding student data (see Section B.3). The original scholarship eligibility problem was a primary motivation for Gelfond’s proposed extension of disjunctive logic programs in his 1991 seminal work on Epistemic Specifications (see [15]). Due to this, it is included in many papers on the subject (typically with only one student’s data, that of Mike) and has been used in some form as a test case for all known ELP solver implementations. The fact that the world view is easy for a human to determine and does not vary in spite of ELP semantic differences makes this an obvious choice for testing solvers.

For this particular program, there is one world view with 32 belief sets. Each belief set contains the same list of students to be interviewed, represented by the atoms interview(mike), interview(pat), interview(peter), and interview(tom). Additionally, the atoms eligible(mary), eligible(nancy), eligible(paul), eligible(sam), eligible(tim), and ¬eligible(van) are all entailed, providing a solution to the encoded scholarship eligibility problem.

% Scholarship Eligibility Problem

% Core program

eligible(Student):

← highGPA(Student).

eligible(Student):

← fairGPA(Student), minority(Student).

¬eligible(Student):

← ¬highGPA(Student),¬fairGPA(Student).

interview(Student):

← not K eligible(Student), not K ¬eligible(Student).

%Student data

fairGPA(mike) orhighGPA(mike).

fairGPA(mary) orhighGPA(mary).

minority(mary).

highGPA(nancy).

fairGPA(paul).

minority(paul).

fairGPA(pat).

minority(peter) orhighGPA(peter).

fairGPA(sam) orhighGPA(sam).

minority(sam).

highGPA(tim).

¬highGPA(tom).

¬fairGPA(tom) orminority(tom).

¬highGPA(van).

¬fairGPA(van).

minority(van).

2.2 B.2: Encoding of a version of the yale shooting problem

The following represents the program yale3 that was used in comparing the performance of ELPsolve with ELPS. This is an example of a yaleN program where N represents the horizon, which is the number of steps required in a plan to be generated for achieving a specified goal state. In this case, the goal is to kill a turkey (by shooting a gun). The program can be scaled by adding actions/conditions (fluents) for killing the turkey, by changing the initital state, and by assigning a different horizon (see Section B.4). The syntax is extended to include arithmetic terms of the form S+ 1 and built-in binary predicate ≠ using infix notation of the form A1≠A2.

The original Yale shooting problem is credited to Hanks and McDermott who were working at Yale University when they posed the problem in the mid 1980s (see [19]). It has been modified for use as an example conformant planning problem which is the problem of finding a sequence of actions that, if performed, guarantees a goal state as a result. The distinguishing feature of a conformant planning problem is that information about the start state is incomplete, meaning that the start state is only known to be one of a finite number of possible states. Seminal work on conformant planning was done by Smith and Weld (see [31]). The encoding used here is based on that described in [21] and uses a slightly modified version of the epistemic conformant planning module defined therein. Actions are discrete, deterministic, and non-overlapping. As the language of Epistemic Specifications seemed ideal for use in solving conformant planning problems, it was the subject of study for the practical application of ELPs during the period when our solver was being developed. As such, we discovered heuristics applicable to this class of programs that were implemented in ELPsolve.³

For this particular program, there is one world view with two belief sets. Each belief set contains the same sequence of actions 〈 pull_trigger, load, pull_trigger 〉 represented respectively by the atoms occurs(pull_trigger, 0), occurs(load, 1), and occurs(pull_trigger, 2), providing a solution to the encoded conformant planning problem.

• % A Version of the Yale Shooting Problem as an Example Conformant Planning Problem

• % 1A—Core program, part A: Epistemic conformant planning module

• occurs(A, S) ←M occurs(A, S), action(A), step(S).

• ← occurs(A1, S), occurs(A2, S), action(A1), action(A2), A1≠A2, step(S).

• ← goal,not K goal.

• ←not M goal.

• % 1B—Core program, part B: Inertia and awareness axioms

• holds(F, S+ 1) ← holds(F, S),not¬holds(F, S+ 1), fluent(F), step(S).

• ¬holds(F, S+ 1) ←¬holds(F, S),notholds(F, S+ 1), fluent(F), step(S).

• holds(F, 0) or ¬holds(F, 0) ← fluent(F).

• % 2A—Problem domain, part A: Relevant fluents and actions

• fluent(alive). fluent(loaded).

• action(load). action(pull_trigger).

• % 2B—Problem domain, part B: Domain description rules

• ¬holds(alive, S+ 1) ← occurs(pull_trigger, S), holds(loaded, S), step(S).

• ¬holds(loaded, S+ 1) ← occurs(pull_trigger, S), step(S).

• holds(loaded, S+ 1) ← occurs(load, S), step(S).

• % 2C—Problem domain, part C: Executability condition [You can’t load a loaded gun]

• fluent(is_impossible). % Special fluent used to express executability condition

• ¬holds(is_impossible, 0). % Initially false

• holds(is_impossible, S+ 1) ← occurs(load, S), holds(loaded, S), step(S).

• % 3A—Problem instance, part A: Horizon and steps when an action can occur

• horizon(3).

• step(0). step(1). step(2).

• % 3B—Problem instance, part B: Initial state (incomplete) [Turkey is alive, but don’t know if gun is loaded]

• holds(alive, 0).

• % 3C—Problem instance, part C: Goal state [Turkey is dead at horizon]

• goal ←¬holds(alive, S),¬holds(is_impossible, S), horizon(S).

2.3 B.3: Student data used for elig N N programs

The table below lists the student data used in eligNN programs, with the core program as per Section B.1. As can be seen, facts for new students were simply added to scale the program. Student names were made up for test purposes, with associated data varied to assist in checking solver correctness.

2.4 B.4: The yale N programs

Scaling the yaleN programs required a little more imagination than that for the eligNN programs, though we still found it easy to create versions that challenged solver capabilities. The number of epistemic negations in the ground program can be viewed as a measure of the relative difficulty for solving. For these programs, the number of epistemic negations is equal to two plus the product of the horizon and the number of actions.

The core program (parts 1A and 1B of program yale3 in Section B.2) and goal (part 3C) are the same for all. The steps are numbered from 0 to one less than the horizon. We tried to minimize changes to the problem domain (parts 2A, 2B, and 2C), changing only the initial state and horizon when this suited our purposes. Thus, programs yale1, yale2, and yale3 use the same set of fluents and actions. Likewise, programs yale5, yale6, and yale7 share the same fluents and actions. An oversight in coding program yale6 resulted in it having no solution, but we decided to keep it in our test suite as an example of an inconsistent program that is not trivially solved.

In the table below, fluent and action terms are listed for each program, along with fluent truth values for the initial state where a true fluent f is represented in the program as holds(f, 0) and a false fluent ¬f is represented as ¬holds(f, 0). If a fluent is not listed in the initial state, its truth value is unknown. The horizon is understood to be the N value in yaleN. Changes in the problem domain are briefly described in the remarks. We refer the reader to [21] for details on using ELPs for solving conformant planning problems.

Program	Fluents	Actions	Initial State	Remarks
yale1	alive	load	alive
	loaded	pull_trigger	loaded
yale2	alive	load	alive
	loaded	pull_trigger	¬loaded
yale3	alive	load	alive	See Section B.2
	loaded	pull_trigger
yale4	alive	load	alive	Fluent wounded added so that
	loaded	pull_trigger	¬loaded	shooting the turkey only wounds
	wounded		¬wounded	the bird the first time, requiring
				a second shot to finish it off
yale5	aimed	aim	alive	Action aim and fluent aimed
	alive	load	loaded	added so that hitting the turkey
	loaded	pull_trigger	¬wounded	requires aiming just before
	wounded			pulling the trigger (other actions
				will upset the aim)
yale6	aimed	aim	alive	No solution
	alive	load	¬wounded
	loaded	pull_trigger
	wounded
yale7	aimed	aim	alive	Same as yale6 but with horizon
	alive	load	¬wounded	set to 7 which allows for a
	loaded	pull_trigger		solution
	wounded
yale8	aimed	aim	¬aimed	Action cock and fluent cocked
	alive	cock	alive	added so that shooting requires
	cocked	load	¬cocked	the gun to be cocked (you can’t
	loaded	pull_trigger	¬loaded	cock a cocked gun and shooting
	wounded		¬wounded	uncocks the gun)