Merge pull request #105 from plaans/numeric-planning

Various fixes in numeric planning

Author: arbimo

doc/src/resources.md

@@ -16,6 +16,7 @@ The right-hand side of the operator could be either a constant or a variable.
 ### 1.2 Effects
 
 The value of a resource can be :
+
 - changed with an **assignment**, the new value could be either a constant or a variable
 - **increased** by a constant value
 - **decreased** by a constant value, internally it is an increased operation with a negative constant value
@@ -24,55 +25,85 @@ The value of a resource can be :
 
 ### 2.1. Effects
 
-Every time a resource value is updated, new conditions are created in order to check that the value can be updated and that the new value is contained in the bounded domain of the resource.
+Every time a resource value is updated, new constraints or conditions are created in order to check that the value can be updated and that the new value is contained in the bounded domain of the resource.
+
+#### 2.1.1 Assign effects
+
+For an assign effect $[t^a] R^a := z$, we will create the following constraints:
 
-For an **assign effect** $[t^a] R^a := z$, we will create the following conditions:
-$$\begin{cases}
+$$
+\begin{cases}
 [t^a] z \ge l \\
 [t^a] z \le u \\
-\end{cases}$$
+\end{cases}
+$$
 
-For an **increase effect** $[t^i] R^i \mathrel{+}= c$, we will create the following conditions:
-$$\begin{cases}
-[t^i] R^i \le u - c \\
-[t^i] R^i \ge l - c \\
-[t^i+\varepsilon] R^i \le u \\
-[t^i+\varepsilon] R^i \ge l \\
-\end{cases}$$
+#### 2.1.2 Increase effects
 
-For a **decrease effect** $[t^d] R^d \mathrel{-}= c$, we convert it into the increase effect $[t^d] R^d \mathrel{+}= (-c)$ and then create the associated conditions.
+For an increase effect $[t^i] R^i \mathrel{+}= c$, we will create a new variable $v$ with the same domain as the resource and add a new condition $[t^i]R^i = v$.
 
-Next, these conditions are converted into linear constraints as explained in the next section.
+This will ensure that the new value of the resource is in the correct domain after the increase.
+Next, this condition is converted into linear constraints as explained in the next section.
+
+#### 2.1.3 Decrease effects
+
+For a decrease effect $[t^d] R^d \mathrel{-}= c$, we convert it into the increase effect $[t^d] R^d \mathrel{+}= (-c)$ and then create the associated conditions.
 
 ### 2.2. Conditions
 
 Every time a resource must be tested, a set of associated linear constraints are created.
 
-For an **equality condition** $[t^c] R^c = z$, we will have the **linear constraints**
-$$\begin{cases}
-l^a_1c^a_1 + l^i_{11}c^i_1 + \dots + l^i_{1m}c^i_m - z = 0 \\
-\dots \\
-l^a_qc^a_q + l^i_{q1}c^i_1 + \dots + l^i_{qm}c^i_m - z = 0 \\
-\end{cases}$$
-
-Where $l^a_jc^a_j$ represents an assignment to the resource and $l^i_{jk}c^i_k$ represents an increase, the $l$ variables are booleans used to know if the associated $c$ variable (which is the value of the assignment or the increase) should be used. The idea is to consider only the constraint corresponding to the latest assignment. 
-
-To do so, we define $\textit{SP}$ which test if the parameters of two resources are the same, $\textit{SPP}$ which test the presence and the parameters, $\textit{LA}$ which test if the assignment is the last one for the current condition:
-$$\begin{cases}
-\textit{SP}(R^1,R^2) &\Leftrightarrow \bigwedge_{b} (p^1_b=p^2_b) \\
-\textit{SPP}(j, b) &\Leftrightarrow \textit{SP}(R^j,R^b) \land \textit{prez}(j) \land \textit{prez}(b) \\
-\textit{LA}(j) &\Leftrightarrow \bigwedge_{b \ne j} (t^a_b \le t^c \land \textit{SPP}(j,b) \implies t^a_b < t^a_j) \\
-\end{cases}$$
-
-Using these intermediate variables, we obtain
-$$\begin{cases}
-\bigvee_{b} l^a_b \\
-l^a_j \Leftrightarrow t^a_j \le t^c \land \textit{LA}(j) \land \textit{SPP}(j,c) \\
-l^i_{jk} \Leftrightarrow l^a_j \land t^a_j < t^i_k \land t^i_k < t^c \land \textit{SPP}(k,c) \\
-\end{cases}$$
-
-For **others conditions**, we convert them into equality conditions. For example, the condition $[t^c] R^c \le z$ is converted into
-$$\begin{cases}
+#### 2.2.1 Equality conditions
+
+For an equality condition $[t^c] R^c = z$, we will have the **linear constraints**
+
+$$
+\begin{cases}
+l^a_1c^a_1 + l^i_{11}c^i_1 + \dots + l^i_{1n}c^i_n - l^a_1z = 0 \\
+\vdots \\
+l^a_kc^a_k + l^i_{k1}c^i_1 + \dots + l^i_{kn}c^i_n - l^a_kz = 0 \\
+\end{cases}
+$$
+
+Where $l^a_jc^a_j$ represents an assignment to the resource and $l^i_{jm}c^i_m$ represents an increase, the $l$ variables are boolean literals used to know if the associated $c$ variable (which is the value of the effect) should be used.
+The idea is to consider only the constraint corresponding to the latest assignment.
+
+To do so, we define $\textit{SP}$ which test if the parameters of two resources are the same by:
+
+$$\textit{SP}(x,y) \Leftrightarrow \bigwedge_{b} (p^x_b=p^y_b)$$
+
+We also define $\textit{LA}$ which test if the assignment effect is the last one before the condition.
+**There are two ways to define it**.
+The **first** one is to check that the effect is before the condition and for other compatible assignment effects, check that they are not between the considering effect and the condition:
+
+$$\textit{LA}(j) \Leftrightarrow t^a_j \le t_c \land \bigwedge_{b \ne j} (\neg \textit{prez}_b \lor \neg\textit{SP}(b,c) \lor t^a_b < t^a_j \lor t^a_b > t^c)$$
+
+The **second** way to define $\textit{LA}$ is to add a fourth time point to the numeric assignment effects.
+Currently, the effects have three time points: the start of the transition, the start of the persistence, and the end of the persistence.
+We add a fourth one, the **end of the assignment**, which holds while the current assignment is the last one.
+This time point is forced to be after or equals to the end of the persistence.
+This way, we just need to check that the condition is between the start of the persistence $t^a_{j,s}$ and the end of the assignment $t^a_{j,e}$:
+
+$$\textit{LA}(j) \Leftrightarrow t^a_{j,s} \le t_c \land t_c \le t^a_{j,e}$$
+
+At the end, the $l^a_j$ literal is true if the effect is present, is the effect before the condition, and has the same resource as the condition:
+
+$$l^a_j \Leftrightarrow \textit{prez}_j \land \textit{LA}(j) \land \textit{SP}(j,c)$$
+
+Moreover, we enforce to have at least one last assignment effect with the disjunction $\bigvee_{j}l^a_j$.
+
+The $l^i_{jm}$ literal is true if the increase $m$ is present with the same resource as the condition, if the assignment $j$ is the last one and if the increase $m$ is between the assignment $j$ and the condition:
+
+$$l^i_{jm} \Leftrightarrow \textit{prez}_m \land \textit{SP}(m,c) \land l^a_j \land t^a_j < t^i_m \land t^i_m \le t_c$$
+
+#### 2.2.2 Others conditions
+
+For others conditions, we convert them into equality conditions.
+For example, the condition $[t^c] R^c \le z$ is converted into
+
+$$
+\begin{cases}
 [t^c] R^c = z' \\
 [t^c] z' \le z
-\end{cases}$$
+\end{cases}
+$$

planning/grpc/server/src/chronicles.rs

@@ -536,18 +536,18 @@ impl<'a> ChronicleFactory<'a> {
         let operation = match kind {
             EffectKind::Assign => EffectOp::Assign(value),
             EffectKind::Increase => {
-                let value = IntCst::try_from(value).context("Increase effect require a constant value.")?;
-                EffectOp::Increase(value)
+                let value = IAtom::try_from(value).context("Increase effect require an integer value.")?;
+                EffectOp::Increase(LinearSum::from(value))
             }
             EffectKind::Decrease => {
-                let value = IntCst::try_from(value).context("Decrease effect require a constant value.")?;
-                EffectOp::Increase(-value)
+                let value = IAtom::try_from(value).context("Decrease effect require an integer value.")?;
+                EffectOp::Increase(-LinearSum::from(value))
             }
         };
         self.chronicle.effects.push(Effect {
             transition_start: span.start,
-            persistence_start: span.end,
-            min_persistence_end: Vec::new(),
+            transition_end: span.end,
+            min_mutex_end: Vec::new(),
             state_var: sv,
             operation,
         });

planning/grpc/server/src/serialize.rs

@@ -127,7 +127,7 @@ pub fn serialize_plan(
     };
 
     // If this is a scheduling problem, interpret all actions as activities
-    // TODO: currently, parameters/variables are not supported.
+    // TODO: currently, variables are not supported.
     let schedule = if _problem_request.scheduling_extension.is_some() {
         let mut schedule = Schedule {
             activities: vec![],
@@ -144,6 +144,22 @@ pub fn serialize_plan(
                 format!("{name}.end"),
                 a.end_time.expect("No end time in scheduling solution").into(),
             );
+            if !a.parameters.is_empty() {
+                // Search for the corresponding activity definition
+                let act = _problem_request
+                    .scheduling_extension
+                    .as_ref()
+                    .expect("Missing scheduling extension")
+                    .activities
+                    .iter()
+                    .find(|a| a.name == name)
+                    .unwrap_or_else(|| panic!("Missing the activity `{}` definition", name));
+
+                // Assign the solution value to each action parameter
+                for (v, p) in a.parameters.iter().zip(&act.parameters) {
+                    schedule.variable_assignments.insert(p.name.clone(), v.clone());
+                }
+            }
             schedule.activities.push(name);
         }
         Some(schedule)