## 4 Incremental Computation: Approach  
Algorithm _Basic_ (Algorithm 1), shown below, provides a very simple, non-incremental method for the calculation trajectories. The algorithm takes as input the pre-determined set of time steps discussed above (i.e., from observations and queries), as well as a set of observations. Program \(\Pi\) used by the algorithm contains the action description and the supporting rules covered earlier. Finally, _Basic_ returns a set of literals that encodes the trajectory that was computed. ```
0:\(p\): pre-determined time steps, e.g., from observations and queries, as facts of the form \(time(t)\)
0:\(O\): a set of observations
0: an answer set
1:\(\tau\gets p\)
2:repeat
3:\(A\gets clingo(\Pi\cup\tau\cup O)\)\(\triangleright\) assumption: clingo() finds a single answer set
4:\(\tau\leftarrow\tau\cup\{time(t^{\prime}).\ |\ newtime(t,t^{\prime})\in A\}\)
5:until\(\{t^{\prime}\ |\ newtime(t,t^{\prime})\in A\}=\emptyset\)
6:return A
```  
**Algorithm 1** Algorithm _Basic_  
In spite of its non-incremental nature, in that the solver is executed multiple times without reusing any knowledge from the prior runs, the algorithm succeeds in making it possible to extend the timeline as needed, based on the information provided by the rules of (10), and to only introduce the time steps that are critical for capturing the evolution of the domain. While more efficient than naive approaches, Algorithm 1 involves redundant computations: at every call to the solver, the state of the domain at all time steps from \(\mathcal{T}\) is computed from scratch. In order to leverage incremental computations, we adopt an approach in which we recompute the state of the domain only for the time steps that are newly introduced. For this purpose, the ASP program is separated into modules:  
* Module _base_, which contains the rules that are time-independent, such as rules defining class hierarchies and domain predicates;Module _time-dependent_, which contains the rules that are time-dependent and should be evaluated incrementally, such as the rules from (10);
* Module _output_, which contains any rules that are time-dependent and should be evaluated at the end of the entire computation, i.e., for the purpose of producing output suitable by user interfaces. The _base_ and _output_ modules are declared using directives #_program base_ and #_program output_, respectively. The _time-dependent_ module is declared by the directives:  
\[ \begin{array}{l}\#program\;timedep(t).\\ \#external\;enabled(T)\;:\;time(T),\;T\geq t.\end{array}  \tag{15}\]  
where \(t\) is the module's parameter. Parameter \(t\) represents the time step starting from which the state of the domain must be computed. This enables a detailed control on the parts of the timeline on which the computation occurs. In order to make this possible, all rules of _time-dependent_ must include special conditions that make it possible to control when they should be applied and when they should be retracted. With one exception, discussed below, every rule of _time-dependent_ must be extended to include the condition:  
\[enabled(t),\;T\geq t \tag{16}\]  
where \(T\) represents the time step at which the rule is triggered. Intuitively, this condition checks that the time step \(T\) considered by the solver in the grounding of the rule is part of the fragment of the timeline on which the computation is being performed. For example, the rules of the form (10) are modified as follows:  
\[ \begin{array}{l}h(f,T)\leftarrow\Gamma(T),\;enabled(T),\;T\geq t.\\ left(f,d,T)\leftarrow\Gamma(T),\;enabled(T),\;T\geq t.\\ newtime(T,T+d)\leftarrow\Gamma(T),\;enabled(T),\;T\geq t.\end{array}  \tag{17}\]  
Note that the inertia axioms and the rules that capture the semantics of durative fluents are modified in a similar way. The rule defining \(next/2\) is extended in a slightly different way, as follows:  
\[ \begin{array}{l}next(T,T^{\prime})\leftarrow\\ time(T),\\ T^{\prime}=\#min\{S\;:\;time(S),\;S>T\},\\ enabled(T^{\prime}),\;T^{\prime}\geq t.\end{array}