1: \NeedsTeXFormat{LaTeX2e}
2: \documentclass[runningheads]{llncs}
3:
4: \usepackage[boxed]{algorithm}
5: \usepackage[noend]{algorithmic}
6: \usepackage{epsfig}
7: \usepackage{latexsym}
8: \usepackage{longtable}
9: \usepackage{psboxit}
10: \usepackage{boxedminipage}
11: \floatstyle{ruled}
12: \newfloat{ex05}{h}{lox}
13: \floatname{ex05}{Ex.}
14: \def\dfn#1{{\em #1}}
15: \def\code#1{\mathsf{#1}}
16: \def\var#1{\textit{#1}}
17: \def\divd#1#2{\lfloor#1/#2\rfloor}
18: \def\divu#1#2{\lceil#1/#2\rceil}
19: \def\In{\mbox{\rm{\ in\ }}}
20: \def\sicstus{SICStus}
21: \def\tracesize{\footnotesize}
22: \newcommand{\caplab}[2]{\caption{\label{#1} #2}}
23: \newcommand{\itemtext}[1]{\item {\bf[#1]}}
24: \newcommand{\tabbegin}[1]{\begin{table*}[#1]\centering}
25: \newcommand{\tabend}{\end{table*}}
26: \newcommand{\figbegin}[1]{\begin{figure*}[#1]}
27: \newcommand{\figend}[2]{\caplab{#1}{#2}\end{figure*}}
28: \newcommand{\mapmath}{$\mapsto$}
29: \newcommand{\hlineskip}{\noalign{\smallskip}\hline\noalign{\smallskip}}
30: \newcommand{\tabhead}[1]{\textbf{#1}}
31: \newcommand{\evtabbegin}[3]{\begin{minipage}{\linewidth}
32: \begin{tabular}{p{#1cm}|p{#2cm}|p{-#3cm +
33: \linewidth}}
34: \hline\noalign{\smallskip}
35: \multicolumn{1}{l}{\tabhead{Trace Event}} &
36: \multicolumn{1}{l}{\tabhead{Attributes}} &
37: \multicolumn{1}{l}{\tabhead{Meaning}} \\
38: \noalign{\smallskip} \hline \noalign{\smallskip}}
39: \newcommand{\evtabend}{\end{tabular}\end{minipage}}
40: \newcommand{\standout}[1]{\textbf{#1}}
41: \newcommand{\greybox}[1]{\psboxit{box .7 setgray fill}{#1}}
42: \newcommand{\eclipse}{ECL$^i$PS$^e$}
43: \newcommand{\texttype}[1]{\texttt{#1}}
44: \newcommand{\nter}[1]{\mbox{$\langle$\textrm{\textit{#1}}$\rangle$}}
45: \newcommand{\ter}[1]{\mbox{\texttt{#1}}}
46: \newcommand{\reczero}[1]{#1$^{*}$} \newcommand{\recone}[1]{#1$^{+}$}
47: \newcommand{\recn}[1]{#1$^{n}$} \newcommand{\maxone}[1]{$[$#1$]$}
48: \newcommand{\group}[1]{$($#1$)$}
49: \newcommand{\rulecounterstep}{\stepcounter{rule}\` (\therule)}
50: \newcommand{\ttitem}[1]{\item{\texttt{#1}}}
51: \newcommand{\bfitem}[1]{\item{\textbf{#1}}}
52: \newcommand{\xindex}[1]{$\mathtt{X_{#1}}$}
53: \newcommand{\yindex}[1]{$\mathtt{Y_{#1}}$}
54: \newcommand{\cindex}[1]{$\mathtt{C_{#1}}$}
55: \newcommand{\xcindex}[1]{$\mathtt{C_{#1}*X_{#1}}$}
56: \newcommand{\xindext}[2]{$\mathtt{X^{#1}_{#2}}$}
57: \newcommand{\nxs}[1]{#1_{1},\ldots ,#1_{n}}
58: \newcommand{\mxs}[1]{#1_{1},\ldots ,#1_{m}}
59: \newcommand{\ncxs}[2]{#1_{1}*#2_{1}+\cdots+#1_{n}*#2_{n}}
60: \newcommand{\spsum}[1]{\underset{i=1,i\neq k,C_{i}#1 0}
61: {\overset{n+1}\sum}} \newcommand{\rhs}[1]{RHS^{#1}_{k}}
62: \newcommand{\mtt}[1]{$\mathtt{#1}$}
63: \newcommand{\mexp}[1]{$#1$}
64: \newcommand{\pqueue}{\textsc{PropagationQueue}}
65: \newcommand{\rqueue}{\textsc{ReadyQueue}} \newcommand{\clpfd}{CLP(FD)}
66: \newcommand{\cpfd}{CP(FD)} \newcommand{\prog}[1]{\texttt{#1}}
67: \newenvironment{boxpage}
68: {\begin{center}\begin{boxedminipage}{\linewidth}\begin{tabbing}}
69: {\end{tabbing}\end{boxedminipage}\end{center}}
70: \newenvironment{quotetab} {\begin{quote}\begin{tabbing}}
71: {\end{tabbing}\end{quote}}
72:
73:
74:
75:
76: \begin{document}
77: \setcounter{page}{1}
78: \title{Tracing and Explaining Execution of \clpfd\ Programs}
79: \titlerunning{Tracing and Explaining Execution of \clpfd\ Programs}
80: \author{Magnus {\AA}gren \and Tam{\'a}s Szeredi \and Nicolas Beldiceanu \and Mats Carlsson}
81: \authorrunning{M. {\AA}gren, T. Szeredi, N. Beldiceanu, M. Carlsson}
82: \institute{SICS, L{\"a}gerhyddsv. 18, SE-752~37~~UPPSALA, Sweden\\
83: \email{\symbol{`\{}magren,tszeredi,nicolas,matsc\symbol{`\}}@sics.se}}
84:
85: \maketitle
86:
87: \addtocounter{footnote}{1}
88: \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)}
89:
90: \begin{abstract}
91: Previous work in the area of tracing \clpfd\ programs mainly focuses
92: on providing information about control of execution and domain
93: modification. In this paper, we present a trace structure that
94: provides information about additional important aspects. We
95: incorporate explanations in the trace structure, i.e.\ reasons for why
96: certain solver actions occur. Furthermore, we come up with a format
97: for describing the execution of the filtering algorithms of global
98: constraints. Some new ideas about the design of the trace are also
99: presented. For example, we have modeled our trace as a nested block
100: structure in order to achieve a hierarchical view. Also, new ways
101: about how to represent and identify different entities such as
102: constraints and domain variables are presented.
103: \end{abstract}
104:
105: \section{Introduction}\label{sect:intro}
106: In this paper, we present new ideas in the area of tracing \clpfd\
107: programs. New trends such as tracing global constraints and explaining
108: solver actions are investigated. Since these issues are still in their
109: development stages and not systematically used, we have not tried to
110: create a universal trace model. Instead, we focus on \clpfd\ and in
111: particular the \clpfd\ solver of \sicstus\ Prolog.
112:
113: %However, our ideas should be fairly easy to apply to other systems as
114: %well.
115:
116: %Over the past 5-10 years, several debugging tools for Constraint
117: %Programming (CP) systems have been proposed and implemented. Two
118: %well-known examples are the Grace debugging tool~\cite{bib:mei95} by
119: %Meier and the Oz Explorer~\cite{bib:schulte97} by Schulte. Generally;
120: %graphical tools, displaying various aspects of the program execution
121: %in a way easily overviewed and controlled by a human, seem to be an
122: %appropriate approach.
123:
124: %No matter what kind of tool you are about to build, information from
125: %within the constraint solver is needed. One way of solving this is by
126: %producing an event trace, from which each tool may extract the needed
127: %information. When designing such a trace structure, several questions
128: %arise. What kind of and how detailed information should be provided?
129: %In what format should the information be presented?
130:
131:
132: The idea of tracing constraint programs originates from
133: Meier~\cite{bib:mei95}. Also, the search-tree visualization tool in
134: CHIP~\cite{bib:sa00} uses a trace log to be able to display
135: propagation events. More current work is carried out by Langevine et
136: al.\ who presented a \clpfd\ trace model in~\cite{bib:lddj01a}. Their
137: work is naturally influenced by the work of
138: Ducass\'{e}~\cite{bib:duc99} on Opium.
139:
140: Previous work such as the above mainly focuses on providing
141: information about control of execution and domain modification. Of
142: course, this information is needed, but if nothing else is provided,
143: important information about the execution is lost. We have looked at
144: the execution of a \clpfd\ program from the following perspectives:
145: \begin{enumerate}
146: \item\label{l11} Control of Execution; information about posting new
147: constraints, waking up delayed constraints, constraint
148: entailment/failure.
149:
150: \item\label{l12} Domain Modification; information about variable
151: domain narrowing (pruning).
152:
153: \item\label{l13} Declarative Aspect; information about why certain actions are
154: taken by the solver and in which context they occur.
155:
156: \item\label{l14} Procedural Aspect; information about filtering
157: algorithms and their entities.
158: \end{enumerate}
159:
160: We build the trace of events as a nested block structure. This means
161: that most of the trace events appear inside a block surrounded by a
162: starting event and an ending event. One example of this is the
163: posting of a new constraint, which gives rise to a block surrounded by
164: the trace events \verb+begin_new_ctr+ and \verb+end_new_ctr+. Inside
165: this block, trace events describing the posting of demon(s) for the
166: new constraint and initial prunings are generated. Building the trace
167: like this has several advantages. First of all, it makes it easier to
168: get a structured overview of the trace. Second, similar actions may be
169: grouped together inside the same block. Furthermore, extra information
170: about the action(s) taking place may be added to the opening and
171: closing events as well as through added events inside the block.
172:
173: We identify variables and other entities by their context, i.e.\ their
174: positions in the constraints, and not only by some identifier. This is
175: useful when one needs to distinguish a specific occurrence among
176: several of the same variable. In addition to that, it makes it
177: possible to also clearly identify entities such as integers, atoms and
178: compound terms.
179:
180: Also, corresponding to point~\ref{l13} above, we provide
181: \dfn{explanations}~\cite{bib:jus01} for why certain actions
182: are taken by the solver. These explanations are incorporated in the
183: trace by specific explanation trace events. Actions for which
184: explanations are provided include domain narrowing, failure, demon
185: enqueuing and internal constraint posting. We extend previous work by
186: also providing compact explanations for global constraints. By doing
187: this, we obtain a stronger link between the consistency rules of the
188: global constraints and the trace.
189:
190: Moreover, corresponding to point~\ref{l14} above, we provide trace
191: events containing detailed information about the filtering algorithms
192: of global constraints. This concerns identifying and presenting the
193: different entities inside the algorithms. This too increases the link
194: between the global constraints and the trace. However, this is more
195: related to the procedural aspect.
196:
197: An example of a simple \clpfd\ program in \sicstus\ Prolog is shown in
198: Ex.~\ref{ex:traceme}. It will be used throughout the paper. Line
199: \verb+(2)+ initializes the domains of the included variables. Lines
200: \verb+(3)+ and \verb+(4)+ post the well-known constraints
201: \verb+all_different/1+\footnote{This is the naive version of
202: \texttt{all\_different}, achieving the same pruning as a set of
203: pairwise inequality constraints.} and \verb+element/3+. Line
204: \verb+(5)+ calls \sicstus's builtin search predicate with a
205: \verb+leftmost+\footnote{Leftmost variable, smallest value first.}
206: search strategy.
207:
208: \begin{ex05}[h]
209: \begin{verbatim}
210: trace_me :- (1)
211: domain([X,Y,V1,V2],1,6), (2)
212: all_different([X,Y,3,V1,8,V2]) (3)
213: element(X,[2,4,3,8],Y), (4)
214: labeling([leftmost],[X,Y,V1,V2]). (5)
215: \end{verbatim}
216: \caption{A simple \clpfd\ Program.}
217: \label{ex:traceme}
218: \end{ex05}
219:
220: In the following, Sect.~\ref{sect:model} presents a \clpfd\ execution
221: model. This is needed in order to be able to present the trace
222: structure in its relevant context. Sect.~\ref{sect:trace} presents the
223: different trace events. First, some design choices concerning how to
224: represent different entities such as constraints and variables are
225: introduced. Following that, the trace events are presented in chunks;
226: trace events corresponding to the same perspective, as noted above,
227: are presented together. After that, a short description of the
228: implementation made in \sicstus\ Prolog is
229: given. Sect.~\ref{sect:relwork} discusses possible areas of
230: usage. Finally, Sect.~\ref{sect:concl} concludes the paper.
231: \section{Execution Model}\label{sect:model}
232: This section presents an execution model of a \clpfd\ kernel; the
233: different data structures it contains, and how these interact. By
234: doing this, we can later present the trace structure in its relevant
235: context. The model is influenced by the constraint solvers of
236: \sicstus\ Prolog~\cite{bib:coc97} and Choco~\cite{bib:lab00}.
237: \subsubsection{Data Structures.}
238: The data structures contain lists and queues for storing information
239: regarding constraints, variables, demons and propagation events.
240:
241: Each \dfn{constraint} is associated with a list of domain variables,
242: \verb+VList+, and a list of demons, \verb+DList+. \verb+VList+
243: contains the variables that occur in the constraint. \verb+DList+
244: contains the demons that are responsible for removing inconsistent
245: values from the variables in \verb+VList+.
246:
247: Each \dfn{variable} is associated with a domain, \verb+Domain+,
248: containing the values the variable may take. These domains are
249: narrowed by propagation events specified below. Furthermore, each
250: variable is associated with a list of constraints, \verb+CList+, which
251: it is involved in. As soon as the domain of a variable changes, one or
252: more of these constraints may wake up and activate their demons.
253:
254: Each \dfn{demon} contains a \dfn{wake-up condition}. When the wake-up
255: condition is fulfilled, the demon's \dfn{filtering algorithm} is
256: activated. This filtering algorithm may exclude some values from the
257: domains of some variables. A filtering algorithm consists of a set of
258: \dfn{methods}, \mtt{\{M_{1},\ldots,M_{n}\}}, where each \mtt{M_{i}}
259: corresponds to some consistency rule of the constraint that the demon
260: belongs to. If some method, \mtt{M_{i}}, notices that the domains of
261: some variables are not consistent with the constraint, \mtt{M_{i}}
262: generates propagation events which specify domain narrowings on these
263: variables.
264:
265: The \dfn{propagation events} have the form \verb+X in_set S+, which
266: constrains the variable \verb+X+ to be a member of the set \verb+S+ of
267: integers.
268:
269: Two \dfn{global lists} are used for storing current constraints and
270: variables in the system; \verb+ConstraintList+ and
271: \verb+VariableList+. Furthermore, two \dfn{global queues} are needed
272: to manage the actions taken by the kernel. \verb+ReadyQueue+ contains
273: the demons that are about to wake up. \verb+PropagationQueue+ contains
274: the propagation events that have been created by active demons.
275:
276: Fig.~\ref{fig:kernel} shows the different data structures and how they
277: are connected to each other. The state is taken from
278: Ex.~\ref{ex:traceme}, just before the execution of line
279: \verb+(4)+. \verb+C1+ and \verb+C2+ are the \verb+all_different/1+ and
280: \verb+element/3+ constraints respectively. Detailed information about
281: variables \verb+X+ and \verb+Y+ as well as about constraint \verb+C2+
282: is shown in three boxes.
283:
284: \figbegin{h}
285: \begin{center}\mbox{\psfig{file=kernel.eps,width=9cm}}\end{center}
286: \figend{fig:kernel}{Kernel state for Ex.~\ref{ex:traceme}. Just before
287: the execution of line \texttt{(4)}.}
288: \subsubsection{Services.}
289: Our \clpfd\ kernel provides the following services:
290: \begin{itemize}
291:
292: \ttitem{connectCtr(C)}, adds the constraint \verb+C+ to the kernel.
293: This includes adding \verb+C+ to \verb+ConstraintList+, adding the
294: variables in \verb+C+ to \verb+VariableList+, \verb+adding+ \verb+C+
295: to the \verb+CList+ of all its variables, creating the
296: demons\footnote{Our trace structure supports the use of more than one
297: demon for each constraint. However, since the examples in this paper
298: are created using \sicstus\ Prolog, and it currently only associates
299: one demon with each constraint, more than one demon per constraint
300: will never be shown.} associated with \verb+C+ and running each
301: demon's filtering algorithm for initial propagation.
302:
303: \ttitem{disconnectCtr(C)}, removes the constraint \verb+C+ from the
304: kernel. This is done when the constraint is entailed, i.e.\ when
305: \verb+C+ is true no matter what values its variables take.
306:
307: \ttitem{enqueueCtr(C,E)}, puts last in \verb+ReadyQueue+ the demons
308: associated with the constraint \verb+C+ that are to wake up due to the
309: propagation event \verb+E+. If any of these demons are already in
310: \verb+ReadyQueue+, it will not be enqueued again.
311:
312: \ttitem{dispatchCtr()}, dequeues the demon that is first in
313: \verb+ReadyQueue+ and activates its filtering algorithm.
314:
315: \ttitem{enqueueEvent(E)}, puts \verb+E+ last in
316: \verb+PropagationQueue+.
317:
318: \ttitem{dispatchEvent()}, dequeues the event \verb+E+ that is first in
319: \verb+PropagationQueue+, performs the narrowing on some domain
320: variable \verb+X+ it specifies, and calls \verb+enqueueCtr(C,E)+ for
321: all constraints in \verb+X+'s constraint list.
322: \end{itemize}
323: If the functions \verb+dispatchEvent()+ and \verb+dispatchCtr()+ can
324: both be executed, the former will have higher priority.
325: \subsubsection{The Active System: An Example.}
326: The easiest way to see how the above described data structures
327: interact is by looking at an example. Assume that the state of the
328: kernel is as in Fig.~\ref{fig:kernel}. There is no propagation event
329: to be performed, but the demon \verb+D2+ of constraint \verb+C2+, the
330: \verb+element/3+ constraint, should be woken up. The kernel calls the
331: function \verb+dispatchCtr()+, which removes \mtt{D2} from
332: \verb+ReadyQueue+ and activates its filtering algorithm. A first
333: method, \verb+M1+, generates a propagation event, \verb+E1+, which
334: restricts \verb+X+ to take a value inside the range \verb+1..4+.
335: Equally, a second method, \verb+M2+, generates a propagation event,
336: \verb+E2+, which restricts \verb+Y+ to take a value inside the set
337: \verb+{2,3,4}+. Also, a third method, \verb+M3+, generates a
338: propagation event, \verb+E3+, which restricts \verb+X+ from taking the
339: value \verb+4+\footnote{Since the value \texttt{8} on position
340: \texttt{4} in the list is not in the domain of \texttt{Y}.}. When the
341: filtering algorithm of \verb+D2+ has finished, the kernel notices that
342: \verb+PropagationQueue+ has changed to contain the propagation events
343: \verb+E1+, \verb+E2+ and \verb+E3+. The kernel calls the function
344: \verb+dispatchEvent()+ three times which does the following each time:
345: \begin{itemize}
346: \item The first propagation event in \verb+PropagationQueue+ is
347: dequeued.
348: \item The narrowing of the variable specified by the propagation event
349: is performed by the kernel.
350: \item The demons of the constraints \verb+C1+ and \verb+C2+, that are
351: supposed to wake up due to the narrowing performed, are put in
352: \verb+ReadyQueue+ by calling the function \verb+enqueueCtr()+
353: twice.
354: \end{itemize}
355: When \verb+PropagationQueue+ is empty, the kernel starts over by
356: calling the function \verb+dispatchCtr()+ again. This is repeated
357: until both queues are empty. When this is the case, the control of
358: execution is given back to the Prolog level. In our case, this means
359: that labeling takes place which will fix a variable and therefore
360: trigger more propagation.
361:
362: \section{Trace Structure}\label{sect:trace}
363: In this section, the trace structure and the information it contains
364: is presented. We start by introducing our ideas about how to identify
365: the different entities in a \clpfd\ program such as constraints and
366: variables. Following that, the trace events are presented together
367: with some examples. Finally, our implementation in \sicstus\ Prolog is
368: described.
369: \subsection{Representing and Identifying Entities in \clpfd\
370: Programs}\label{sect:tracerep}
371: \subsubsection{Identifiers.}
372: The \dfn{id of a constraint} is a Prolog atom created by prepending
373: the atom \verb+ctr_+ to the source code functor and appending a
374: unique\footnote{Unique for the specific type of constraint.} number to
375: this. The \dfn{id of a variable} is a Prolog atom of the form
376: \verb+fdvar_N+ where \verb+N+ is a unique number. For example, the
377: following identifiers are produced by Ex.~\ref{ex:traceme} where
378: \verb+C0+, \verb+C1+ and \verb+C2+ are the constraints posted on lines
379: \verb+(2)+, \verb+(3)+ and \verb+(4)+ respectively: {\tracesize
380: \begin{quotetab}
381: \{\=\mtt{X \mapsto fdvar\_1,Y \mapsto fdvar\_2,V1 \mapsto
382: fdvar\_3,V2 \mapsto fdvar\_4,} \\
383: \>\mtt{C0 \mapsto ctr\_domain\_1,C1 \mapsto
384: ctr\_all\_different\_1,C2 \mapsto ctr\_element\_1}\}
385: \end{quotetab}
386: }
387: \subsubsection{Constraint Representation.}
388: \label{sect:conrep}
389: A constraint is represented similarly to its source code
390: representation. It has the same functor atom and structure, with all
391: variables replaced by their given identifiers. In Ex.~\ref{ex:traceme}
392: for instance, the constraint {\tracesize
393: \begin{quote}
394: \verb+all_different([X,Y,3,V1,8,V2])+
395: \end{quote}}
396: is represented as {\tracesize
397: \begin{quote}
398: \verb+all_different([fdvar_1,fdvar_2,3,fdvar_3,8,fdvar_4])+.
399: \end{quote}}
400: \subsubsection{Location of Variables.}
401: It is not enough to be able to identify variables by their
402: identifiers. While this allows to distinguish different variables, it
403: will not make it possible to, within one constraint, uniquely
404: determine a specific occurrence among several of the same variable.
405:
406: We have solved this with what we call a \dfn{path}. A path uniquely
407: determines a position or a list of positions in a constraint. When
408: referencing arguments of a constraint, for example when displaying a
409: variable's domain, a path referring to that variable is given instead
410: of its id. This path must always have a context, a corresponding
411: constraint, to be interpreted in.
412:
413: A path is represented as a Prolog list containing (lists of) fixed
414: values or other paths. The first element of a path identifies the
415: topmost position in the corresponding constraint. For example, any
416: path referring to some position(s) in the \verb+element/3+ constraint
417: in Ex.~\ref{ex:traceme} has one of the integers 1, 2, 3 or one of the
418: lists \verb+[1,2]+, \verb+[1,3]+, \verb+[2,3]+, \verb+[1,2,3]+ as
419: first element. Lines a and b in Table~\ref{ex:path1} show two of
420: these in paths with only one element and the position(s) they refer
421: to.
422:
423: The i+1:st element of a path refers to some position(s)
424: \standout{inside} whatever the i:th element refers to. This means that
425: the position(s) the i:th element refers to must be a compound term or
426: a list of compound terms. Line c in Table~\ref{ex:path1} illustrates
427: this. This example also introduces one more symbol in the path term;
428: the \verb+#+ sign. It is used whenever the term(s) we refer to is
429: inside a list (a non-list compound term would not have a preceding
430: \verb+#+ sign).
431:
432: Some more syntax is needed in order for the path to be more expressive
433: and compact. First of all, we will use \verb+[*]+ to express ``all
434: positions'' of a compound term. It may also be useful to identify
435: \standout{almost} all positions in a compound term. We will use the
436: \verb+\+ sign for this purpose, denoting set subtraction\footnote{In
437: our case, the sets are lists.}. Line d in Table~\ref{ex:path1}
438: illustrates this.
439:
440: In addition to the above, we may apply functions to the entities
441: referred to by a path. \verb+P/F+ has the meaning that the function
442: \verb+F+ is applied to each entity referred to by the path
443: \verb+P+. Possible values for \verb+F+ are, among others, \verb+min+,
444: \verb+max+ and \verb+length+. Table~\ref{ex:path2} shows some examples
445: of this. If \verb+P+ refers to a list of positions of size \mexp{n},
446: \verb+P/F+ returns a list of values of size \mexp{n}. However, one
447: element lists are simplified as shown on lines a and b in
448: Table~\ref{ex:path2}.
449:
450: \tabbegin{h}
451: \caption{The positions marked with gray are the positions referred to
452: by the corresponding path.}
453: \begin{tabular}{lll|lll}
454: \hlineskip
455: & \tabhead{Path} & \tabhead{Position(s)} & & \tabhead{Path} &
456: \tabhead{Position(s)} \\
457: \hlineskip
458: a. & \verb+[[1,3]]+ & \texttt{element(\greybox{X},[2,4,3,8],\greybox{Y})} &
459: c. & \verb+[2,#[1,2]]+ &
460: \texttt{element(X,[\greybox{2},\greybox{4},3,8],Y)} \\
461: b. & \verb+[2]+ & \texttt{element(X,\greybox{[2,4,3,8]},Y)} &
462: d. & \verb+[2,#[*]]\[2,#1]+ &
463: \texttt{element(X,[2,\greybox{4},\greybox{3},\greybox{8}],Y)} \\
464: \hlineskip
465: \end{tabular}
466: \label{ex:path1}
467: \tabend
468: \tabbegin{h}
469: \caption{Functions applied to paths. The state of the variables is as
470: in Fig.~\ref{fig:kernel}, i.e.\ before the execution of line
471: \texttt{(4)} in Ex.~\ref{ex:traceme}.}
472: \begin{tabular}{llll}
473: \hlineskip
474: & \tabhead{P/F} & \tabhead{Constraint} & \tabhead{Value(s)} \\
475: \hlineskip
476: a. & \verb+[1]/length+ & \verb+all_different([X,Y,3,V1,8,V2])+ &
477: \verb+6+ \\
478: b. & \verb+[1]/min+ & \verb+element(X,[2,4,3,8],Y)+ & \verb+1+ \\
479: c. & \verb+[[1,3]]/max+ & \verb+element(X,[2,4,3,8],Y)+ & \verb+[6,6]+ \\
480: \hlineskip
481: \end{tabular}
482: \label{ex:path2}
483: \tabend
484: \subsection{Trace Events}
485: Now, it is time to present the trace events. They are organized in
486: chunks, each chunk containing trace events for a specific purpose. The
487: chunks of trace events are presented in tables followed by examples
488: generated by Ex.~\ref{ex:traceme}.
489:
490: All trace events have an \verb+EventId+ attribute, an increasing
491: number. We will often identify them by the value of this attribute and
492: simply call it \dfn{id}. The \verb+EventId+ is always the first
493: attribute of the Prolog fact. Furthermore, when we talk about a whole
494: block of trace events, we mean the opening and closing trace events of
495: the block and all trace events in between. For example, a \verb+prune+
496: block includes the trace events \verb+begin_prune+ and
497: \verb+end_prune+, and all trace events between these.
498:
499: Within our illustrations of Ex.~\ref{ex:traceme}, since the constraint
500: representations occur very frequently, we will use the following short
501: notations: {\tracesize
502: \begin{itemize}
503: \item \verb+ALLDIFF = all_different([fdvar_1,fdvar_2,3,fdvar_3,8,fdvar_4])+
504: \item \verb+ELEMENT = element(fdvar_1,[2,4,3,8],fdvar_2)+
505: \end{itemize}
506: } Also, when mentioning variables, we will use the variable
507: name from the source code of Ex.~\ref{ex:traceme}, even if the trace
508: events contain the given identifier.
509: \subsubsection{Control of Execution.}
510: In this section, trace events describing the control of execution are
511: presented. This concerns things like new constraint posting, demon
512: enqueuing and demon wakening. The trace events that describe these
513: actions are presented in Table~\ref{ev:exec}.
514:
515: \tabbegin{h}
516: \caption{Control of execution trace events.}
517: \evtabbegin{2.7}{2.1}{4.8}
518:
519: \verb+begin_new_ctr+ & \verb+EventId+, \verb+ConstraintId+,
520: \verb+Constraint+ & Generated when a new constraint is to be added to
521: the system, i.e.\ when entering the \verb+connectCtr()+
522: function. \verb+ConstraintId+ and \verb+Constraint+ are respectively
523: the constraint's id and internal representation as explained above. \\
524: \hlineskip
525:
526: \verb+end_new_ctr+ & \verb+EventId+, \verb+Result+ & Generated when
527: demons for the constraint have been created and possible initial
528: propagation has finished, i.e.\ just before exiting the
529: \verb+connectCtr()+ function. \verb+Result+ denotes the result of
530: adding the new constraint. \mtt{Result \in
531: \{fail,delay,entail\}} \\\hlineskip
532:
533: \verb+new_demon+ & \verb+EventId+, \verb+DemonId+\footnote{Identifiers
534: for demons are generated similar to identifiers for constraints.},
535: \verb+DemonType+, \verb+WakeConds+, \verb+Constraint+ & Generated when
536: a new demon is added to the system. This happens inside the
537: \verb+connectCtr()+ function. \verb+DemonType+ is a descriptive atom
538: of the demon. \verb+WakeConds+ is a list of pairs
539: (\verb+VPath+,\verb+Condition+) where \verb+VPath+ is a path to some
540: variable(s) and \mtt{Condition \in \{min,max,minmax,val,dom\}}. \\
541: \hlineskip
542:
543: \verb+push_demon+ & \verb+EventId+, \verb+DemonId+, \verb+DemonType+ &
544: Generated when a wake-up condition for at least one variable has been
545: fulfilled. This corresponds to the function \verb+enqueueCtr()+.\\
546: \hlineskip
547:
548: \verb+begin_wake_demon+ & \verb+EventId+, \verb+DemonId+,
549: \verb+DemonType+ & Generated when a demon is to wake up for
550: propagation. This corresponds to entering the \verb+dispatchCtr()+
551: function, after dequeuing the topmost demon from \verb+ReadyQueue+.\\
552: \hlineskip
553:
554: \verb+end_wake_demon+ & \verb+EventId+, \verb+Result+ & Generated when
555: a demon has finished all propagation. This corresponds to exiting the
556: \verb+dispatchCtr()+ function, after the filtering algorithm has
557: finished.\\
558: \hlineskip \evtabend
559: \label{ev:exec}
560: \tabend
561:
562: Lines \verb+(3)+ and \verb+(4)+ in Ex.~\ref{ex:traceme} post two
563: constraints to the system. This gives rise to the following trace
564: events to be created\footnote{There are several gaps, identified by
565: `\ldots', since we only present the trace events relevant to the
566: control of execution at this stage.}:
567: {\tracesize
568: \begin{verbatim}
569: begin_new_ctr(9,ctr_all_different_1,ALLDIFF)
570: new_demon(10,ctr_all_different_1,all_different_1,[[1,#[*]]-val],
571: ALLDIFF)
572: begin_wake_demon(11,ctr_all_different_1,all_different_1)
573: ...
574: end_wake_demon(21,delay)
575: end_new_ctr(22,delay)
576: begin_new_ctr(23,ctr_element_1,ELEMENT)
577: ...
578: begin_new_ctr(25,ctr_in_1,fdvar_1 in 1..4)
579: ...
580: end_new_ctr(32,entail)
581: new_demon(33,ctr_element_1,element_3,
582: [[1]-dom,[2,#[*]]-minmax,[3]-minmax],ELEMENT)
583: begin_wake_demon(34,ctr_element_1,element_3)
584: ...
585: end_wake_demon(57,delay)
586: end_new_ctr(58,delay)
587: \end{verbatim}
588: } The first five trace events are created due to the posting of the
589: constraint \verb+all_different/1+. This gives rise to the creation of
590: a new demon (id \verb+10+) and the wakening of that demon (id:s
591: \verb+11+ and \verb+21+). The last one of these trace events (id
592: \verb+22+) contains the result \verb+delay+, meaning that the
593: constraint will not wake up again until the state of at least one of
594: its variables changes. Moving on, the \verb+element/3+ constraint is
595: introduced in much the same way. The difference is the creation of an
596: internal \verb+in/1+ constraint (id:s \verb+25+ and \verb+32+) to
597: ensure that \verb+X+ takes a value in the range \verb+1..4+.
598: \subsubsection{Domain Modification.}
599: Now, we introduce trace events describing domain modification, i.e.\
600: pruning of variables. Such trace events are presented in
601: Table~\ref{ev:dmod}.
602: \tabbegin{h}
603: \caption{Domain modification trace events.}
604: \evtabbegin{2.1}{1.8}{3.9}
605:
606: \verb+begin_prune+ & \verb+EventId+, \verb+Intention+,
607: \verb+Constraint+ & Generated when some pruning is about to occur,
608: corresponds to actions inside the \verb+dispatchCtr()+
609: function. \verb+Intention+ is a Prolog fact with information about the
610: intended pruning\footnote{Since some values might have been removed
611: already, the actual values removed may be different from the intended
612: pruning.}.\\\hlineskip
613:
614: \verb+end_prune+ & \verb+EventId+, \verb+Result+ & Generated when some
615: pruning has been carried out. \verb+Result+ denotes the result of all
616: domain narrowings performed inside the block. \mtt{Result = succeed}
617: iff all prunings inside the block was successful, otherwise
618: \mtt{Result = fail}.\\\hlineskip
619:
620: \verb+prune+ & \verb+EventId+, \verb+PrunedVars+, \verb+Pruning+,
621: \verb+Constraint+, \verb+Result+ & Generated when some domain
622: narrowing occurs. This corresponds to the \verb+enqueueEvent()+
623: function. \verb+PrunedVars+ is a path referring to the positions of
624: the pruned variables. \verb+Pruning+ is a Prolog fact with information
625: about the actual pruning. \verb+Result+ denotes the result,
626: \verb+fail+ or \verb+succeed+, of the pruning. \\\hlineskip
627:
628: \verb+before_prune+, \verb+after_prune+ & \verb+EventId+,
629: \verb+PrunedVars+, \verb+Domains+, \verb+Constraint+ & These are
630: generated before (after) a \verb+prune+ trace event. They contain
631: domain information about the pruned variables before (after) value
632: removal. \verb+Domains+ is a list of domains in the \sicstus\ Prolog
633: format\footnote{For example, \texttt{[[3|5],[7|7]]} denotes the set
634: \texttt{\symbol{`\{}3,4,5,7\symbol{`\}}}, see the \clpfd\ section
635: of~\cite{bib:sicstus} for details.}. \\\hlineskip
636:
637: \verb+fail+ & \verb+EventId+, \verb+Constraint+ & Generated when
638: inconsistency is noticed due to some non-fulfilled necessary condition
639: of a constraint. \\\hlineskip
640:
641: \evtabend
642: \label{ev:dmod}
643: \tabend
644:
645: For Ex.~\ref{ex:traceme}, the following trace events are added due to
646: the posting of the \verb+all_different/1+ constraint on line
647: \verb+(3)+:
648: {\tracesize
649: \begin{verbatim}
650: begin_prune(14,remove_value(3),ALLDIFF)
651: ...
652: before_prune(16,[1,#[1,2,4,6]],[[[1|6]],[[1|6]],[[1|6]],[[1|6]]],
653: ALLDIFF)
654: prune(17,ctr_all_different_1,[1,#[1,2,4,6]],remove_value(3),ALLDIFF,
655: succeed)
656: after_prune(18,[1,#[1,2,4,6]],[[[1|2],[4|6]],[[1|2],[4|6]],
657: [[1|2],[4|6]],[[1|2],[4|6]]],ALLDIFF)
658: end_prune(19,succeed)
659: \end{verbatim}
660: }
661: These will occur between the trace events with id:s \verb+11+ and
662: \verb+21+, the wakening of the \verb+all_different/1+ demon. The first
663: trace event contains information about the intended domain
664: narrowing. In this case the value \verb+3+ is to be removed from some
665: variables. The path to these variables is shown in the following three
666: trace events. The first and last of these (id:s \verb+16+ and
667: \verb+18+) contain domain information about the variables before and
668: after pruning. The middle trace event (id \verb+17+) contains
669: information about the actual pruning. Finally, the trace event with id
670: \verb+19+ contains the result of the pruning. Since it did not produce
671: any empty domains, the result is \verb+succeed+.
672:
673: The posting of the \verb+element/3+ constraint generates the following
674: trace events containing information about pruning the variable
675: \verb+X+:
676: {\tracesize
677: \begin{verbatim}
678: begin_prune(50,remove_values([[4|4]]),ELEMENT)
679: ...
680: before_prune(52,[1],[[[1|2],[4|4]]],ELEMENT)
681: prune(53,ctr_element_1,[1],remove_value(4),ELEMENT,succeed)
682: after_prune(54,[1],[[[1|2]]],ELEMENT)
683: end_prune(55,succeed)
684: \end{verbatim}
685: }
686: \subsubsection{Explanations.}\label{sect:expl}
687: The trace events presented in this section provide
688: \dfn{explanations}~\cite{bib:jus01} for other trace events, i.e.\
689: reasons for why certain actions are taken by the solver. These trace
690: events are presented in Table~\ref{ev:expl}.
691:
692: \tabbegin{h}
693: \caption{Explanation trace events. All but
694: \texttt{push\_demon\_because} contain the same type of information.}
695: \evtabbegin{3}{2.1}{5.1}
696:
697: \verb+push_demon_because+ & \verb+EventId+, \verb+Variables+,
698: \verb+Condition+, \verb+Constraint+ & Generated before a
699: \verb+push_demon+ trace event. \verb+Condition+ is a property
700: fulfilled by the variables referred to by the path
701: \verb+Variables+. \mtt{Condition \in \{min,max,minmax,val,dom\}}.
702: \\\hlineskip
703:
704: \verb+prune_because+, \verb+fail_because+, \verb+new_ctr_because+ &
705: \verb+EventId+, \verb+ConstraintId+, \verb+Explanation+,
706: \verb+Constraint+ & Generated before the
707: corresponding\footnote{Trivially, a \texttt{prune\_because} trace
708: event is for example generated before some trace events describing
709: domain narrowing.} trace events. \verb+Explanation+ is an explanation
710: or a reason for why the corresponding action occurs.\\\hlineskip
711:
712: \evtabend
713: \label{ev:expl}
714: \tabend
715:
716: First of all, we will make clear what we mean with explanations: An
717: explanation \mexp{e} for some kernel action \mexp{a} is a logical
718: formula \mexp{e} such that \mexp{e \Rightarrow a}, i.e.\ if \mexp{e}
719: holds, \mexp{a} will occur. In Prolog, we represent an explanation
720: with a pair, \verb+N-CondList+, where \verb+N+ is an integer and
721: \verb+CondList+ is a list of \verb+cond(M,Pa,PL)+ terms. An
722: explanation \mexp{e =} \verb+N-CondList+ holds iff at least \verb+N+
723: of the \verb+cond/3+ terms in \verb+CondList+ hold. Each \verb+cond/3+
724: term contains an integer \verb+M+, a path \verb+Pa+ and a list of
725: properties \verb+PL+. The property on index \mexp{i} in \verb+PL+ is
726: associated with the entity on index \mexp{i} in the list of positions
727: referred to by \verb+Pa+. For example, assume that \verb+Pa+ $=$
728: \verb+[[1,3]]+, \verb+PL+ $=$ \verb+[eq(2),neq(3)]+ and that \verb+Pa+
729: is associated with the \verb+element/3+ constraint in
730: Ex.~\ref{ex:traceme}. Then \verb+X+ is associated with \verb+eq(2)+
731: and \verb+Y+ is associated with \verb+neq(3)+. When \verb+PL+ contains
732: a single property, it is associated with each entity referred to by
733: \verb+Pa+. Also, the list structure is skipped and \verb+PL+ will
734: denote the value of the single property. Possible properties in
735: \verb+PL+ are, among others, \verb+eq(I)+, \verb+neq(I)+,
736: \verb+inset(S)+ and \verb+notinset(S)+ where \verb+I+ is an integer
737: and \verb+S+ is a finite set of integers. A \verb+cond/3+ term holds
738: iff at least \verb+M+ of the entities referred to by \verb+Pa+ fulfill
739: their respective properties.
740:
741: %\tabbegin{h}
742: %\caption{Some possible properties for the entity \texttt{E}.}
743: %\begin{tabular}{ll}
744: %\hlineskip
745: %\tabhead{Property} & \tabhead{Meaning} \\
746: %\hlineskip
747: %\verb+eq(I)+ & \verb+E+ can take the value \verb+I+. \\
748: %\verb+neq(I)+ & \verb+E+ cannot take the value \verb+I+. \\
749: %\verb+inset(S)+ & \verb+E+ can take a value in the finite set \verb+S+. \\
750: %\verb+notinset(S)+ & \verb+E+ cannot take a value in the finite set \verb+S+. \\
751: %\hlineskip
752: %\end{tabular}
753: %\label{tab:conds}
754: %\tabend
755:
756: Now, let us give an illustrative example. Assume that
757: \begin{quote}
758: \mexp{e =} \verb+1-[cond(1,[1,#3],eq(3))]+
759: \end{quote}
760: explains the solver action \mexp{a}. Also, assume that \mexp{e} is
761: associated with a pruning generated due to the \verb+all_different/1+
762: constraint in Ex.~\ref{ex:traceme}. This gives us the information that
763: \mexp{a} occurs since at least one of the \verb+cond/3+ terms
764: holds. For the only one, it holds since at least one of the entities
765: referred to by \verb+[1,#3]+ can take the value \verb+3+,
766: \verb+eq(3)+. In our case, this is the position marked with gray in
767: \texttt{all\_different([X,Y,\greybox{3},V1,8,V2])}. In order for
768: \mexp{a} not to occur, the least thing one must do is to change the
769: value on that position to some value distinct from \verb+3+. Actually,
770: this explanation occurs in the trace event {\tracesize
771: \begin{verbatim}
772: prune_because(15,ctr_all_different_1,1-[cond(1,[1,#3],eq(3))],ALLDIFF).
773: \end{verbatim}
774: }
775: Hence, \mexp{e} is an explanation for removing the value \verb+3+ from
776: all variables in the \verb+all_different/1+ constraint.
777:
778: The following are some more explanation trace events from
779: Ex.~\ref{ex:traceme}:
780: {\tracesize
781: \begin{verbatim}
782: new_ctr_because(24,ctr_element_1,1-[cond(1,[2]/length,eq(4))],ELEMENT)
783: ...
784: prune_because(51,ctr_element_1,1-[cond(1,[3],notinset([[8|8]]))],ELEMENT)
785: \end{verbatim}
786: } The first one is generated before the \verb+begin_new_ctr+
787: trace event with id \verb+25+. It contains an explanation for posting
788: the \verb+X in 1..4+ constraint inside the creation of the
789: \verb+element/3+ constraint. The explanation is that the length of the
790: list on the second position in the constraint is \verb+4+.
791:
792: Similarly, the id of the last one tells us that it is generated before
793: the \verb+before_prune+ trace event with id \verb+52+. It contains an
794: explanation for pruning the variable \verb+X+. This too occurs inside
795: the creation of the \verb+element/3+ constraint. The explanation is
796: that the third argument of the constraint, the variable \verb+Y+, does
797: not intersect with the set consisting of the single value
798: \verb+8+. Due to this, \verb+X+ cannot take the value \verb+4+.
799:
800: For some solver actions, there are several different reasons for why
801: they occur. In order to show this, we need to introduce one more
802: example.
803:
804: \begin{ex05}
805: \begin{verbatim}
806: explain_me :- (1)
807: domain([X1],1,6), (2)
808: domain([X2,X3,X4,X5],1,2), (3)
809: all_distinct([X1,X2,X3,X4,X5]). (4)
810: \end{verbatim}
811: \caption{A failing \texttt{all\_distinct/1} constraint.}
812: \label{ex:explainme}
813: \end{ex05}
814:
815: The \verb+all_distinct/1+ constraint on line \verb+(4)+ in
816: Ex.~\ref{ex:explainme} uses the complete filtering algorithm of
817: R\'egin~\cite{Reg94}. When, during the posting of that constraint, its
818: demon is woken up, it will produce a failure since the variables
819: \verb+X2+, \verb+X3+, \verb+X4+ and \verb+X5+ are all in the range
820: \verb+1..2+. For this failure, we generate the following explanation:
821: \begin{quote}
822: \verb+1-[cond(all,[1,#[2,3,4,5]],inset([[1|2]]))]+
823: \end{quote}
824: where \verb+all+ is a keyword for identifying all entities referred to
825: by the associated path. By looking at this explanation, we conclude
826: that, in order for the failure not to occur, we need to enlarge the
827: domains of any two of the variables \verb+X2+, \verb+X3+, \verb+X4+
828: and \verb+X5+ with at least two distinct values. We see this since
829: there are $4$ variables taking values in a set of integers of size $2$
830: and $4-2=2$.
831: \subsubsection{Filtering Algorithms.}
832: The trace events presented in this section describe the execution of
833: the filtering algorithms associated with the demons. Since each
834: filtering algorithm is built up by a set of methods, information about
835: each active method is needed. Table~\ref{ev:filter} presents the
836: relevant trace events. \tabbegin{h}
837: \caption{Filtering algorithms trace events.}
838: \evtabbegin{2}{1.8}{3.8}
839:
840: \verb+begin_method+ & \verb+EventId+, \verb+MethodName+ & Generated
841: when a demon's filtering algorithm activates a specific
842: method. \verb+MethodName+ is a Prolog atom with a name corresponding
843: to the consistency rule of the associated constraint.\\\hlineskip
844:
845: \verb+end_method+ & \verb+EventId+, \verb+Result+ & Generated when a
846: specific method has finished. \verb+Result+ denotes the result of the
847: prunings carried out inside the block. Similar to the \verb+Result+
848: attribute in the \verb+end_prune+ trace event.\\\hlineskip
849:
850: \verb+info_method+ & \verb+EventId+, \verb+InfoName+, \verb+Info+,
851: \verb+Constraint+ & Generated inside a specific method. Contains more
852: detailed information about entities involved in the filtering
853: algorithm. \verb+InfoName+ is a Prolog atom with a descriptive name of
854: the provided information. \verb+Info+ is a pair \verb+P-E+ containing
855: the extra information, \verb+P+ is a path referring to the entity
856: \verb+E+. \\\hlineskip
857:
858: \evtabend
859: \label{ev:filter}
860: \tabend
861:
862: Each \verb+prune+ block is surrounded by a \verb+method+ block, and
863: possibly preceded by an \verb+info_method+ trace event. For the first
864: example concerning domain modification, the following trace events are
865: added:
866: {\tracesize
867: \begin{verbatim}
868: begin_method(12,propagate_ground_variable)
869: info_method(13,ground_variable,[1,#3]-3,ALLDIFF)
870: ...
871: end_method(20,succeed)
872: \end{verbatim}
873: } By looking at the id:s, we see that they are generated
874: before and after the \verb+prune+ block describing the removal of the
875: value \verb+3+ from the variables \verb+X+, \verb+Y+, \verb+V1+ and
876: \verb+V2+. The \verb+begin_method+ trace event contains a name of the
877: active method. In this case, \verb+propagate_ground_variable+ denotes
878: the method that removes a ground value from all non-ground domain
879: variables in the \verb+all_different/1+ constraint. Following that,
880: the \verb+info_method+ trace event contains more detailed information
881: about the actual entities involved in the method. More specifically,
882: it tells us that the ground variable is on the position referred to by
883: \verb+[1,#3]+ and its value is \verb+3+. Finally, the
884: \verb+end_method+ trace event contains the result, \verb+succeed+, of
885: the whole \verb+method+ block. The result will be \verb+fail+ iff at
886: least one failure inside the block is detected, otherwise
887: \verb+succeed+.
888:
889: The second example concerning domain modification, the one associated
890: with the \verb+element/3+ constraint, is surrounded by the following
891: \verb+method+ block:
892: {\tracesize
893: \begin{verbatim}
894: begin_method(49,prune_x)
895: ...
896: end_method(56,succeed)
897: \end{verbatim}
898: }
899: %For this one, no further \verb+info_method+ trace event is provided.
900: \subsection{Implementation}\label{sect:impl}
901: The described trace structure has been implemented in a research
902: branch of the \clpfd\ solver in \sicstus\ Prolog version 3.9.
903:
904: Each trace event is represented by an abstract datatype (ADT) in C.
905: Complex information, such as compound terms and lists, is represented
906: using C strings. Each ADT has creation and deletion primitives as well
907: as a primitive for converting the information to a Prolog fact.
908:
909: On the Prolog side, it is possible to create and access the trace
910: events through some predicates. For the creation, each trace event
911: (with two exceptions\footnote{The trace events \texttt{push\_demon}
912: and \texttt{push\_demon\_because} are created at a central place
913: within the C part of the kernel.}) have a corresponding constructor
914: predicate. For retrieving, a predicate
915: \verb|get_events(+Selector, -TraceEvents)| is
916: available. \verb+Selector+ is an integer, an atom or a compound term
917: specifying a set of trace events. \verb+TraceEvents+ is a list of
918: trace events corresponding to \verb+Selector+.
919:
920: %Examples include \verb+all+, \verb+first+, \verb+last+, \verb+1+ and
921: %\verb+3-5+ where integers denote trace event id:s.
922: %The constraint kernel has been tagged with code to create trace events
923: %at different places. Some trace events are generated at only one
924: %central place while others are generated at several places. Generally,
925: %trace events concerning demon enqueuing and demon wakening are
926: %centralized. Other trace events concerning domain modification,
927: %description of the filtering algorithms etc.\ are created at each
928: %specific constraint. Currently, the tagged global constraints include
929: %\verb+assignment/[2,3]+, \verb+circuit/[1,2]+, \verb+element/3+,
930: %\verb+scalar_product/4+, \verb+all_different/[1,2]+ and
931: %\verb+all_distinct/[1,2]+.
932:
933: \section{Discussion}\label{sect:relwork}
934: Tracing \clpfd\ programs is still an open area. In our case, more
935: testing is needed in order to evaluate the trace model. This includes
936: building debugging tools, using the different kinds of information the
937: trace provides.
938:
939: One interesting tool to build would be a search-tree visualizer such
940: as the Oz Explorer~\cite{bib:schulte97} by Schulte. Such a tool would
941: explore the information in the trace concerning the control of
942: execution aspect. Also, as was done for the Oz Explorer, one could
943: connect to it other tools using a plug-in scheme, displaying various
944: information concerning other aspects at the nodes of the
945: search-tree. An example of such a tool for the Oz Explorer is the
946: Constraint Investigator~\cite{bib:mueller00} by M\"uller.
947:
948: Another tool, exploring the information concerning the domain
949: modification aspect, would be a variable domain visualizer. Domains
950: could for instance be visualized in a way similar to as
951: in~\cite{bib:car00}.
952:
953: The information concerning the declarative aspect could be used by a
954: tool for solving over-constrained problems. Explanations would help to
955: point out the set of inconsistent constraints. Jussien and Ouis
956: presented a tool like this in~\cite{bib:jo01}.
957:
958: For educational purposes, a tool that provides information about
959: filtering algorithms would be useful. Such a tool could connect the
960: consistency rules of the constraints with the different methods in the
961: corresponding filtering algorithms.
962:
963: As a first use of the trace structure, we have implemented an
964: extension to the Prolog debugger in \sicstus. At the usual breakpoints
965: of the debugger, it is possible to ask queries about the trace and the
966: entities in it. The user may for example display certain trace events,
967: ask queries about domain variables and generate explanations for
968: specific domain narrowings.
969: \section{Conclusion}\label{sect:concl}
970: In this paper, we presented new ideas in the area of tracing \clpfd\
971: programs. In addition to providing information about control of
972: execution and domain modification, we also provide information
973: concerning the declarative and procedural aspects. We did this by
974: incorporating the idea of explanations in the trace, as well as coming
975: up with new ideas about tracing filtering algorithms. By doing this,
976: we have obtained a link between the consistency rules and the
977: filtering algorithms in constraint solving.
978:
979: Furthermore, we presented some new ideas about how to present the
980: trace, both regarding the structure and the information contained.
981: This includes building the trace as a nested block structure, as well
982: as using a path for identifying the different entities in a \clpfd\
983: program.
984:
985: Implementing the trace structure in a high-end system like \sicstus\
986: is not an easy task. This is especially true for the task of adapting
987: filtering algorithms to generate explanations. Sometimes, the added
988: overhead it meant to provide the information needed for sharp
989: explanations was too large. In this case, some \dfn{approximation
990: explanation}\footnote{An explanation that is true but not necessarily
991: the one that expresses the least dependency.} has been used. In the
992: long run, providing explanations probably means that filtering
993: algorithms need to be changed in order to, more naturally, provide the
994: necessary information.
995:
996: \begin{thebibliography}{10}
997:
998: \bibitem{bib:coc97}
999: M.~Carlsson, G.~Ottosson, and B.~Carlson.
1000: \newblock An {O}pen-{E}nded {F}inite {D}omain {C}onstraint {S}olver.
1001: \newblock In H.~Glaser, P.~Hartel, and H.~Kucken, editors, {\em Programming
1002: Languages: Implementations, Logics, and Programming}, volume 1292 of {\em
1003: LNCS}, pages 191--206. Springer-Verlag, 1997.
1004:
1005: \bibitem{bib:car00}
1006: M.~Carro and M.~Hermenegildo.
1007: \newblock Tools for {C}onstraint {V}isualization: {T}he {VIFID/TRIFID} {T}ool.
1008: \newblock In P.~Deransart, M.~Hermenegildo, and J.~Ma{\l}uszy\'nski, editors,
1009: {\em Analysis and {V}isualisation {T}ools for {C}onstraint {P}rogramming},
1010: number 1870 in LNCS, chapter~10. Springer Verlag, 2000.
1011:
1012: \bibitem{bib:duc99}
1013: M.~Ducass\'{e}.
1014: \newblock Opium: {A}n {E}xtendable {T}race {A}nalyser for {Prolog}.
1015: \newblock {\em The Journal of Logic Programming}, 39:177--223, 1999.
1016:
1017: \bibitem{bib:sicstus}
1018: M.~Carlsson et~al.
1019: \newblock {\em {SICStus} {Prolog} User's Manual}.
1020: \newblock Swedish Institute of Computer Science, release 3 edition, 1995.
1021: \newblock {ISBN} 91-630-3648-7.
1022:
1023: \bibitem{bib:jus01}
1024: N.~Jussien.
1025: \newblock e-constraints: explanation-based {C}onstraint {P}rogramming.
1026: \newblock In {\em CP01 Workshop on User-Interaction in Constraint
1027: Satisfaction}, Paphos, Cyprus, 2001.
1028:
1029: \bibitem{bib:jo01}
1030: N.~Jussien and S.~Ouis.
1031: \newblock User-friendly explanations for constraint programming.
1032: \newblock In {\em ICLP'01 11th Workshop on Logic Programming Environments},
1033: Paphos, Cyprus, 1 December 2001.
1034:
1035: \bibitem{bib:lab00}
1036: F.~Laburthe.
1037: \newblock {CHOCO}: Implementing a {CP} kernel.
1038: \newblock In {\em Proc. TRICS: Techniques foR Implementing Constraint
1039: programming Systems}, pages 71--85, Singapore, 2000.
1040: \newblock CP2000 workshop.
1041:
1042: \bibitem{bib:lddj01a}
1043: L.~Langevine, P.~Deransart, M.~Ducass\'e, and E.~Jahier.
1044: \newblock Prototyping {CLP(FD)} tracers: a trace model and an experimental
1045: validation environment.
1046: \newblock In A.~Kusalik, editor, {\em Proceedings of the Eleventh Workshop on
1047: Logic Programming Environments (WLPE'01)}, Paphos, Cyprus, 1 December 2001.
1048:
1049: \bibitem{bib:mei95}
1050: M.~Meier.
1051: \newblock Debugging {C}onstraint {P}rograms.
1052: \newblock In {\em Principles and Practice of Constraint Programming}, volume
1053: 976 of {\em LNCS}, pages 204--221. Springer-Verlag, 1995.
1054:
1055: \bibitem{bib:mueller00}
1056: T.~M\"uller.
1057: \newblock Practical {I}nvestigation of {C}onstraints with {G}raph {V}iews.
1058: \newblock In R.~Dechter, editor, {\em Proceedings of the Sixth International
1059: Conference on Principles and Practice of Constraint Programming}, volume 1894
1060: of {\em Lecture Notes in Computer Science}, pages 320--336, Singapore, 2000.
1061: Springer-Verlag.
1062:
1063: \bibitem{Reg94}
1064: J.-C. R\'egin.
1065: \newblock A filtering algorithm for constraints of difference in {CSPs}.
1066: \newblock In {\em Proc. of the Twelfth National Conference on Artificial
1067: Intelligence (AAAI-94)}, pages 362--367, 1994.
1068:
1069: \bibitem{bib:schulte97}
1070: C.~Schulte.
1071: \newblock Oz {E}xplorer: {A} {V}isual {C}onstraint {P}rogramming {T}ool.
1072: \newblock In L.~Naish, editor, {\em Proceedings of the Fourteenth International
1073: Conference on Logic Programming}, pages 286--300. MIT Press, 1997.
1074:
1075: \bibitem{bib:sa00}
1076: H.~Simonis and A.~Aggoun.
1077: \newblock Search-{T}ree {V}isualization.
1078: \newblock In P.~Deransart, M.V. Hermenegildo, and J.~Ma{\l}uszy{\'n}ski,
1079: editors, {\em Analysis and Visualization Tools for Constraint Programming},
1080: volume 1870 of {\em LNCS}, pages 191--208. Springer-Verlag, 2000.
1081:
1082: \end{thebibliography}
1083:
1084:
1085: \end{document}
1086: