1: \NeedsTeXFormat{LaTeX2e}
2: \documentclass[runningheads]{llncs}
3:
4: \usepackage{amssymb,epsf,psfig}
5: \newcounter{nbr@exemples}
6: \setcounter{nbr@exemples}{0}
7: \newenvironment{exemple}[1]{\begin{example}\textbf{~(#1)}\begin{quote}\begin{small}}{\end{small}\end{quote}\end{example}}
8: \newenvironment{exemple-continu}[1]{\vspace*{0.3cm}\noindent\textit{Example~#1.}\textbf{~(followed)}\begin{quote}\begin{small}}{\end{small}\end{quote}}
9: \def\coins{\textsc{coins}}
10: \def\eg{\emph{eg.}\ }
11: \def\ie{\emph{i.e.}\ }
12: \def\csp{\textsc{csp}}
13:
14: \begin{document}
15: \setcounter{page}{31}
16: \title{{COINS}: a constraint-based interactive solving system}
17: \titlerunning{{COINS}: a constraint-based interactive solving system}
18: \author{Samir Ouis\inst{1} \and Narendra Jussien\inst{1} \and Patrice Boizumault\inst{2}}
19: \authorrunning{S. Ouis, N. Jussien, P. Boizumault}
20: \institute{\'Ecole des Mines de Nantes \\
21: 4, rue Alfred Kastler -- BP 20722 \\
22: F-44307 Nantes Cedex 3 -- France\\
23: \email{\{souis,jussien\}@emn.fr} \\
24: \and
25: GREYC, CNRS UMR 6072 \\ Universit\'e de Caen, Campus 2, \\
26: F-14032 Caen Cedex -- France\\
27: \email{boizu@info.unicaen.fr}}
28:
29: \maketitle
30:
31: \addtocounter{footnote}{1}
32: \footnotetext{In Alexandre Tessier (Ed), proceedings of the 12th International Workshop on Logic Programming Environments (WLPE 2002), July 2002, Copenhagen, Denmark.\\Proceedings of WLPE 2002: \texttt{http://xxx.lanl.gov/html/cs/0207052} (CoRR)}
33:
34: \begin{abstract}
35: This paper describes the \coins\ (COnstraint-based INteractive
36: Solving) system: a conflict-based constraint solver. It helps
37: understanding inconsistencies, simulates constraint additions
38: and/or retractions (without any propagation), determines if a given
39: constraint belongs to a conflict and provides diagnosis tools (\eg
40: why variable $v$ cannot take value $val$). \coins\ also uses
41: user-friendly representation of conflicts and explanations.
42: \end{abstract}
43:
44:
45: \section{Introduction}
46:
47: Constraint programming has been proved extremely successful for
48: modelling and solving combinatorial search problems appearing in
49: fields such as scheduling resource allocation and design. Several
50: languages and systems such as \textsc{chip} \cite{aggoun-chip},
51: \textsc{choco} \cite{laburthe-choco}, \textsc{gnuProlog}
52: \cite{diaz-gnuProlog}, \textsc{Ilog solver} \cite{reference01ilog}
53: have been developed and widely spread. But these systems are
54: helpless when the constraint network to solve has no solution.
55: Indeed, only a \texttt{no solution} message is sent to the user
56: who is left alone to find~: why the problem has no solution;
57: which constraint to relax in order to restore the coherence; etc.
58:
59: These questions yield two different problems: \emph{explaining}
60: inconsistency and \emph{restoring} consistency. Several
61: theoretical answers have been provided to address those questions:
62: \textsc{QuickXPlain} \cite{junker-quickxplain} computes
63: conflicts for configuration problems,
64: \cite{bessiere-dynamic} and \cite{debruyne-dynamic} introduce
65: tools to dynamically remove constraints, \textsc{PaLM}
66: \cite{jussien-palm} uses conflicts to address those issues and
67: define new search algorithms, etc.
68:
69: User interaction requires user-friendly and interactive tools. In
70: this paper, we advocate for the use of \emph{$k$-relevant}
71: explanations \cite{bayardo-complexity} to provide the \coins\
72: (COnstraint-based INteractive Solving) system.
73:
74: \coins\ helps the user understand inconsistency, simulate
75: constraint additions and/or retractions (without any propagation),
76: determine if a given constraint belongs to a conflict and provide
77: diagnosis tools (\eg why variable $v$ cannot take value $val$).
78: \coins\ is based upon the use of conflict sets (\emph{a.k.a.}
79: nogood \cite{schiex-nogood}), explanations
80: \cite{jussien-e-constraints} and their user-friendly
81: representation \cite{jussien-user-friendly}.
82:
83: This paper is organized as follows: we review the definition and
84: generation of conflicts and explanations within constraint
85: programming in section~\ref{explanation}. Then, we introduce
86: $k$-relevance-bounded explanations (section~\ref{sec-k-relevance}) and give an
87: illustrative example (section~\ref{example}). Before illustrating
88: the use of $k$-relevant explanations in the \coins\ system
89: (section~\ref{exploiting}) we present a natural way to provide
90: user-friendly explanations (section~\ref{user-friendly}). Finally,
91: we give a short overview of our implementation.
92:
93: \section{Conflict and explanations for constraint programming}\label{explanation}
94:
95: A \emph{Constraint Satisfaction Problem} (\csp) is defined by a
96: set of variables $V = \{v_1, v_2, \ldots, v_n \}$, their
97: respective value domains $D_1, D_2, \ldots, D_n$ and a set of
98: constraints $C = \{ c_1, c_2, \ldots, c_m \}$. A solution of the
99: \csp\ is an assignment of values to all the variables such that
100: all constraints in $C$ are satisfied. We denote by
101: $\mathbf{sol}(V,C)$ the set of solutions of the \csp\ $(V,C)$.
102:
103: In the following, we consider variables domains as unary
104: constraints. Moreover, the classical enumeration mechanism that is
105: used to explore the search space is handled as a series of
106: constraints additions (value assignments) and retractions
107: (backtracks). Those particular constraints are called
108: \emph{decision constraints}. This rather unusual consideration
109: allow the easy generalization of the concepts that are presented
110: in this paper to any kind of decision constraints (not only
111: assignments but also precedence constraints between tasks for
112: scheduling problems or splitting constraints in numeric \csp, etc.
113: ).
114:
115:
116: \subsection{Definitions}\label{definitions}
117:
118: Let us consider a constraints system whose current state (\ie the
119: original constraint and the set of decisions made so far) is
120: contradictory. A \textbf{conflict set} (\emph{a.k.a.}
121: \textbf{nogood} \cite{schiex-nogood}) is a subset of the current
122: constraints system of the problem that, left alone, leads to a
123: contradiction (no feasible solution contains a nogood). A conflict
124: divides into two parts\footnote{Notice that some special cases may
125: arise. If $k<1$, the considered problem is proved as
126: over-constrained. Some constraints need to get relaxed. If $C' =
127: \emptyset$, the set of decisions that has been taken so far is in
128: itself contradictory. This can happen only if no propagation is
129: done after a decision has been made.}: a subset of the original
130: set of constraints ($C' \subset C$ in equation~\ref{eq-nogood})
131: and a subset of decision constraints introduced so far in the
132: search (here $dc_1, \ldots, dc_k$).
133:
134: \begin{equation} \label{eq-nogood}
135: \mathbf{sol}\left(V,\left(C' \wedge dc_1 \wedge ... \wedge dc_k
136: \right)\right) = \emptyset
137: \end{equation}
138:
139: An operational viewpoint of conflict sets can be made explicit by
140: rewriting equation~\ref{eq-nogood} the following way:
141: \begin{equation} \label{eq-explanation}
142: C' \wedge \left(\bigwedge_{i \in [1..k] \setminus j}dc_i\right)\rightarrow \neg dc_{j}
143: \end{equation}
144:
145: Let us consider $dc_j: v_j = a$ in the previous formula.
146: Equation~\ref{eq-explanation} leads to the following result
147: ($s(v)$ is the value of variable $v$ in the solution $s$):
148:
149: \begin{equation} \label{eq-explanation-rewritten}
150: \forall s \in \mathbf{sol}\left(V,C' \wedge \left(\bigwedge_{i \in [1..k] \setminus j}dc_i
151: \right)\right), s(v_j) \neq a
152: \end{equation}
153:
154: The left hand side of the implication in
155: equation~\ref{eq-explanation} is called an \textbf{eliminating
156: explanation} (explanation for short) because it justifies the
157: removal of value $a$ from the domain $d(v)$ of variable $v$. It is
158: noted: $expl(v \neq a)$.
159:
160: Explanations can be combined to provide new ones. Let us suppose
161: that $dc_1 \lor \ldots \lor dc_j$ is the set of all possible
162: choices for a given decision (set of possible values, set of
163: possible sequences, etc.). If a set of explanations $C'_1
164: \rightarrow \neg dc_1$, ..., $C'_j \rightarrow \neg dc_j$ exists,
165: a new conflict can be derived: $C'_1 \wedge \ldots \wedge C'_j$.
166: This new conflict provides more information than each of the old
167: ones.
168:
169: For example, a conflict can be computed from the empty domain of a
170: variable $v$ (using explanations for each of the removed values):
171: \begin{equation} \label{eq-contradiction}
172: \bigwedge_{a \in d(v)} expl(v \neq a)
173: \end{equation}
174:
175: %Notice that when a conflict set does not contain any decision
176: %constraint, the associated problem is proved to be
177: %over-constrained.
178:
179:
180: \subsection{Storing explanations: $k$-relevance-bounded learning}
181: There generally exists several explanations for the removal of a
182: given value. Several different approaches were introduced to
183: handle that multiplicity. \emph{Dependency Directed
184: Backtracking}\cite{stallman-ddb} records all encountered
185: explanations. The major inconvenience of this approach is its
186: exponential space complexity. Indeed, the number of recorded
187: explanations increases in a monotonous way. Various algorithms
188: only keep a \emph{single} explanation: \emph{Dynamic Backtracking}
189: \cite{ginsberg-dynamic} and its improvements (\emph{MAC-DBT}
190: \cite{jussien-macdbt-cp}, \emph{Generalized Dynamic Backtracking}
191: \cite{bliek-gpb}, \emph{Partial-order Dynamic Backtracking}
192: \cite{ginsberg-gsat}) and \emph{Conflict-directed BackJumping}
193: \cite{prosser-maccbj}. The idea is to forget (erase) explanations
194: which are not valid any more considering the current set of
195: decision constraints. Space complexity therefore remains
196: polynomial while ensuring the completeness of the algorithms.
197: Unfortunately, this idea is not really compatible with debugging:
198: only one explanation is kept and past information are completely
199: lost.
200:
201: Instead of recording only one explanation, a more interesting idea is to
202: keep information as long as a given criterion is verified:
203:
204: \begin{itemize}
205: \item Time-bounded criterion: explanations are forgotten after a
206: given time. This criteria is similar to \emph{tabu} list
207: management in \emph{tabu} search \cite{glover-tabu}.
208:
209:
210: \item Size-bounded criterion: \cite{schiex-nogood-orig} have used
211: a criteria defined in \cite{dechter90}. This criteria keeps only
212: the explanations with a size lower or equal to a given value $n$.
213: This criteria limits the spatial complexity, but may forget really
214: interesting nogoods.
215:
216: \item Relevance-bounded criterion: explanations are kept if they are
217: not \emph{too far} from the current set of decision constraints. This
218: concept (called $k$-relevance) has been introduced in
219: \cite{bayardo-complexity} and focus explanations/conflict
220: management to what is important: relevance \emph{wrt} the current
221: situation.
222: \end{itemize}
223:
224:
225: Time and size-bounded recording do have a controllable space
226: complexity. This is also the case for $k$-relevance learning
227: (\emph{cf.} section~\ref{sec-k-relevance}). As we shall see, our
228: tools are meant for the debugging and the dynamic analysis of programs:
229: the space occupation overhead is well worth it.
230:
231: \section{$k$-relevance-bounded explanations}
232: \label{sec-k-relevance}
233:
234: While solving a constraint problem, the current state of calculus can be
235: described with two sets of constraints: \textbf{$R$ the set of relaxed
236: constraints} (decisions that have been undone during search,
237: constraints that have been explicitly relaxed by the user, etc.)
238: and $A$ the set of active constraints (the current constraint
239: store). $\langle A,R\rangle$ is called a \emph{configuration}.
240: Following \cite{bayardo-complexity}, we can now define a
241: $k$-relevant explanation as:
242:
243: \begin{definition}{$k$-relevant explanation (\cite{bayardo-complexity})}\\
244: Let $\langle A,R\rangle$ a configuration. An explanation $e$ is
245: said to be \textbf{$k$-relevant} if it contains at most $k-1$
246: relaxed constraints, \ie $|e \cap R|<k$.
247: \end{definition}
248:
249: In $k$-relevance-bounded learning, only $k$-relevant explanations
250: are kept during search. Hence, several different explanations may
251: be kept for a given value removal. Thus $expl(v \neq a)$
252: will not contain any more a single explanation but the set of
253: $k$-relevant explanations recorded for the removal of value $a$ from the domain
254: $d(v)$ of variable $v$.
255:
256: %This set is organized according to the relevance of the
257: % explanations. The explanations of the same
258: %degree of relevance will be grouped.
259: % If we take all the $k$-relevant explanations, we will have $k$
260: %subsets. Every subset will be associated to the explanations which
261: %contain $i$ ($i \in [0, k-1] $) relaxed constraints. This subset
262: %will be noted $expl(v \not = a, i) $. More formally ~: $e \in expl
263: %(v \not = a, i) $ if $| e \cap R ¦ = i $ with $R$ the set of
264: %relaxed constraints (i.e $e$ contains $i$ relaxed constraits).
265: %
266: %Thus all the $k$-relevant explanations will be equal
267: %to~: $$expl (v \not = a) = \bigcup _ { i=0 } ^ { i=k-1 } expl (v
268: %\not = has, i) $$
269: %
270: %Clarifying that the explanations of relevance $0$ noted $expl (v
271: %\not = a, 0)$ represent the valid explications.
272:
273: \subsection{Managing $k$-relevant explanations}
274:
275: \subsubsection{Computing $k$-relevant explanations}
276: $k$-relevant explanations, as regular explanations
277: \cite{jussien-e-constraints} can be computed during propagation.
278: However, some issues arise (see example~\ref{ex-issues}).
279:
280: \begin{exemple}{Example for explanation computation}\label{example-computation}
281: \label{ex-issues} Let us consider two variables $v_1$ and $v_2$.
282: Let us assume that value $a$ from $v_1$ is only supported by value
283: $b$ from $v_2$ in constraint $c$. Let finally assume that $b$ is
284: removed from $v_2$ (a set of explanations being: $\{ \{c_1, c_2
285: \}, \{c_1,c_3\}, \{c_4, c_5\}\}$).
286: This removal needs to be
287: propagated.
288:
289: But, which explanation one should choose to compute the
290: explanation of the value removal $v_1 \neq a$ ? Do we have to
291: consider all the possibilities $ \{c, c_1, c_2
292: \}$, $\{c, c_1,c_3\}$ or $\{c, c_4, c_5\}$? Only one ?
293: \end{exemple}
294:
295: As values are removed only once, we can focus on one particular
296: explanation: the first one. The explanation computed at removal
297: time is called the \emph{main} one. That explanation will be used
298: to compute forthcoming explanations. Moreover, this explanation is
299: exactly the one that would have been computed by a classical
300: approach (see section~\ref{definitions}).
301:
302: \begin{exemple-continu}{\ref{ex-issues}}
303: Let us suppose that the \emph{main} explanation for the removal of
304: value $b$ from $v_2$ is $\{c_1, c_2\}$.
305:
306: Thus, the removal $v_1 \neq a$ will be justified by $\{c, c_1,
307: c_2\} $.
308: \end{exemple-continu}
309:
310: \subsubsection{Evolution of the $k$-relevant explanations}
311:
312: We need to maintain the relevance information attached to stored
313: explanations upon constraint additions and retractions. In both
314: ways, the relevance of explanations may vary. The idea is to keep
315: track of these variations and to forget explanations as soon as
316: they become irrelevant. We organize the contents of the
317: $k$-relevant explanations according to the relevance of its
318: explanations. More precisely, all $k$-relevant explanations for a
319: given removal $expl(v \neq a)$ are partitioned into $k$ subsets,
320: \ie\ $expl(v \neq a) = \cup_{i \in [0..k-1]} expl(v \neq a,i)$.
321: Subset $expl(v \neq a, i)$ contains the explanations having $i$
322: relaxed constraints.
323:
324: \begin{exemple}{Updating $2$-relevant explanations}
325: \label{example-2-relevance}
326:
327: Consider example~\ref{example-computation}. We assume that no
328: other explanation has been found for the removal $v_1\not=
329: a$. The $2$-relevant explanations for this removal are~:
330: $expl(v_1 \not= a,0) = \{\{c, c_1, c_2\}, \{c_2,c_4\}\}$,
331: $expl(v_1 \not= a,1) = \{\{c_1, c_3\},\{c_2, c_3\}\}$.
332:
333: Notice that constraint $c_3$ is relaxed. That is why both $\{c_1,
334: c_3\}$ and $\{c_2, c_3\}$ are in the $expl(v_1 \not= a,1)$.
335:
336: \begin{itemize}
337: \item If constraint $c_1$ is relaxed: explanation $\{c, c_1, c_2\}$
338: jumps from $expl(v_1 \not= a, 0)$ to $expl(v_1 \not= a, 1)$;
339: explanation $\{c_1,c_3\}$ is forgotten and thus removed from
340: $expl(v_1 \not= a, 1)$ (we have $k=2$). The new set of
341: $2$-relevant explanations is therefore: $expl(v_1 \not= a,0) = \{
342: \{c_2,c_4\}\}$, $expl(v_1 \not= a,1) = \{\{c, c_1, c_2\}, \{c_2,
343: c_3\} \}$.
344: \item If constraint $c_3$ is reactivated (from the original set of explanations): explanations
345: $\{c_1, c_3\}$ and $\{c_2, c_3\}$ become valid and the new set of
346: $2$-relevant explanations is therefore: $expl(v_1 \not= a,0) = \{
347: \{c, c_1, c_2\}, \{c_2,c_4\}, \{c_1, c_3\},\{c_2, c_3\}\}$,
348: $expl(v_1 \not= a,1) = \{ \}$.
349: \end{itemize}
350: \end{exemple}
351:
352:
353: \subsubsection{Computing conflicts}
354: The same dilemma that we encountered when computing explanations
355: appears when computing conflicts. Indeed, when a contradiction is
356: identified (a domain of a variable becomes empty), we saw that
357: equation~\ref{eq-contradiction} computes a conflict. However,
358: there may exist several explanations for each considered value
359: removal. Contrarily to the explanation computation process, we
360: chose here to provide all possible explanations (limiting
361: ourselves to valid explanations \ie $expl(v \neq a,0)$) for all $i
362: \in [0..k-1]$. The resulting number of valid conflicts is:
363: \begin{equation} \label{eq-all-conflicts}
364: \quad \prod_{a\in d(v)} |expl(v\not= a, 0)| \quad
365: \mathtt{conflicts}
366: \end{equation}
367:
368: \begin{exemple}{The possible nogoods}
369: Let us consider example~\ref{example-2-relevance} but with a
370: different $k$. We assume that values $a$ and $b$ from $v_1$ are
371: have been removed with the following explanations: $expl(v_1 \not=
372: a,0) = \{ \{c, c_1, c_2\}, \{c_2,c_4\}\}$ and $expl(v_1 \not= b,0)
373: = \{ \{c_1, c_5\}, \{c_2,c_5\}\}$.
374:
375: Applying equation~\ref{eq-all-conflicts} leads to the following
376: nogoods:
377: \begin{itemize}
378: \item $\{c, c_1, c_2\} \cup \{c_1, c_5\}$
379: \item $\{c, c_1, c_2\} \cup \{c_2, c_5\}$
380: \item $\{ c_2, c_4\} \cup \{c_1, c_5\}$
381: \item $\{c_2, c_4\} \cup \{c_2, c_5\}$
382: \end{itemize}
383:
384: Here, the \emph{main} explanation for $v_1 \not= a$ is $\{c, c_1,
385: c_2\}$ and $\{c_1, c_5\}$ is the one for $v_1 \not= b$.
386: \end{exemple}
387:
388: %Consequently, it is interesting to choose the good explanations
389: %which will constitute the conflict.
390:
391: \subsection{$1$-relevance \emph{vs.} classical approaches}
392:
393: All classical approaches (\emph{Dynamic Backtracking} or
394: \emph{MAC-DBT}) forget explanations as they become invalid. A
395: $1$-relevant learning technique will obviously proceed the same
396: way. However, it differs from classical approaches by the number
397: of recorded explanations by removal. Indeed, during resolution,
398: one may come across an explanation for an already performed
399: removal. Instead of not taking it into account, $1$-relevance will
400: keep that secondary information\footnote{It will be used to compute conflict. The
401: \emph{main} explanation will still be the only used to compute
402: subsequent explanations.}.
403:
404: Furthermore, all classical approaches take into account only one
405: conflict. This conflict is computed following to
406: equation~\ref{eq-contradiction}. Our approach may deal with a
407: \emph{set} of conflicts (see equation~\ref{eq-all-conflicts}).
408: Nevertheless that particular explanation management has a
409: computational and spatial cost.
410:
411: \subsection{Complexity issues}\label{complexity}
412:
413: To compute the complexity of our approach, let us consider a \csp\
414: defined upon $n$ discrete variables with maximum domain size $d$
415: upon which are posted $e$ constraints. If we only keep a single
416: explanation per value removal, there will be at most $n \times d$
417: explanations of maximal size $e + n$ \ie all the constraints from
418: the problem ($e$) and the decision constraints ($n$). Thus the
419: complexity of the classical approach is $O((e+n) \times n\times d)
420: $.
421:
422: However, as far as the $k$-relevance approach is concerned, an
423: explanation can contain up to $k-1$ relaxed constraints, the
424: maximal size of an explanation being $n + e + k - 1$. The maximum
425: number of explanations for a given value removal is bounded by the
426: maximum number of non included subsets in a set.
427: The worst case is: $\left(\begin{array}{c} { e+n+k-1 } \\
428: {(e+n+k-1)/2} \end{array}\right)$ subsets of size $(e+n+k-1)/2$.
429:
430: Therefore, the spatial complexity for storing $k$-relevance
431: explanations is in: $$O\left(n\times d \times \left(\begin{array}{c} { e+n+k-1 } \\
432: {(e+n+k-1)/2} \end{array}\right) \times (e+n+k-1)/2\right)$$
433:
434:
435: \section{An example~: the conference problem} \label{example}
436: To illustrate the use of the $k$-relevant explanations, we present
437: the resolution of the conference problem
438: \cite{jussien-implementing-lncs}. From now on, we fill focus our
439: study to $1$-relevance.
440:
441: %\emph{In the section~\ref{contribution} we whill show how our
442: %system \textbf{COINS} uses these explanations to provide an
443: %interactive help for the resolution of an over-constrained
444: %problem.}
445:
446: %To show the interest of our approach we focus our study to
447: %$1$-relevance in the rest of the paper.
448:
449: \subsection{Presentation of the problem}\label{problem-conference}
450:
451: Michael, Peter and Alan are organizing a two-day seminar for
452: writing a report on their work. In order to be efficient, Peter
453: and Alan need to present their work to Michael and Michael needs
454: to present his work to Alan and Peter (actually Peter and Alan
455: work in the same lab). Those presentations are scheduled for a
456: whole half-day each. Michael wants to known what Peter and Alan
457: have done before presenting his own work. Moreover, Michael would
458: prefer not to come the afternoon of the second day because he has
459: got a very long ride home. Finally, Michael would really prefer
460: not to present his work to Peter and Alan at the same time.
461:
462:
463:
464:
465: \subsection{A constraint model for the conference problem} \label{conf-model}
466: A constraint model for that problem is described as follows~: let
467: $Ma, Mp, Am, Pm$ the variables representing four presentations
468: ($M$ and $m$ are respectively for Michael as a speaker and as an
469: auditor). There domain will be $[1,2,3,4]$ ($1$ is for the morning
470: of the first day and $4$ for the afternoon of the second day).
471: Several constraints are contained in the problem: implicit
472: constraints regarding the organization of presentations and the
473: constraints expressed by Michael.
474:
475: The implicit constraints can be stated:
476: \begin{itemize}
477: \item A speaker cannot be an auditor in the same half-day. This
478: constraint is modelled as: $c_1: Ma \neq Am$, $c_2: Mp \neq Pm$,
479: $c_3: Ma \neq Pm$ and $c_4: Mp \neq Am$.
480: \item No one can attend two presentations at the same time. This
481: is modelled as $c_5: Am \neq Pm$.
482: \end{itemize}
483:
484: Michael constraints can be modelled:
485: \begin{itemize}
486: \item Michael wants to speak after Peter and Alan: $c_6: Ma > Am$,
487: $c_7: Ma > Pm$, $c_8: Mp > Am$ and $c_9: Mp > Pm$.
488: \item Michael does not want to come on the fourth half-day: $c_{10}: Ma \neq 4$,
489: $c_{11}: Mp \neq 4$, $c_{12}: Am \neq 4$ and $c_{13}: Pm \neq 4$.
490: \item Michael does not want to present to Peter and Alan at the
491: same time: $c_{14}: Ma \neq Mp$.
492: \end{itemize}
493:
494:
495:
496:
497: \subsection{Using classical approaches}
498: Table~\ref{DomainePalmenum} shows the resulting explanations for
499: both approaches (classical and $1$-relevant) after adding
500: constraints from $C_1$ to $C_6$.
501: %
502: %
503: %summarizes the treatment of the added constraints ($C_1$ to $C6$)
504: %as well as the computation of the explanations according to both
505: %approaches, classical and the $1$-relevant.
506: The column associated to the classical approach contains only a
507: single explanation by removal, opposed to the $1$-relevant column.
508: The domain of the variable $P_m$ is empty. We deduce that our
509: problem is over-constrained. According to the
510: equation~\ref{eq-contradiction} of the section~\ref{explanation},
511: we obtain the conflict $\{C_1, C_2, C_3, C_4, C_5, C_6\}$.
512:
513: \begin{table}[htpb]
514: \begin{center}
515: \leavevmode
516:
517: \begin{tabular}{|ccccc|} \hline
518: Variable & Value & Explanation & $1$-relevance & present~? \\ \hline
519: $P_m$ & $1$ & $\{C_1,C_2,C_4,C_6\}$ & $\{C_1,C_2,C_4,C_6\},\{C_1,C_4,C_6\} $ & no \\
520: $P_m$ & $2$ & $\{C_5,C_6\} $&$\{C_5,C_6\} $ & no \\
521: $P_m$ & $3$ & $\{C_5,C_6\} $ & $\{C_5,C_6\} $ &no \\
522: $P_m$ & $4$ & $\{C_3\} $ &$\{C_3\},\{C_5\},\{C_5,C_6\} $ &no \\ \hline
523: $A_m $ & $1$ & $\emptyset $ & $\emptyset $ &\textbf{yes} \\
524: $A_m $ & $2$ & $\{C_4,C_6\} $ & $\{C_4,C_6\} $ &no \\
525: $A_m $ & $3$ & $\{C_4,C_6\} $ & $\{C_4,C_6\} $ &no \\
526: $A_m $ & $4$ & $\{C_2\} $ & $\{C_2\},\{C_4\},\{C_4,C_6\} $ &no \\ \hline
527: $M_p$ & $1$ & $\{C_4\} $ & $\{C_4\},\{C_5\},\{C_6\} $ &no \\
528: $M_p$ & $2$ & $\emptyset $ & $\emptyset $ &\textbf{yes} \\
529: $M_p$ & $3$ & $\{C_6\} $ &$\{C_6\} $ &no \\
530: $M_p$ & $4$ & $\{C_6\} $ & $\{C_6\} $ &no \\ \hline
531: $M_a $ & $1$ & $\{C_2\} $ &$\{C_2\},\{C_3\} $ &no \\
532: $M_a $ & $2$ & $\emptyset $ & $\emptyset $ &\textbf{yes} \\
533: $M_a $ & $3$ & $\emptyset $ & $\emptyset $ &\textbf{yes} \\
534: $M_a $ & $4$ & $\emptyset $ & $\emptyset $ &\textbf{yes} \\ \hline
535: \end{tabular}
536:
537: \caption{Domains after the introduction of constraints}
538: \label{DomainePalmenum}
539: \end{center}
540: \end{table}
541:
542:
543: \subsection{Solving using $1$-relevant explanations}
544: %\fbox{Samir} \texttt{V\'{e}rifier coh\'{e}rence par rapport \`{a} la
545: %diff\'{e}rence entre $1$-relevance et approches classiques}
546:
547: Table~\ref{DomaineKrelevance} presents the $1$-relevant
548: explanations associated to every removal after we have
549: removed the redundant explanations like $\{C_5,C_6\}$ for the
550: removal $P_m \not= 4$. But as the second approach proposes several
551: explanations, we can deduce several conflicts. In our case, we
552: obtain two conflicts~: $\{C_1, C_3, C_4, C_5, C_6\}$ and $\{C_1,
553: C_4, C_5, C_6\}$.
554:
555: The second conflict is more precise since it is included in the
556: first one. There is a quite important difference between the
557: conflict provided by the first approach which contains all the
558: constraints that do not help the user and the conflicts provided
559: by the $1$-relevant approach.
560:
561: \begin{table}[[htpb]
562: \begin{center}
563: \leavevmode
564:
565: \begin{tabular}{|ccccc|} \hline
566: Variable & Value & Explanation & $1$-relevance & present~? \\ \hline
567: $P_m$ & $1$ & $\{C_1,C_2,C_4,C_6\}$ &$\{C_1,C_4,C_6\} $ & no \\
568: $P_m$ & $2$ &$\{C_5,C_6\} $ &$\{C_5,C_6\} $ & no \\
569: $P_m$ & $3$ & $\{C_5,C_6\} $ &$\{C_5,C_6\} $ & no \\
570: $P_m$ & $4$ & $\{C_3\} $ &$\{C_3\},\{C_5\} $ & no \\ \hline
571: $A_m $ & $1$ &$\emptyset $ &$\emptyset $ & \textbf{yes} \\
572: $A_m $ & $2$ &$\{C_4,C_6\} $ &$\{C_4,C_6\} $ & no \\
573: $A_m $ & $3$ & $\{C_4,C_6\} $ &$\{C_4,C_6\} $ & no \\
574: $A_m $ & $4$ & $\{C_2\} $ &$\{C_2\},\{C_4\} $ & no \\ \hline
575: $M_p$ & $1$ & $\{C_4\} $ &$\{C_4\},\{C_5\},\{C_6\} $ & no \\
576: $M_p$ & $2$ & $\emptyset $ &$\emptyset $ & \textbf{yes} \\
577: $M_p$ & $3$ & $\{C_6\} $ &$\{C_6\} $ & no \\
578: $M_p$ & $4$ & $\{C_6\} $ &$\{C_6\} $ & no \\ \hline
579: $M_a $ & $1$ & $\{C_2\} $ &$\{C_2\},\{C_3\} $ & no \\
580: $M_a $ & $2$ & $\emptyset $ &$\emptyset $ & \textbf{yes} \\
581: $M_a $ & $3$ & $\emptyset $ &$\emptyset $ & \textbf{yes} \\
582: $M_a $ & $4$ & $\emptyset $ &$\emptyset $ & \textbf{yes} \\ \hline
583: \end{tabular}
584:
585:
586: \caption{Final set of explanations }
587: \label{DomaineKrelevance}
588: \end{center}
589: \end{table}
590:
591:
592:
593: \subsection{User interaction}
594:
595: As we can see in our example, conflicts and explanations are sets
596: of low-level constraints. Only a specialist can understand and
597: correctly interpret the provided information. In order to design
598: user interaction tools, we therefore need to provide
599: \emph{translation} tools to make accessible to any user the
600: low-level constraints. In the next section, we introduce
601: user-friendly explanations to address that issue.
602:
603:
604: \section{User-friendly explanations} \label{user-friendly}
605:
606: In this section, we introduce the notion of user-friendly
607: explanations \cite{jussien-user-friendly}. We provide a set of
608: tools to address the accessibility issue of conflicts and
609: explanations made of low-level constraints. %The main idea is to
610: %consider constraints programs as an hierarchy of constraints and
611: %to add information about that hierarchy within the constraints.
612: %\fbox{Samir} \texttt{R\'{e}sumer en deux pages maximum le papier user-friendly}.
613:
614: %\subsection{The problem and our solution}
615: A solution to that issue will be obtained thanks to the developer
616: of the application. When developing an application, such an expert
617: needs to \emph{translate} the problem from the high level
618: representation (the user's comprehension of the problem) to the
619: low-level representation (the actual constraints in the system).
620: We note this translation a \texttt{user} $\rightarrow$
621: \texttt{system} translation.
622:
623:
624: For user-friendly explanations, we need the other way
625: \emph{translation}: from the low-level constraints (solver
626: adapted) to the user comprehensible constraints (higher level of
627: abstraction). We note this translation a \texttt{system}
628: $\rightarrow$ \texttt{user} translation. That translation is
629: usually not explicitly coded in the system. Asking a developer to
630: provide such a translator while coding would be quite strange for
631: him. We chose to automatize that translation in a transparent way.
632:
633:
634:
635: %\texttt{reprendre intro et dans les premiers paragraphes}
636: \subsection{Hierarchical representation of problems}
637: This idea relies on a single hypothesis: all aspects of a
638: constraint-based application can be represented in a hierarchical
639: way. Indeed, any object appearing in a constraint problem is
640: attached to at most a single \emph{father-}object. Note that a
641: given \emph{father-}object may have several
642: \emph{children-}objects. For example, figure~\ref{fig-conference}
643: gives a graphical representation of the problem defined in
644: section~\ref{problem-conference}.
645:
646: \begin{figure}[hbtp]
647: \begin{center}
648: ~\hspace{1.8cm}
649: \epsfbox{conference-diagram.ps}
650: ~\vspace{-23cm}
651: \end{center}
652: \caption{An hierarchical view of the conference problem} \label{fig-conference}
653: \end{figure}
654:
655:
656: \subsection{Building a \texttt{system} $\rightarrow$ \texttt{user} translator}
657:
658: While developing a constraint application, the user only
659: needs to explicitly state the underlying hierarchy of his problem.
660: Only the leaves of this structure, namely the low-level
661: constraints, can be used by the constraint solver.
662:
663: The leaves may be too low-level for a typical user of the final
664: application. However, he can understand higher levels in the
665: hierarchy. What allows the hierarchy hypothesis is to build with
666: no effort for the developer a hierarchical representation of the
667: problem. Once built, this representation can be used to interact
668: with any user through user-friendly explanations. Such
669: explanations are provided using procedures converting low-level
670: constraints into user understandable pieces of the hierarchy.
671: Those procedures are completely problem independent and may be
672: provided within the constraint solver.
673:
674: The user perception of a given problem can be seen as a \emph{cut}
675: in the hierarchical view of the considered problem. For example,
676: let suppose that the user is Michael who does not want to deal
677: with implicit constraints. Although he does understand his own
678: wishes. Therefore, his view of the problem would be: \fbox{The
679: conf. problem}, \fbox{P\&A before}, \fbox{Not 4$^{th}$ $1/2$ day}
680: and \fbox{P\&A not same time}.
681:
682: Our example has no solution, one explanation for that situation
683: provided by a classical approach is: $\{c_1, c_2, c_3, c_4, c_5,
684: c_6\}$.
685:
686: Michael looks at the explanation from his point of view. We
687: therefore need to project the concrete explanation onto his
688: representation. The projection consists in projecting the
689: constraints $\{c_1, c_2, c_3, c_4, c_5, c_6\}$ from bottom to the
690: top of the hierarchy representing the problem (see
691: figure~\ref{fig-conference}) until a user understandable box is
692: reached.
693:
694: For example, the projection of the constraints $\{c_1, c_2, c_3,
695: c_4\} $ gives in first step the \fbox{Speaker vs. Auditor} box.
696: Unfortunately, this box is not understandable by Michael. In this
697: case, the projection continues to the father box: \fbox {Implicit
698: constraints}. Once again, this box is not understandable by
699: Michael and the projection gets to \fbox {The conf. problem}.
700: Finally, we reached \fbox{The conf. problem} box which Michael can
701: deal with. The projection of $c_5$ gives the same box through
702: \fbox{Auditor vs. 2 pers.} and \fbox{Implicit constraints}. For
703: $c_6$, the projection is easier because the first reached box is
704: user understandable.
705:
706: The final projection gives: \fbox{The conf. problem} and \fbox{P\&A
707: before}. He can ask to discard one box. For example, the box
708: \emph{Michael wants to speak after Peter and Alan}.
709:
710:
711: %\texttt{Repr\'{e}sentation de l'utilisateur comme une coupe,
712: %projection, un petit exemple -- sch\'{e}ma}
713:
714: \section{Exploiting $k$-relevant explanations} \label{exploiting}
715:
716: $k$-relevance provides more interesting explanations and allows to
717: obtain a better diagnosis. In this section, we present five
718: concrete situations which the user is frequently confronted in the
719: case of a failure. We show how $k$-relevant explanations allow
720: to better understand and to analyze this failure and to quickly
721: simulate various scenarios.
722:
723:
724:
725: %\texttt{Faire un mini-plan (itemize) de ce dont on va parler dans cette section}
726:
727: \subsection{Giving more precise explanations}
728:
729: %\texttt{pas de d\'{e}finition formelle ... faire du texte}
730: %\texttt{revoir l'anglais}
731:
732: %\begin{definition}{(More precise explanations )}
733: % Let $e_1$ and $e_2$ be two explanationsof the removal $v \not= a$. $e_1$ is more precise than $e_2$ if and only if $ e_1 \subsetneq e_2$ (because let suppose $c \in e_1 - e_2$, we know that the relaxation of $c$ does not put back the value $a$ in the domain of $v$. So, the configuration $<A-{c},R\cup{c}>$ remains incoherent.
734: %\end{definition}
735:
736: If we have two explanations for the same removal $e_1$ and $e_2$
737: such as $e_1 \subsetneq e_2$, then we know that the constraints
738: which belong to $e_2 \setminus e_1$ are not responsible for the
739: removal. We say that $e_1$ is more precise than $e_2$.
740:
741: %So, precise explanations lead to precise conflict sets. Also, from
742: %such explanations, we can check if a constraint is really
743: %responsible for the removal of a value. For example, the removal
744: %$Pm \not = 1$ is justified by two explanations within the
745: %$1$-relevant approach. Indeed, we notice that the second
746: %explanation is included in the first one.
747: %
748: %We deduce that constraint $C_2$ is not really responsible for the
749: %removal of this value $P_m \not= 1$. Indeed, the relaxation of
750: %$C_2$ will not change the situation at all.
751:
752: Consequently, constraints belonging to $e_2 - e_1$ are not
753: responsible of the incoherence if they do not appear in the other
754: removals. $k$-relevance is, of course, not the panacea (see
755: constraint $C_6$ which is not responsible for the removal $P_m
756: \not = 4$ but intervenes in the removal $Pm \not = 1$ -- it
757: appears in the conflict). But, the multiplicity of explanations
758: leads to more precise explanations and conflicts.
759:
760: \subsection{Does a constraint belong to a conflict?}
761: \label{sec-belonging}
762: %\texttt{More relevant answer to the question \textit{Does a constraint belongs to a conflict ?}}
763:
764: % As we saw in the introduction, the user
765: %would like to know if a constraint $c$ belongs to a conflict.
766:
767: An interesting issue when debugging is to know wether a given
768: constraint belongs to a conflict or not. $k$-relevant explanations
769: help answering that question.
770:
771:
772: Let suppose that the cause of incoherence is the variable $A_m$
773: (see table~\ref{DomaineAm}). As there is a failure (the domain of
774: variable $A_m$ is empty), the user wants to know if
775: \textit{constraint $C_5$ belongs to a conflict} by referring to
776: the table~\ref{DomaineAm}. Based on the classical approach, the
777: only conflict will be $\{C_2,C_3,C_4,C_6\}$. Indeed, The answer
778: will be negative ($C_5 \not\in \{C_2, C_3, C_4, C_6 \} $). While
779: our $1$-relevant approach provides 8 conflicts and indicates that
780: the constraint $C_5$ is strongly responsible of the incoherence.
781:
782: \begin{table}[h]
783: \begin{center}
784: \leavevmode
785:
786: \begin{tabular}{|ccccc|} \hline
787: Variable & Value & Explanation & $1$-relevance ¬ deleted~? \\ \hline
788:
789: $A_m $ & $1$ & $\{C_3\}$ & $\{C_3\},\{C_5\}$ & no \\
790: $A_m $ & $2$ & $\{C_4,C_6\} $ &$\{C_4,C_6\},\{C_5\} $ & no \\
791: $A_m $ & $3$ & $\{C_4,C_6\} $ &$\{C_4,C_6\},\{C_5\} $ & no \\
792: $A_m $ & $4$ & $\{C_2\} $ & $\{C_2\},\{C_4\} $ & no \\ \hline
793:
794: \end{tabular}
795:
796: \caption{ New state of the variable $A_m$}
797: \label{DomaineAm}
798: \end{center}
799: \end{table}
800:
801: \subsection{Simulating constraint relaxation}
802: Determining if a given constraint belongs to a conflict or not may
803: lead to spend a lot of time by relaxing each suspected constraint.
804: For that reason, we propose a tool which allows to simulate a
805: relaxation (without any propagation) only by updating the
806: $k$-relevant explanations.
807:
808: For example, let suppose that the user suspects that constraint
809: $C_3$ belongs to a conflict. The constraint-checking tool (see
810: section~\ref{sec-belonging}) confirms it. The relaxation of this
811: constraint will put back all the values $a$ such as $C_3 \in
812: expl(A_m \not= a)$. According to table~\ref{DomaineAm}, the
813: constraint $C_3$ is partly responsible for the removal $A_m \not=
814: 1$. The classical approach would have put back the value $1$ in
815: the domain of $A_m$ and launched the propagation phase.
816: Unfortunately, the problem is always over-constrained because the
817: removal $Am \not= 1$ is justified by the constraint $C_5$ and the
818: domain of $A_m$ becomes empty again.
819:
820: $1$-relevant explanations allow us to know that the relaxation of
821: the constraint $C_3$ will lead towards an another failure due to
822: the removal $A_m \not= 1$ that will be justified by another
823: explanation: $\{C_5\}$. Thus, our tool is able to indicate to the
824: user if a relaxation of a suspected constraint will lead to
825: another \emph{immediate} failure.
826:
827: \subsection{Simulating constraint addition}
828:
829: To solve a dynamic problem, a simple execution from scratch
830: is too expensive for every modification introduced by the user.
831: %Certains ont propos\'{e} des outils permettant de r\'{e}soudre le probl\`{e}me \`{a} partir de la solution courante sans savoir si cette modification (pr\'{e}cisement l'ajout d'une contrainte relax\'{e}e) nous conduira vers un \'{e}chec.
832: Some proposed tools allowing to solve the problem from the current
833: solution do not allow to know if this modification (precisely the
834: addition of a previously relaxed constraint) will lead towards a
835: failure.
836:
837: %So, il para\^{\i}t plus raisonnable de mettre \`{a} profit l'information accumul\'{e}e au cours de la r\'{e}solution du probl\`{e}me pr\'{e}c\'{e}dent pour \'{e}viter d'ajouter des contraintes nous conduisant vers un \'{e}chec imm\'{e}diat.
838:
839: It is helpful to take advantage of the information accumulated
840: during the resolution of the previous problem to avoid adding
841: constraints leading towards an \emph{immediate} failure. For this
842: reason, we have proposed a tool simulating the re-introduction of
843: a relaxed constraint without any propagation. This tool informs
844: the user if the addition of a relaxed constraint leads towards a
845: failure or not. So we can avoid reintroducing such constraints.
846:
847: %\begin{exemple}{Constraint addition}
848: For example, let suppose now that the user has removed constraints
849: $\{c_3, c_5\}$ to put back value~1 in the domain of $A_m$. The new
850: domains (along with the associated explanations) are reported in
851: table~\ref{NewDomaineAm}. Let suppose that our user wants to put
852: back the previously relaxed constraint $c_3$. A naive approach
853: consists in propagating the constraint from the current situation
854: (it leads to a contradiction). However, $2$-relevant explanations
855: can be used to simulate this constraint addition by updating the
856: relevance status of associated explanations. Some of them may
857: become valid ($\{c_3\}$ in our example) and therefore remove some
858: values (1 from $A_m$ here). Here, with no propagation at all,
859: using $k$-relevant explanation could have helped the user by
860: telling him that adding constraint $c_3$ would have lead to a
861: contradiction.
862: %\end{exemple}
863:
864: \begin{table}[hbtp]
865: \begin{center}
866: \leavevmode
867:
868: \begin{tabular}{|cccccc|} \hline
869: Variable & Value & Explanation & $1$-relevance & $2$-relevance & present~? \\ \hline
870:
871: $A_m $ & $1$ & & & $\{C_3\},\{C_5\}$ & yes \\
872: $A_m $ & $2$ & $\{C_4,C_6\} $ &$\{C_4,C_6\},\{C_5\} $ & & no \\
873: $A_m $ & $3$ & $\{C_4,C_6\} $ &$\{C_4,C_6\},\{C_5\} $ & & no \\
874: $A_m $ & $4$ & $\{C_2\} $ & $\{C_2\},\{C_4\} $ & & no \\ \hline
875:
876: \end{tabular}
877:
878: \caption{ New state of the variable $A_m$ after relaxation of $c_3$ and $c_5$}
879: \label{NewDomaineAm}
880: \end{center}
881: \end{table}
882:
883:
884: %For implementing such a tool, the idea is to decrease the
885: %relevance of the $k$-relevant explanation which contain the
886: %relaxed constraint $c$ (precisely the explanations which have only
887: %constraint $c$ as relaxed constraint). If we add constraint $c$,
888: %these explanations become valid (\ie $1$-relevant). This will
889: %imply the removal of some values. Thus, we can easily verify if
890: %any domain becomes empty (\ie failure) when adding constraint
891: %$c$.
892:
893: %After, as some explanations become valid (\ie $1$-relevant),
894: %we can know which part of the values have to be removed. Thus, in some cases, we can determine without any
895: %propagation if any domain becomes empty. This is not feasible by
896: %the classical approach without propagating.
897:
898: \subsection{Providing error diagnosis}
899: Imagine now that after some relaxations, the user wants to know
900: why the variable $M_p$ cannot take the value $1$? The classical
901: approach provides the explanation $\{C_6\}$. While the
902: $1$-relevant approach provides the set of explanations: $\{
903: \{C_4\}, \{C_5\}, \{C_6\}\}$.
904:
905: We notice that $1$-relevance provides a richer diagnosis than the
906: classical approach.
907:
908: \section{Implementation} \label{implementation}
909:
910: \textbf{COINS} has been implemented in
911: \texttt{choco}\footnote{\texttt{choco} is an open source
912: constraint engine developed as the kernel of the OCRE project. The
913: OCRE project (its name standing for \emph{Outil Contraintes pour
914: la Recherche et l'Enseignement}, \ie, \emph{Constraint tool for
915: Research and Education}) aims at building free Constraint
916: Programming tools that anyone in the Constraint Programming and
917: Constraint Reasoning community can use. For more information see
918: www.choco-constraints.net.} \cite{laburthe-choco} using the
919: \texttt{PaLM} system \cite{jussien-palm}. \texttt{choco} allows~:
920: to propagate the constraints, to manage domains as well as other
921: filtering algorithms, local search, etc. Experiments show that
922: when $k$ increases, the performance of $k$-relevance decreases.
923: In the other hand, for $k=1$ and $k = 2$, we obtain the same
924: temporal performances as \textbf{mac-dbt}\cite{jussien-macdbt-cp}.
925: For $k = 1$ and $k = 2$, the time lost to manage the $k$-relevant
926: explanations is compensated by avoiding future failures. For $k
927: \geq 3$, $k$-relevance loses its advantages. More precisely, for
928: such a $k$, we are losing time managing explanations that will
929: seldom let us avoid future failures. Especially, we shall update
930: explanations which will never become valid (\ie $1$-relevant).
931:
932: %Thus the compromise between record useful explanations and
933: %$k$-relevant explanation time management, would be $k=1$ and
934: %$k=2$. Unfortunately, we pay a small penalty of memory space.
935:
936: %We limit our description to the management of the k-relevant eliminating explanations and their relevance.
937: %
938: %First, concerning the addition of an instantiation constraint\footnote{An instantiation constraint is a singular constraint of type $v = val$.}, we shall begin by updating the relevance of the eliminating explanations which contain the added constraint before propagating its effects (see figure \ref{explication}, line 3).
939: %
940: %
941: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
942: %% ALGO DBT+K-RELEVANCE ALGO DBT+K-RELEVANCE ALGO DBT+K-RELEVANCE
943: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
944: %
945: %\begin{figure*}[h]
946: %\begin{center}
947: %\scriptsize
948: %
949: %
950: %\fbox{\parbox{10cm}{
951: %\begin{tabular}{p{11.5cm}}
952: %
953: %
954: %
955: %\newcounter{numligne}
956: %\newcounter{numlignecc}
957: %
958: %\setcounter{numligne}{1}
959: %\setcounter{numlignecc}{1}
960: %
961: %
962: %
963: %
964: %
965: %%%%%
966: %%%%% function dbt-giveValueAndCheck(I, V, i, a)
967: %%%%%
968: %\textbf{function} $dbt$-$giveValueAndCheck( I, \mathcal{V}, i, a)$ \\
969: %%%%%
970: %%%%% Ci=(i=a); C<-CU{Ci};
971: %%%%%
972: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} $C_{i}=constraint(i=a); \mathcal{C}\gets\mathcal{C}\cup\lbrace C_i \rbrace$ ; \\
973: %%%%%
974: %%%%% I<-IU{(i,a)}; V<-V\{i};
975: %%%%%
976: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} $I\gets I\cup\lbrace (i,~a)\rbrace$ ; $\mathcal{V}\gets \mathcal{V}\backslash \lbrace i\rbrace$ ; \\
977: %%%%%
978: %%%%% j <- dbt-updateAdd({(v,l,Ei)| Ci in Expl(v,l,i,s)})
979: %%%%%
980: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} $j \gets dbt$-$updateAdd(\lbrace (v,l,d,s) | C_i \in Expl(v, l,d,s) \rbrace) $ \\
981: %%%%%
982: %%%%% if j = success
983: %%%%%
984: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} \textbf{if} $j = success$\\
985: %%%%%
986: %%%%% foreach beDi s.t. b=/=a do
987: %%%%%
988: %\thenumligne \stepcounter{numligne} \hspace*{0.4cm} \textbf{foreach} $b\in D_i~$ s.t. $~b\neq a$ \textbf{do} \\
989: %%%%%
990: %%%%% Expl(i,b,0) <- Expl(i,b,0) U {{Ci}}
991: %%%%%
992: %\thenumligne \stepcounter{numligne} \hspace*{0.6cm} $Expl(i,b,1) \gets Expl(i,b,1) \cup \lbrace \{ C_i\} \rbrace$; \\
993: %%%%%
994: %%%%% Di<-{a};
995: %%%%%
996: %\thenumligne \stepcounter{numligne} \hspace*{0.4cm} $D_{i}\gets\lbrace a\rbrace$ ; \\
997: %%%%%
998: %%%%% else var <- selectOneVariable(j);
999: %%%%%
1000: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} \textbf{else} $var \gets selectOneVariable(j)$;
1001: %
1002: %%%%%
1003: %%%%% dbt-handleContradiction()
1004: %%%%%
1005: %\thenumligne \stepcounter{numligne} \hspace*{0.6cm} $dbt$-$handleContradiction(\bigcup_{a\in dom_{var}} select(Expl(var,a,1)), I, \mathcal{V})$;\\
1006: %%%%%
1007: %%%%% c<-dbt-checkConstraintsBackards(I);
1008: %%%%%
1009: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} $c\gets dbt$-$checkConstraintsBackwards(I)$; \\
1010: %%%%%
1011: %%%%% if c is a success then return success
1012: %%%%%
1013: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} \textbf{if} $c$ is a $success$ \textbf{then return} $success$ \\
1014: %%%%%
1015: %%%%% else return{ci}U{Ck| kevars(c)}
1016: %%%%%
1017: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} \textbf{else return} $\lbrace C_i\rbrace\cup\lbrace C_k \vert k\in vars(c)\rbrace$
1018: %
1019: %
1020: %\end{tabular}
1021: %
1022: %}}
1023: %\end{center}
1024: %
1025: %\caption{\label{explication} Adding an instantiation constraint}
1026: %
1027: %
1028: %
1029: %\end{figure*}
1030: %
1031: %
1032: %
1033: %The addition of this instantiation constraint will decrease the relevance of the explanations noted above (see figure \ref{majexplication}).
1034: %Among these eliminating explanations, some of them will become valid, and allow to remove values present in their domain.
1035: %At the end of this update we test if there is no incoherence (i.e. an empty domain ) (see figure \ref{majexplication}, line 6).
1036: %
1037: %
1038: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1039: %% ALGO DBT+K-RELEVANCE ALGO DBT+K-RELEVANCE ALGO DBT+K-RELEVANCE
1040: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1041: %
1042: %\begin{figure*}[h]
1043: %\begin{center}
1044: %
1045: %\scriptsize
1046: %\fbox{\parbox{10cm}{
1047: %
1048: %
1049: %\begin{tabular}{p{11.5cm}}
1050: %
1051: %%\setlength{\tabac}{1cm}
1052: %\setcounter{numligne}{1}
1053: %\setcounter{numlignecc}{1}
1054: %\\
1055: %
1056: %%%%%
1057: %%%%% function dbt-updateAdd(last)
1058: %%%%%
1059: %\textbf{function} $dbt$-$updateAdd(last)$\\
1060: %\thenumligne \stepcounter{numligne} \hspace{0.1cm} $state \gets success$\\
1061: %%%%%
1062: %%%%% foreach (v,l,i,j) in last
1063: %%%%%
1064: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} \textbf{foreach} $(v \not= a,i,j^{th}) \in last$ \textbf{do}\\
1065: %%%%%
1066: %%%%% Expl(v,l,i-1,j) <- Expl(v,l,i,j)
1067: %%%%%
1068: %\thenumligne \stepcounter{numligne} \hspace*{0.4cm} $Expl(v \not= l,i - 1, j^{th}) \gets Expl(v \not= l,i,j^{th})$;\\
1069: %%%%%
1070: %%%%% if i=0 and |Expl(v,l,1,j)| = 1 then
1071: %%%%%
1072: %\thenumligne \stepcounter{numligne} \hspace*{0.4cm} \textbf{if} $i=0$ \textbf{and} $|Expl(v,l,0)| = 1$ \textbf{then}\\
1073: %%%%%
1074: %%%%% Dv <- Dv - {l};
1075: %%%%%
1076: %\thenumligne \stepcounter{numligne} \hspace*{0.6cm} $D_v \gets D_v \backslash \lbrace l \rbrace$;\\
1077: %%%%%
1078: %%%%% if Dv = 0 then state <- state U v
1079: %%%%%
1080: %\thenumligne \stepcounter{numligne} \hspace*{0.6cm} \textbf{if} $D_v = \emptyset$ \textbf{then} $state \gets state \cup v$;\\
1081: %%%%%
1082: %%%%% retourne state
1083: %%%%%
1084: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} \textbf{return} $state;$\\
1085: %
1086: %
1087: %
1088: %
1089: %
1090: %\end{tabular}
1091: %
1092: %}}
1093: %\end{center}
1094: %
1095: %\caption{\label{majexplication} Updating the eliminating explanations }
1096: %
1097: %\end{figure*}
1098: %
1099: %
1100: %
1101: %
1102: %
1103: %
1104: %Secondly, when we relax a constraint, \textbf{mac-dbt} ignores all the eliminating explanations disabled. In particular, \textbf{mac-dbt} will put back values which their eliminating explanations are ignored. But as k-relevance records a set of eliminating explanations for each removal, it maintains these removed values while it exists a valid explanation. The test (line 4 of figure \ref{domaine}) allows to restrict the return of the values which have no valid explanations.
1105: %
1106: %
1107: %
1108: %
1109: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1110: %% ALGO DBT+K-RELEVANCE ALGO DBT+K-RELEVANCE ALGO DBT+K-RELEVANCE
1111: %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
1112: %
1113: %\begin{figure*}[h]
1114: %\begin{center}
1115: %\scriptsize
1116: %\fbox{\parbox{10cm}{
1117: %
1118: %\begin{tabular}{p{11.5cm}}
1119: %%\setlength{\tabac}{1cm}
1120: %\setcounter{numligne}{1}
1121: %\setcounter{numlignecc}{1}
1122: %\\
1123: %
1124: %
1125: %
1126: %
1127: %%%%%
1128: %%%%% function dbt-updateRetract(back)
1129: %%%%%
1130: %\textbf{function} $dbt$-$updateRetract(Back)$ \\
1131: %%%%%
1132: %%%%% foreach (v,a,i,j) in back do
1133: %%%%%
1134: %\thenumligne \stepcounter{numligne} \hspace*{0.1cm} \textbf{foreach} $(v,a,i,j^{th})\in back$ \textbf{do} \\
1135: %%%%%
1136: %%%%% Expl(v,a,i+1,j) <- Expl(v,a,i,j)
1137: %%%%%
1138: %\thenumligne \stepcounter{numligne} \hspace*{0.4cm} $Expl(v,a,i + 1,j) \gets Expl(v,a,i,j) $;\\
1139: %%%%%
1140: %%%%% delete(Expl(v,a,j)|j=k)
1141: %%%%%
1142: %\thenumligne \stepcounter{numligne} \hspace*{0.4cm} $delete(Expl(v,a,i)|i=k)$;\\
1143: %%%%%
1144: %%%%% if Expl(v,a,0) = emptyset then
1145: %%%%%
1146: %\thenumligne \stepcounter{numligne} \hspace*{0.4cm} \textbf{if} $Expl(v,a,0) = \{\emptyset\}$ \textbf{then}\\
1147: %%%%%
1148: %%%%% Dv <- Dv U {l};
1149: %%%%%
1150: %\thenumligne \stepcounter{numligne} \hspace*{0.6cm} $D_v \gets D_v \cup \lbrace l \rbrace$;\\
1151: %
1152: %
1153: %\end{tabular}
1154: %
1155: %}}
1156: %\end{center}
1157: %
1158: %\caption{\label{domaine} Updating the domains}
1159: %
1160: %\end{figure*}
1161:
1162:
1163: \section{Conclusion}
1164: In this paper, we have introduced the foundations of several
1165: interactive tools which are of great help for a user to solve an
1166: over-constrained problem. We have shown the effectiveness of these
1167: $k$-relevance-based tools. $k$-relevance keeps several
1168: explanations by removal and forgets them once they become
1169: irrelevant.
1170:
1171: We have shown the contribution of our $k$-relevance-based tools
1172: compared to classical approach. $k$-relevance
1173: provides more precise explanations; gives some general information
1174: that cannot be accessible within a classical framework:
1175: $k$-relevance allows the simulating of constraint
1176: retraction/addition and so provides richer diagnosis tools.
1177:
1178: Our current work includes designing algorithms which compute the
1179: \emph{best} conflict from all the explanations. We investigate
1180: adding user-based comparators \cite{borning-constraint-89} to our
1181: tools in order to provide automatic comparison of solutions.
1182: Also, we try to decrease the space complexity by managing differently the explanations.
1183:
1184: \begin{thebibliography}{10}
1185:
1186: \bibitem{aggoun-chip}
1187: Aggoun, A., Dincbas, M., Herold, A., Simonis, H., {Van
1188: Hentenryck}, P.:
1189: \newblock {The CHIP System}.
1190: \newblock Technical Report TR-LP-24, ECRC, Munich, Germany (1987)
1191:
1192: \bibitem{laburthe-choco}
1193: Laburthe, F.:
1194: \newblock {CHOCO}: implementing a {CP} kernel.
1195: \newblock In: CP00 Post Conference Workshop on Techniques for Implementing
1196: Constraint programming Systems (TRICS), Singapore (2000)
1197:
1198: \bibitem{diaz-gnuProlog}
1199: Diaz, D., Codognet, P.:
1200: \newblock The {GNU} prolog system and its implementation.
1201: \newblock In: ACM Symposium on Applied Computing, Villa Olmo, Como, Italy
1202: (2000)
1203:
1204: \bibitem{reference01ilog}
1205: Ilog:
1206: \newblock Solver reference manual (2001)
1207:
1208: \bibitem{junker-quickxplain}
1209: Junker, U.:
1210: \newblock {QUICKXPLAIN}: Conflict detection for arbitrary constraint
1211: propagation algorithms.
1212: \newblock In: IJCAI'01 Workshop on Modelling and Solving problems with
1213: constraints, Seattle, WA, USA (2001)
1214:
1215: \bibitem{bessiere-dynamic}
1216: Bessi\`ere, C.:
1217: \newblock Arc consistency in dynamic constraint satisfaction problems.
1218: \newblock In: Proceedings AAAI'91. (1991)
1219:
1220: \bibitem{debruyne-dynamic}
1221: Debruyne, R.:
1222: \newblock Arc-consistency in dynamic {CSP}s is no more prohibitive.
1223: \newblock In: $8^{th}$ {C}onference on {T}ools with {A}rtificial {I}ntelligence
1224: {(TAI'96)}, Toulouse, France (1996) 299--306
1225:
1226: \bibitem{jussien-palm}
1227: Jussien, N., Barichard, V.:
1228: \newblock The palm system: explanation-based constraint programming.
1229: \newblock In: Proceedings of {TRICS}: {T}echniques fo{R} {I}mplementing
1230: {C}onstraint programming {S}ystems, a post-conference workshop of {CP 2000},
1231: Singapore (2000) 118--133
1232:
1233: \bibitem{bayardo-complexity}
1234: {Bayardo Jr.}, R.J., Miranker, D.P.:
1235: \newblock A complexity analysis of space-bounded learning algorithms for the
1236: constraint satisfaction problem.
1237: \newblock In: AAAI'96. (1996)
1238:
1239: \bibitem{schiex-nogood}
1240: Schiex, T., Verfaillie, G.:
1241: \newblock Nogood {R}ecording fot {Static} and {Dynamic} {Constraint}
1242: {Satisfaction} {Problems}.
1243: \newblock International Journal of Artificial Intelligence Tools \textbf{3}
1244: (1994) 187--207
1245:
1246: \bibitem{jussien-e-constraints}
1247: Jussien, N.:
1248: \newblock e-constraints: explanation-based constraint programming.
1249: \newblock In: CP01 Workshop on User-Interaction in Constraint Satisfaction,
1250: Paphos, Cyprus (2001)
1251:
1252: \bibitem{jussien-user-friendly}
1253: Jussien, N., Ouis, S.:
1254: \newblock User-friendly explanations for constraint programming.
1255: \newblock In: ICLP'01 11th Workshop on Logic Programming Environments, Paphos,
1256: Cyprus (2001)
1257:
1258: \bibitem{stallman-ddb}
1259: Stallman, R.M., Sussman, G.J.:
1260: \newblock Forward reasoning and dependency directed backtracking in a system
1261: for computer-aided circuit analysis.
1262: \newblock Artificial Intelligence \textbf{9} (1977) 135--196
1263:
1264: \bibitem{ginsberg-dynamic}
1265: Ginsberg, M.:
1266: \newblock Dynamic backtracking.
1267: \newblock Journal of Artificial Intelligence Research \textbf{1} (1993) 25--46
1268:
1269: \bibitem{jussien-macdbt-cp}
1270: Jussien, N., Debruyne, R., Boizumault, P.:
1271: \newblock Maintaining arc-consistency within dynamic backtracking.
1272: \newblock In: Principles and Practice of Constraint Programming (CP 2000).
1273: Number 1894 in Lecture Notes in Computer Science, Singapore, Springer-Verlag
1274: (2000) 249--261
1275:
1276: \bibitem{bliek-gpb}
1277: Bliek, C.:
1278: \newblock Generalizing partial order and dynamic backtracking.
1279: \newblock In: Proceedings of AAAI. (1998)
1280:
1281: \bibitem{ginsberg-gsat}
1282: Ginsberg, M., McAllester, D.:
1283: \newblock {GSAT} and dynamic backtracking.
1284: \newblock In Borning, A., ed.: Principles and Practice of Constraint
1285: Programming. Volume 874 of Lecture Notes in Computer Science., Springer
1286: (1994) (PPCP'94: Second International Workshop, Orcas Island, Seattle, USA).
1287:
1288: \bibitem{prosser-maccbj}
1289: Prosser, P.:
1290: \newblock {MAC-CBJ}: maintaining arc-consistency with conflict-directed
1291: backjumping.
1292: \newblock Research Report 95/177, Department of Computer Science -- University
1293: of Strathclyde (1995)
1294:
1295: \bibitem{glover-tabu}
1296: Glover, F., Laguna, M.:
1297: \newblock Modern heuristic Techniques for Combinatorial Problems, chapter Tabu
1298: Search, C. Reeves.
1299: \newblock Blackwell Scientific Publishing (1993)
1300:
1301: \bibitem{schiex-nogood-orig}
1302: Schiex, T., Verfaillie, G.:
1303: \newblock Nogood recording for static and dynamic {CSP}.
1304: \newblock In: $5^{th}$ IEEE International Conference on Tools with Artificial
1305: Intelligence, Boston, MA. (1993) 48--55
1306:
1307: \bibitem{dechter90}
1308: Dechter, R.:
1309: \newblock Enhancement schemes for constraint processing: Backjumping, learning,
1310: and cutset decomposition.
1311: \newblock Artificial Intelligence \textbf{41} (1990) 273--312
1312:
1313: \bibitem{jussien-implementing-lncs}
1314: Jussien, N., Boizumault, P.:
1315: \newblock Implementing constraint relaxation over finite domains using {ATMS}.
1316: \newblock In Jampel, M., Freuder, E., Maher, M., eds.: Over-Constrained
1317: Systems. Number 1106 in Lecture Notes in Computer Science, Springer-Verlag
1318: (1996) 265--280
1319:
1320: \bibitem{borning-constraint-89}
1321: Borning, A., Maher, M., Martindale, A., Wilson, M.:
1322: \newblock Constraint hierarchies and logic programming.
1323: \newblock In Levi, G., Martelli, M., eds.: ICLP'89: Proceedings 6th
1324: International Conference on Logic Programming, Lisbon, Portugal, MIT Press
1325: (1989) 149--164
1326:
1327: \end{thebibliography}
1328:
1329: \end{document}
1330: