2.1 Answer set programming

A (disjunctive) program $\Pi$ in ASP is a set of rules $r$ of the form:

\begin{equation*}a_1;\ldots ;a_m \;{:}{-}\; a_{m+1}, \ldots, a_n, \;not \; a_{n+1},\ldots, \; not \; a_{o}.\end{equation*}

where each atom $a_i$ is of the form: $p(t_1,\ldots, t_k)$, $p$ is a predicate symbol of arity $k$ and $t_1,\ldots, t_k$ are terms built using constants and variables. For predicates with arity $k{=}0$, we will omit the parenthesis. A naf (negation as failure) literal is of the form $a$ or $not\; a$ for an atom $a$. A rule is called fact if $m{=}1$ and $o{=}0$, normal if $m{=}1$ and integrity constraint if $m{=}0$. Each rule can be split into a head $h(r)=\{a_1,\ldots, a_m\}$ and a body $B(r)=\{a_{m+1},\ldots, not\;a_o\}$, which divides into a positive part $B^+(r) = \{a_{m+1},\dots, a_n\}$ and a negative part $B^-(r) = \{a_{n+1},\dots, a_o\}$. An expression (i.e. term, atom, rule, program, …) is said to be ground if it does not contain variables. Let $M$ be a set of ground atoms, for a ground rule $r$ we say that $M \models r$ iff $M \cap h(r) \neq \emptyset$ whenever $B^+(r)\subseteq M$ and $B^-(r)\cap M = \emptyset$. $M$ is a model of $\mathcal{P}$ if $M \models r$ for each $r \in \mathcal{P}$. $M$ is a stable model (also called answer set) iff $M$ is a $\subseteq$-minimal model of the Gelfond-Lifschitz reduct of $\mathcal{P}$ w.r.t. $M$. The reduct is defined as $\mathcal{P}^M = \{h(r) \gets{} B^+(r) |M \cap B^-(r) = \emptyset, r \in \mathcal{P} \}$ (Gelfond and Lifschitz, Reference Gelfond and Lifschitz1988).

To ease ASP programming, several language extensions such as conditional literals, cardinality constraints, and optimization statements were introduced (Calimeri et al., Reference Calimeri, Faber, Gebser, Ianni, Kaminski, Krennwallner, Leone, Maratea, Ricca and Schaub2019). Conditional literals are of the form $a{:}b_1,\ldots, b_m$ with naf-literals $a$ and $b_i$. They allow the conditional inclusion of atoms $a$ for condition $b_1,\ldots, b_m$ and are especially useful in combination with variables. Cardinality constraints introduce compact counting of atoms with an upper bound $s$ and lower bound $t$. They are of the form $s\{d1;\ldots;dn\}t$ with conditional literals $d_i$. Optimization statements of the form #$\texttt{minimize}\{w_{1}@p_{1}, t_{1}:c_{1};\ldots;w_{n}@p_{n}; t_{n}:c_{n}\}.$ aim to minimize the sum over $w_i$ over a set of weighted tuples $(w_i,t_i)$ for priority level $p_i$ (default level $0$) under the condition $c_i$. Additionally, the program clingo offers several extensions as well, such as ranges l..u, indicating any integer between l and u, including both.

2.2 Multi-shot ASP in clingo

clingo provides an API (Gebser et al., Reference Gebser, Kaminski, Kaufmann and Schaub2019b) to access the functionality of an ASP program within an imperative language such as python. The standard procedure is to create a clingo control object in the wrapper program, assign one or more logic program inputs, ground it, and solve it. This setup allows to alter and repeatedly run logic programs (multi-shot).

Besides basic functionality, the clingo control object provides access to several mechanics connected to the logic program. Parametrized subprograms allow grounding of rules with values of constants determined at runtime, enabling flexible data management. The solving is initialized via a solve call. The corresponding function accepts attributes to influence the execution of the solving, such as assumptions. Assumptions are a list of atom/truth value pairs, which state valid mappings for the current solve call. Another mechanic to influence truth values of atoms are externals. They are declared in the form #$\texttt{external } a{:}b_1,\ldots, b_m \texttt{.}$ with conditional literal $a{:}b_1,\ldots, b_m$ within the logic program. An atom marked as external has a fixed truth value similar to a fact, except that in between solve calls the actual value can be changed via the function assign_external. It is even possible to remove an external permanently by releasing it.

Next to assumptions and externals, there is also the possibility to directly influence the ongoing search for models. During the solve call, truth values can be assigned to (negated) conjunctions of atoms (clauses and nogoods). In clingo this functionality is accessible by either implementing a custom propagator or indirectly through the context of a model object. The model object can be obtained by providing a callback model handling function to the solve call.

2.3 Graphs, paths, and Hamiltonian cycles

A grid graph $G(n,m)$ is an undirected graph formed by a rectangular grid of vertices (Itai et al., Reference Itai, Papadimitriou and Szwarcfiter1982). The grid consists of $n$ rows and $m$ columns, denoted as $G(n,m) = (V, E)$, where $V$ represents the set of vertices with $|V|=n{\cdot }m$ and $E\subseteq V{\times }V$ represents the set of edges. Each vertex $v(x,y)\in{}V$ corresponds to an intersection of a column $x$ and a row $y$, and each edge in $E$ connects adjacent vertices in the horizontal or vertical direction.

A path p within a grid graph $(V, E)$ is a sequence of adjacent vertices $v_1, \dots, v_{n}$ denoted as list $[v_1, \dots, v_{n}]$, with $\textit{p}{}_i = v_i$ and $|\textit{p}{}|=n$, such that for every $i \in \{2, \ldots, n\}$ there exists an edge $(v_{i-1}, v_i) \in E$. A subpath $\textit{p}{}'$ of p covers a subsequence of vertices such that there exists a $c \in \mathbb{N}$, for which every $\textit{p}{}'_i$ equals $\textit{p}{}_{i{+}c}$.

A Hamiltonian cycle (HC) (Itai et al., Reference Itai, Papadimitriou and Szwarcfiter1982) in a grid graph $G(n,m)=(V, E)$ is a path $\textit{p}{}$ of distinct vertices such that $(p_{n\cdot{}m}, p_1) \in E$. Therefore, an HC is a cycle that passes through every vertex of the graph without repetition, following the adjacent edges of the grid structure. Only grid graphs with even numbers of vertices admit an HC (Itai et al., Reference Itai, Papadimitriou and Szwarcfiter1982).

2.4 Snake game

The game snake is a classic arcade game, where the user steers a snake’s head on a grid similar to a grid graph of dimension $n{\times }m$. The snake can be interpreted as a list of grid coordinates, for example =[(6.2), (5.2), (4.2), (4.3), (3.3)] for Figure 1b starting with the tail and ending with the head. Possible movements for the head are left, right, up, and down to reach adjacent fields on the grid. The snake body follows the head movement, meaning starting with after one step the new snakes ′ body elements _i-1 now equal _i as illustrated in Figure 1(b) and (c).

Fig 1. Examples for a snake on a $6\times{}6$ grid generated by our software. The snake head is marked with eyes.

A snake can increase its length by placing the head on a tile occupied by an apple with coordinates , leading for the extended snake ′ to occupy the fields as illustrated in Figure 1(d) and (e). Now the apple is consumed and another apple appears on a random, unoccupied field. The game starts with a snake of length one in the corner of the grid and one apple on a random, unoccupied field as indicated in Figure 1(a). The maximal length of a snake is $n{\cdot }m$, since the snake fills all the fields and no apple can be placed, preventing any future growth of the snake as shown in Figure 1(e). The game terminates if the head lands on a field of the body, leaves the grid, or the snake reached its maximal length. For the latter the game is considered won.

3.1 Problem description for iterations

One snake game consists of $n{\cdot }m{-}2$ iterations of searching a path from a given snake to a given apple for given grid dimensions $n{\times }m$. Therefore, we can formalize a problem description for one iteration.

General Snake. Given a path , a goal vertex on a grid graph $G(n,m)$, derive a path , such that iff $a=|\textit{p}{}|$ and for every $1{\leq }j{\lt }k{\lt }|\textit{p}{}|$ with $\textit{p}{}_j = \textit{p}{}_k$, then

General Snake has three key points: the path has to start with , the vertex appears exactly once at the end and if a vertex repeats, enough steps lie between repetitions for the snake to move out of the way. General Snake covers all possible solutions for one iteration of snake.

Fig 2. Examples for a snake on a $6\times{}6$ grid. Black lines indicate HCs.

While this problem description is sound to solve a single iteration, it does not ensure future iterations to be solvable (compare Figure 1(d) and (e)). To force a game to be won (G1), each field has to be reachable in every iteration. An effective method to enforce reachability in all future iterations is deriving HCs, since the snake will visit each field of the grid before reaching the field currently occupied by its tail. Hence, we define two problems which include HCs as well, where the second is an extension of the first.

Hamiltonian snake (HS). Given a path for a grid graph $G(n,m)$, derive an HC on $G$ starting with subpath .

Minimal Hamiltonian Snake (MHS). Given a path and a goal vertex with for a grid graph $G(n,m)$, derive an HC on $G$ starting with subpath which minimizes $i$ for

An example of the problem and its (minimal) Hamiltonian snake can be seen in Figure 2(a) and (b). Since HCs can only be derived for grid graphs with even numbers of vertices (Itai et al., Reference Itai, Papadimitriou and Szwarcfiter1982), we will handle grids with even number of fields only.

Complexity. HS asks for a solution of an NP problem, putting in the complexity class of nondeterministic polynomial Function Problems (FNP). MHS asks for a solution of an NP problem for which no other solutions with certain properties exist, putting MHS in the complexity class of FNP with NP oracle calls (${FNP}{}^{{NP}{}}$). We decided to define function problems, since strategies (see next paragraph) require actual paths as output.

3.2 Snake strategies

To solve a whole snakes game, we will iteratively solve its $n{\cdot }m{-}2$ HS resp. MHS problems (basic setup). Starting in the first iteration with =[(1.1)], every iteration has a starting snake and random apple coordinates as variable input. From the output path with p_j = we can derive the snake coordinates ′ for the next iteration:

We will now introduce the naive strategy, which aims to finish the game consistently by solving its HS problems. In the first iteration, the naive strategy derives an HC. This path is followed repeatedly, removing the requirement to generate new HCs altogether. This strategy takes on average steps per iteration. The first HC can be derived in polynomial time, by replicating column two and three and row three from Figure 2(b) for arbitrary grid sizes.Footnote ² The number of steps per iteration is bound by the number of fields, consequently putting the naive strategy in polynomial time as well.

The naive strategy aims playing safe (G1). To minimize the total number of steps (G2) we introduce the conservative strategy, which allows the HC to change in between iterations. Hence, we follow the basic setup and solve MHS problems. Solving MHS lies in ${FNP}{}^{{NP}{}}$, which places the conservative strategy in the same complexity class.

Addressing the computation time (G3) we have to discuss and compare different implementations and design choices, which will be covered throughout this publication.

3.3 Multi-shot implementation approaches

By following the conservative strategy, playing snakes boils down to generating HCs efficiently. ASP is well suited for this task, NP-Problems can be easily expressed. Furthermore, snake can be implemented quite space efficient as well: Algorithm1 shows the base logic program for the initial iteration, with head/1 and apple/1 as variable input. field/1 defines the nodes of the grid, connected/2 the edges, next/2 represent the path choices and path/1 ensures a closed cycle. Finally, with mark/1 the path segment between head and apple is marked to be minimized in the last line. In latter iterations, a snake body can be enforced by manipulating corresponding next/2 atoms.

Algorithm 1 base logic program to solve one iteration of snakes

ASP base Algorithm1 can be utilized to iteratively solve snake in different ways. A simple approach is to ground and solve the logical program for each iteration and discard it afterwards (one-shot). However, there are several reasons to reuse a logic program. For instance, time intense grounding or minimal changes can be exploited, especially for iterative progressing problems. There are several approaches to reuse a logic program. Main contribution of this work is a compilation and demonstration of different approaches. Therefore, we will now introduce five different clingo implementations to solve snake. Technically, they will mainly differ in the method to manipulate next/2 atoms.

Algorithm 2 Main Algorithm for iteratively computing snake paths

An outline of the wrapper functionality for multi-shot approaches can be seen in Algorithm2, which implements the conservative strategy. In Lines 1-3 the logic program, and step counter are initialized. The initialization (Line 1) for multi-shot approaches includes grounding apple/1 and head/1 as externals:

#external apple(XY): field(XY).

#external head(XY) : field(XY).

Without these (external) atoms, the optimization statement can not be formulated. In a loop, is picked at random (Line 5) and corresponding external values for the apple position and snake head are set (Lines 6, 7, 9, 10). The main part is represented by he $\textit{retrieve}$ function (Line 8). Here, the values of will be tied to corresponding next/2 atoms from the logic program. Furthermore, the solve process is started and resulting models are managed and converted into paths. The implementation of the retrieve function depends on the approach (see Algorithms3-8). In Line 11, the new snake position is derived from the path. The for loop stops once reached maximal length or no path could be derived.

One-shot. one-shot can be understood as the default approach for logic programs. Here, the current position of the snake and the apple are introduced as facts, resulting in permanently fixing the current values. Each iteration requires grounding and solving a new logic program from scratch. While one-shot sounds rather wasteful (especially in an iterative setting), it comes with clear advantages as well: There is no need to consider mechanics of extending or manipulating logic programs, thus creating a simple, stable, straight forward and easy to debug solution. Therefore one-shot is well suited for fast development projects with easy code maintenance or noncritical execution times.

Implementing one-shot uses a similar outline as Algorithm2, with small changes. Line 1 would be moved into the loop before the apple placement. Instead of setting externals (Lines 6, 7, 9, 10), facts are added to the logic program before solving:

The retrieve function for one-shot is outlined in Algorithm3. The function translates into equivalent next atom facts to be added to $\Pi{}$. The program is subsequently solved and the path derived from the model returned. To fit the interface of the multi-shot algorithm, the program $\Pi{}$ is returned as well.

Algorithm 3. retrieve for one-shot

Ad hoc. As for multi-shot implementations, adding and removing rules (Gebser et al., Reference Gebser, Kaminski, Obermeier and Schaub2015, Reference Gebser, Kaminski, Kaufmann and Schaub2019b) will be called the ad hoc variant. Adding rules is comparatively easy, as a program is essentially a set of rules. To disable or remove rules, we utilize external atoms, since their truth values are assigned outside of the logic program. Basically, an external atom is introduced as guard to a temporary rule. Once the external guard is released, the connected rules are released as well. Released externals can not be reused.

We will explain the mechanics through the implementation of the retrieve function from Algorithm4, fitting into Algorithm2. In our case an atom of step/1 is declared to be external (Line 1). Now constraints enforcing the current positions onto next/2 are added with the external as guard (Line 3). The external is set to True (Line 4) and the program solved. To remove the current restrictions on $\Pi{}$, the external is released afterward (Line 6) and $\Pi{}$ is suited to be used in another iteration.

In current literature, usually ad hoc is utilized, since it allows adding of previously unspecified rules and atoms. This comes in handy, especially for logic programs with rising horizons. Therefore ad hoc (along with one-shot) is the most flexible of all approaches. On the downside, expanding a ground logic program may require a deeper understanding of its underlying dependencies, as existing rules need to be compliant with the added rules. Reducing the number of temporary rules (to streamline the solving process) poses another challenge, since its realization usually adds complexity to maintain the code.

Algorithm 4. retrieve for ad hoc; Input: Π, ; Output: Π, path

Preground. In a restricted setting, adding and removing rules might not be a required feature and would result in unnecessary computational overhead. Pregrounding all required temporary rules might improve computation times, reduce complexity of the code and introduces a neat interface between the wrapper program and the logic program. Each temporary rule acquires at least one external predicate in the body to be switched on and off again. Pregrounding does not include the option to add rules on the fly since all possible changes are introduced once in the beginning. Additionally, a vast amount of inactive rules might slow down the program as well. However, preground might perform well on compact programs with lots of iterations, since in comparison to ad hoc no overhead is generated.

Algorithm2 can be extended for preground by adding the following rules to the initial grounding in Line 1:

#$\texttt{external prenext({X},{Y}) : connected({X},{Y}).}$

$\texttt{:- prenext({X},{Y}),{not} next({X},{Y}), connected({X},{Y}).}$

By setting the external prenext/2 to True, we can enforce the corresponding next/2 atom to be True as well. Algorithm5 indicates the functionality of the retrieve function, which boils down to translating the snake into corresponding prenext/2 atoms and temporary activating them before solving.

Algorithm 5. retrieve for preground; Input: Π, ; Output: Π, path

Assume. Instead of handling externals and altering the logic program every time, we can also fix truth values for non-external atoms via assumptions. This option is limited to truth values of atoms, therefore in many cases the introduction of auxiliary rules and atoms is advised, comparable to preground. Assumption atoms do not require to be declared as such and they are provided as a list of atom/truth value assignments to the solve call. In comparison to externals, assumptions are not persistent and have to be formulated for every solve call, which may lead to a less organized setup in comparison to preground. The naming convention should also be considered: names of externals are usually picked for easy access in the wrapper program, whereas assumption require to operate on predefined atom names. Handling atoms with complex terms in clingo can become convoluted quite fast, decreasing the readability of the code. Assume and preground compare in functionality, with preground contributing a simpler interface and assume being more flexible.

The retrieve function for the assume approach is shown in Algorithm6. In clingo assumptions are provided as an attribute to the solve call. Enforcing the position via assumptions does not require any alterations of the logic program.

Algorithm 6. retrieve for assume; Input: Π, Output: Π, path

Nogood. Next to assignments of truth values to (external) atoms, clingo also offers mechanics to influence the search progress. During the search, proven sub-results are stored in form of (negated) conjunctions of literals, which are called clauses and nogoods (Weinzierl, Reference Weinzierl2017). Adding custom nogoods to an ongoing search can be utilized as multi-shot approach. Comparable to assumptions, we are able to assign truth values to not only atoms but clauses during a solve call. The nogood approach therefore can handle rules similar to preground without prior definition, since truth values can be assigned to arbitrary conjunctions of literals. In clingo nogoods require sophisticated knowledge to access: either via a customized propagator or via accessing a model from the solve call. We implemented the latter, which causes the issue of adding constraints after obtaining the initial model. Like this, the first model does not respect the snake placement. This can result in an unobtainable short path, which renders the subsequent optimization futile. However, the system can be steered to generate a predefined model using heuristics as described in the next paragraph.

To manipulate nogoods, a function to process obtained models needs to be assigned in the solve call (here: my_func). The retrieve function boils down to assigning a function for model handling as shown in Algorithm7.

Algorithm 7. retrieve for nogood; Input: Π, ; Output: Π, path

The function my_func has access to the model object during the solve call. It is its only argument. Additional objects can be provided via object oriented programming (Gebser et al., Reference Gebser, Kaminski, Obermeier and Schaub2015). A partial implementation of my_func can be seen in Algorithm8. At first, the function checks if the current model is the first obtained model and compliant with our not yet enforced restrictions. In our implementation, this model is marked with a special atom (dummy). If this is the case, a clause is added to enforce the current snake placement.

Algorithm 8. my_func - code snipped to add as search restriction

To summarize: The nogood approach combines the possible expressivity of preground without the baggage of inactive rules with the flexibility of assumptions. However, access to nogoods requires sophisticated knowledge of the clingo API. If the nogoods are set via the model object, mechanics to enforce a predefined first model might be necessary.

Initial model via heuristics. For the introduced strategies, we can generate one HC from the previous iteration or a generic HC for the first iteration (compare Figure 2(a)). Therefore, we can jump-start the current solve process, guaranteeing at least one model for the optimization in the conservative strategy. We can utilize heuristics (Gebser et al., Reference Gebser, Kaminski, Kaufmann, Lindauer, Ostrowski, Romero, Schaub, Thiele and Wanko2019a) to inject this dummy model within the logic program in clingo:

{dummy}.

#heuristic dummy. [99, true]

#external heur(X,Y) : connected(X,Y).

:- dummy, heur(X,Y), not next(X,Y).

For this, an independent dummy atom is introduced and marked with a high preference to be set to True. Additional external atoms (i.e. $\texttt{heur/2}$) can be preset to influence the actual effect of the $\texttt{dummy}$ atom to the models where it is contained. We are now able to set a dummy model, which benefits computation times and is required to implement the nogood approach via model object.