Dekker1/dekker-phd-thesis
Archived
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Incorporate Background feedback from Peter

Browse Source
This commit is contained in:
Jip J. Dekker 2021-05-24 14:41:37 +10:00
parent b5ff72e95f
commit 3687260209
No known key found for this signature in database
GPG Key ID: 517DF4A00618C9C3
3 changed files with 934 additions and 904 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
assets/acronyms.tex
View File

@ -45,7 +45,7 @@
\newacronym[see={[Glossary:]{gls-mip}}]{mip}{MIP\glsadd{gls-mip}}{Mixed Integer \newacronym[see={[Glossary:]{gls-mip}}]{mip}{MIP\glsadd{gls-mip}}{Mixed Integer
Programming} Programming}
\newacronym{np-comp}{NP-complete}{Nondeterministic Polynomial-time complete} \newacronym{np}{NP}{Nondeterministic Polynomial-time}
\newacronym[see={[Glossary:]{gls-opl}}]{opl}{OPL\glsadd{gls-opl}}{The \newacronym[see={[Glossary:]{gls-opl}}]{opl}{OPL\glsadd{gls-opl}}{The
Optimisation Programming Language} Optimisation Programming Language}

163
assets/bibliography/references.bib
View File

@ -110,6 +110,7 @@
@software{biere-2021-kissat, @software{biere-2021-kissat,
title = {Kissat}, title = {Kissat},
version = {2021}, version = {2021},
year = {2021},
author = {Armin Biere}, author = {Armin Biere},
url = {http://fmv.jku.at/kissat/} url = {http://fmv.jku.at/kissat/}
} }
@ -191,7 +192,8 @@
url = {https://doi.org/10.1007/s10732-011-9158-2}, url = {https://doi.org/10.1007/s10732-011-9158-2},
doi = {10.1007/s10732-011-9158-2}, doi = {10.1007/s10732-011-9158-2},
timestamp = {Fri, 30 Nov 2018 13:23:27 +0100}, timestamp = {Fri, 30 Nov 2018 13:23:27 +0100},
biburl = {https://dblp.org/rec/journals/heuristics/ChiarandiniGGS12.bib}, biburl =
{https://dblp.org/rec/journals/heuristics/ChiarandiniGGS12.bib},
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@ -203,6 +205,26 @@
version = {0.10.3} version = {0.10.3}
} }
@inproceedings{choi-2006-fin-cons,
author = {Chiu Wo Choi and Warwick Harvey and J. H. M. Lee and Peter
J. Stuckey},
editor = {Abdul Sattar and Byeong{-}Ho Kang},
title = {Finite Domain Bounds Consistency Revisited},
booktitle = {{AI} 2006: Advances in Artificial Intelligence, 19th
Australian Joint Conference on Artificial Intelligence,
Hobart, Australia, December 4-8, 2006, Proceedings},
series = {Lecture Notes in Computer Science},
volume = 4304,
pages = {49--58},
publisher = {Springer},
year = 2006,
url = {https://doi.org/10.1007/11941439\_9},
doi = {10.1007/11941439\_9},
timestamp = {Mon, 04 Nov 2019 12:36:13 +0100},
biburl = {https://dblp.org/rec/conf/ausai/ChoiHLS06.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@article{cocke-1970-cse, @article{cocke-1970-cse,
author = {Cocke, John}, author = {Cocke, John},
title = {Global Common Subexpression Elimination}, title = {Global Common Subexpression Elimination},
@ -282,25 +304,6 @@
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@inproceedings{feydy-2011-half-reif,
author = {Thibaut Feydy and Zoltan Somogyi and Peter J. Stuckey},
editor = {Jimmy Ho{-}Man Lee},
title = {Half Reification and Flattening},
booktitle = {Principles and Practice of Constraint Programming - {CP}
2011 - 17th International Conference, {CP} 2011, Perugia,
Italy, September 12-16, 2011. Proceedings},
series = {Lecture Notes in Computer Science},
volume = 6876,
pages = {286--301},
publisher = {Springer},
year = 2011,
url = {https://doi.org/10.1007/978-3-642-23786-7_23},
doi = {10.1007/978-3-642-23786-7_23},
timestamp = {Tue, 14 May 2019 10:00:45 +0200},
biburl = {https://dblp.org/rec/conf/cp/FeydySS11.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@software{forrest-2020-cbc, @software{forrest-2020-cbc,
author = {Forrest, J. and author = {Forrest, J. and
Stefan Vigerske and Stefan Vigerske and
@ -324,6 +327,25 @@
url = {https://doi.org/10.5281/zenodo.3700700} url = {https://doi.org/10.5281/zenodo.3700700}
} }
@inproceedings{feydy-2011-half-reif,
author = {Thibaut Feydy and Zoltan Somogyi and Peter J. Stuckey},
editor = {Jimmy Ho{-}Man Lee},
title = {Half Reification and Flattening},
booktitle = {Principles and Practice of Constraint Programming - {CP}
2011 - 17th International Conference, {CP} 2011, Perugia,
Italy, September 12-16, 2011. Proceedings},
series = {Lecture Notes in Computer Science},
volume = 6876,
pages = {286--301},
publisher = {Springer},
year = 2011,
url = {https://doi.org/10.1007/978-3-642-23786-7_23},
doi = {10.1007/978-3-642-23786-7_23},
timestamp = {Tue, 14 May 2019 10:00:45 +0200},
biburl = {https://dblp.org/rec/conf/cp/FeydySS11.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@article{fourer-2002-amplcp, @article{fourer-2002-amplcp,
author = {Robert Fourer and David M. Gay}, author = {Robert Fourer and David M. Gay},
title = {Extending an Algebraic Modeling Language to Support title = {Extending an Algebraic Modeling Language to Support
@ -402,6 +424,17 @@
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@techreport{gamrath-2020-scip,
author = {Gerald Gamrath and Daniel Anderson and Ksenia Bestuzheva and Wei-Kun Chen and Leon Eifler and Maxime Gasse and Patrick Gemander and Ambros Gleixner and Leona Gottwald and Katrin Halbig and Gregor Hendel and Christopher Hojny and Thorsten Koch and Le Bodic, Pierre and Stephen J. Maher and Frederic Matter and Matthias Miltenberger and Erik M{\"u}hmer and Benjamin M{\"u}ller and Marc E. Pfetsch and Franziska Schl{\"o}sser and Felipe Serrano and Yuji Shinano and Christine Tawfik and Stefan Vigerske and Fabian Wegscheider and Dieter Weninger and Jakob Witzig},
title = {{The SCIP Optimization Suite 7.0}},
type = {ZIB-Report},
institution = {Zuse Institute Berlin},
number = {20-10},
month = {3},
year = {2020},
url = {http://nbn-resolving.de/urn:nbn:de:0297-zib-78023}
}
@article{fruhwirth-1998-chr, @article{fruhwirth-1998-chr,
author = {Thom W. Fr{\"{u}}hwirth}, author = {Thom W. Fr{\"{u}}hwirth},
title = {Theory and Practice of Constraint Handling Rules}, title = {Theory and Practice of Constraint Handling Rules},
@ -417,15 +450,12 @@
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@techreport{gamrath-2020-scip, @software{gecode-2021-gecode,
author = {Gerald Gamrath and Daniel Anderson and Ksenia Bestuzheva and Wei-Kun Chen and Leon Eifler and Maxime Gasse and Patrick Gemander and Ambros Gleixner and Leona Gottwald and Katrin Halbig and Gregor Hendel and Christopher Hojny and Thorsten Koch and Le Bodic, Pierre and Stephen J. Maher and Frederic Matter and Matthias Miltenberger and Erik M{\"u}hmer and Benjamin M{\"u}ller and Marc E. Pfetsch and Franziska Schl{\"o}sser and Felipe Serrano and Yuji Shinano and Christine Tawfik and Stefan Vigerske and Fabian Wegscheider and Dieter Weninger and Jakob Witzig}, author = {{Gecode Team}},
title = {{The SCIP Optimization Suite 7.0}}, title = {Gecode: A Generic Constraint Development Environment},
type = {ZIB-Report}, year = 2021,
institution = {Zuse Institute Berlin}, url = {http://www.gecode.org},
number = {20-10}, version = {6.3.0}
month = {3},
year = {2020},
url = {http://nbn-resolving.de/urn:nbn:de:0297-zib-78023}
} }
@article{gebser-2012-clasp, @article{gebser-2012-clasp,
@ -443,14 +473,6 @@
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@software{gecode-2021-gecode,
author = {{Gecode Team}},
title = {Gecode: A Generic Constraint Development Environment},
year = 2021,
url = {http://www.gecode.org},
version = {6.3.0}
}
@manual{gurobi-2021-gurobi, @manual{gurobi-2021-gurobi,
author = {{Gurobi Optimization, LLC}}, author = {{Gurobi Optimization, LLC}},
title = {Gurobi Optimizer Reference Manual}, title = {Gurobi Optimizer Reference Manual},
@ -548,7 +570,8 @@
year = 1997, year = 1997,
issn = {0377-2217}, issn = {0377-2217},
doi = {https://doi.org/10.1016/S0377-2217(96)00170-1}, doi = {https://doi.org/10.1016/S0377-2217(96)00170-1},
url = {https://www.sciencedirect.com/science/article/pii/S0377221796001701}, url =
{https://www.sciencedirect.com/science/article/pii/S0377221796001701},
author = {Rainer Kolisch and Arno Sprecher}, author = {Rainer Kolisch and Arno Sprecher},
keywords = {Project scheduling, Resource constraints, Benchmark keywords = {Project scheduling, Resource constraints, Benchmark
instances} instances}
@ -653,7 +676,8 @@
url = {https://doi.org/10.1007/s10601-008-9041-4}, url = {https://doi.org/10.1007/s10601-008-9041-4},
doi = {10.1007/s10601-008-9041-4}, doi = {10.1007/s10601-008-9041-4},
timestamp = {Fri, 13 Mar 2020 10:58:29 +0100}, timestamp = {Fri, 13 Mar 2020 10:58:29 +0100},
biburl = {https://dblp.org/rec/journals/constraints/MarriottNRSBW08.bib}, biburl =
{https://dblp.org/rec/journals/constraints/MarriottNRSBW08.bib},
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@ -677,6 +701,14 @@
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@software{minizinc-2021-minizinc,
author = {{MiniZinc Team}},
title = {MiniZinc: a free and open-source constraint modeling language},
year = 2021,
url = {http://www.minizinc.org},
version = {2.5.5}
}
@inproceedings{michel-2005-comet, @inproceedings{michel-2005-comet,
author = {Laurent Michel and Pascal Van Hentenryck}, author = {Laurent Michel and Pascal Van Hentenryck},
editor = {Peter van Beek}, editor = {Peter van Beek},
@ -696,12 +728,13 @@
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@software{minizinc-2021-minizinc, @software{perron-2021-ortools,
author = {{MiniZinc Team}}, title = {OR-Tools},
title = {MiniZinc: a free and open-source constraint modeling language}, version = {9.0},
year = 2021, author = {Laurent Perron and Vincent Furnon},
url = {http://www.minizinc.org}, organization = {Google},
version = {2.5.5} url = {https://developers.google.com/optimization/},
date = {2021-04-30}
} }
@inproceedings{nethercote-2007-minizinc, @inproceedings{nethercote-2007-minizinc,
@ -724,15 +757,6 @@
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@software{perron-2021-ortools,
title = {OR-Tools},
version = {9.0},
author = {Laurent Perron and Vincent Furnon},
organization = {Google},
url = {https://developers.google.com/optimization/},
date = {2021-04-30}
}
@article{pisinger-2007-heuristic, @article{pisinger-2007-heuristic,
author = {David Pisinger and Stefan Ropke}, author = {David Pisinger and Stefan Ropke},
title = {A general heuristic for vehicle routing problems}, title = {A general heuristic for vehicle routing problems},
@ -773,6 +797,17 @@
url = {http://www.choco-solver.org } url = {http://www.choco-solver.org }
} }
@phdthesis{rendl-2010-thesis,
author = {Andrea Rendl},
title = {Effective compilation of constraint models},
school = {University of St Andrews, {UK}},
year = {2010},
url = {http://hdl.handle.net/10023/973},
timestamp = {Thu, 25 Aug 2016 17:20:59 +0200},
biburl = {https://dblp.org/rec/phd/ethos/Rendl10.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@inproceedings{rendl-2009-enhanced-tailoring, @inproceedings{rendl-2009-enhanced-tailoring,
author = {Andrea Rendl and Ian Miguel and Ian P. Gent and Christopher author = {Andrea Rendl and Ian Miguel and Ian P. Gent and Christopher
Jefferson}, Jefferson},
@ -784,23 +819,13 @@
8-10 August 2009}, 8-10 August 2009},
publisher = {{AAAI}}, publisher = {{AAAI}},
year = 2009, year = 2009,
url = {http://www.aaai.org/ocs/index.php/SARA/SARA09/paper/view/824}, url =
{http://www.aaai.org/ocs/index.php/SARA/SARA09/paper/view/824},
timestamp = {Tue, 09 Feb 2021 08:32:53 +0100}, timestamp = {Tue, 09 Feb 2021 08:32:53 +0100},
biburl = {https://dblp.org/rec/conf/sara/RendlMGJ09.bib}, biburl = {https://dblp.org/rec/conf/sara/RendlMGJ09.bib},
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@phdthesis{rendl-2010-thesis,
author = {Andrea Rendl},
title = {Effective compilation of constraint models},
school = {University of St Andrews, {UK}},
year = {2010},
url = {http://hdl.handle.net/10023/973},
timestamp = {Thu, 25 Aug 2016 17:20:59 +0200},
biburl = {https://dblp.org/rec/phd/ethos/Rendl10.bib},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@inproceedings{rendl-2015-minisearch, @inproceedings{rendl-2015-minisearch,
author = {Andrea Rendl and Tias Guns and Peter J. Stuckey and Guido author = {Andrea Rendl and Tias Guns and Peter J. Stuckey and Guido
Tack}, Tack},
@ -859,7 +884,8 @@
url = {https://doi.org/10.1007/s10601-018-9289-2}, url = {https://doi.org/10.1007/s10601-018-9289-2},
doi = {10.1007/s10601-018-9289-2}, doi = {10.1007/s10601-018-9289-2},
timestamp = {Mon, 26 Oct 2020 09:00:47 +0100}, timestamp = {Mon, 26 Oct 2020 09:00:47 +0100},
biburl = {https://dblp.org/rec/journals/constraints/SchiendorferKAR18.bib}, biburl =
{https://dblp.org/rec/journals/constraints/SchiendorferKAR18.bib},
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }
@ -885,7 +911,8 @@
url = {https://doi.org/10.1007/s10601-012-9137-8}, url = {https://doi.org/10.1007/s10601-012-9137-8},
doi = {10.1007/s10601-012-9137-8}, doi = {10.1007/s10601-012-9137-8},
timestamp = {Fri, 13 Mar 2020 10:58:29 +0100}, timestamp = {Fri, 13 Mar 2020 10:58:29 +0100},
biburl = {https://dblp.org/rec/journals/constraints/SchrijversTWSS13.bib}, biburl =
{https://dblp.org/rec/journals/constraints/SchrijversTWSS13.bib},
bibsource = {dblp computer science bibliography, https://dblp.org} bibsource = {dblp computer science bibliography, https://dblp.org}
} }

303
chapters/2_background.tex
View File

@ -29,10 +29,10 @@ the modelling of \gls{cop}, where a \gls{csp} is augmented with a
\gls{objective} \(z\). In this case the goal is to find a solution that \gls{objective} \(z\). In this case the goal is to find a solution that
satisfies all \constraints{} while minimising (or maximising) \(z\). satisfies all \constraints{} while minimising (or maximising) \(z\).
Although a constraint model does not contain any instructions to find a suitable Although a constraint model does not contain any instructions on how to find a
solution, these models can generally be given to a dedicated solving program, or suitable solution, these models can generally be given to a dedicated solving
\solver{} for short, that can find a solution that fits the requirements of the program, or \solver{} for short, that can find a solution that fits the
model. requirements of the model.
\begin{example}% \begin{example}%
\label{ex:back-knapsack} \label{ex:back-knapsack}
@ -178,16 +178,17 @@ format. In \minizinc\ these items are not constrained to occur in any particular
order. We will briefly discuss the most important model items. For a detailed order. We will briefly discuss the most important model items. For a detailed
overview of the structure of \minizinc\ models you can consult the full overview of the structure of \minizinc\ models you can consult the full
syntactic structure of \minizinc\ 2.5.5 in \cref{ch:minizinc-grammar}. syntactic structure of \minizinc\ 2.5.5 in \cref{ch:minizinc-grammar}.
Nethercote et al.\ and Mariott et al.\ offer a detailed discussion of the Nethercote et al.\ and Marriott et al.\ offer a detailed discussion of the
\minizinc\ and \zinc\ language, its predecessor, respectively \minizinc\ and \zinc\ language, its predecessor, respectively
\autocite*{nethercote-2007-minizinc,marriott-2008-zinc}. \autocite*{nethercote-2007-minizinc,marriott-2008-zinc}.
Values in \minizinc\ are declared in the form \mzninline{@\(T\)@: @\(I\)@ = Values in \minizinc\ are declared in the form \mzninline{@\(T\)@: @\(I\)@;} or
@\(E\)@;}. \(T\) is the type of the declared value, \(I\) is a new identifier \mzninline{@\(T\)@: @\(I\)@ = @\(E\)@;}. \(T\) is the type of the declared
used to reference the declared value, and, optionally, the modeller can value, \(I\) is a new identifier used to reference the declared value, and,
functionally define the value using an expression \(E\). The identifier used in optionally, the modeller can functionally define the value using an expression
a top-level value definition must be unique. Two declarations with the same \(E\). The identifier used in a top-level value definition must be unique. Two
identifier will result in an error during the flattening process. declarations with the same identifier will result in an error during the
flattening process.
The main types used in \minizinc\ are Boolean, integer, floating point numbers, The main types used in \minizinc\ are Boolean, integer, floating point numbers,
sets of integers, and (user-defined) enumerated types. These types can be used sets of integers, and (user-defined) enumerated types. These types can be used
@ -206,16 +207,14 @@ type expression. These expressions constrain a declaration, not just to a
certain type, but also to a set of value. This set of values is generally certain type, but also to a set of value. This set of values is generally
referred to as the \gls{domain} of a \variable{}. In \minizinc\ any expression referred to as the \gls{domain} of a \variable{}. In \minizinc\ any expression
that has a set type can be used as a type expression. For example, the following that has a set type can be used as a type expression. For example, the following
two declarations two declarations declare two integer \variables{} that can take the values from
three to five and one, three, and five respectively.
\begin{mzn} \begin{mzn}
var 3..5: x; var 3..5: x;
var {1,3,5}: y; var {1,3,5}: y;
\end{mzn} \end{mzn}
declare two integer \variables{} that can take the values from three to five and
one, three, and five respectively.
If the declaration includes an expression to functionally define the value, then If the declaration includes an expression to functionally define the value, then
the identifier can be used as a name for this expression. If, however, the type the identifier can be used as a name for this expression. If, however, the type
of the declaration is given as a type expression, then this places an implicit of the declaration is given as a type expression, then this places an implicit
@ -235,7 +234,9 @@ solver to do one of three actions: to find an assignment to the \variables{}
that satisfies the constraints, \mzninline{solve satisfy;}, to find an that satisfies the constraints, \mzninline{solve satisfy;}, to find an
assignment to the \variables{} that satisfies the constraints and minimises the assignment to the \variables{} that satisfies the constraints and minimises the
value of a \variable{}, \mzninline{solve minimize x;}, or similarly maximises value of a \variable{}, \mzninline{solve minimize x;}, or similarly maximises
the value of a \variable{}, \mzninline{solve maximize x;}. the value of a \variable{}, \mzninline{solve maximize x;}. If the model does not
contain a goal item, then it then the problem is assumed to be a satisfaction
problem.
\jip{TODO:\@ add some information about search in \minizinc{}. It's probably \jip{TODO:\@ add some information about search in \minizinc{}. It's probably
pretty relevant.} pretty relevant.}
@ -261,7 +262,7 @@ to function calls. A solver can then provide its own implementation for these
functions. It is assumed that the implementation of the functions in the functions. It is assumed that the implementation of the functions in the
\solver{} libraries will ultimately be rewritten into fully relational call. \solver{} libraries will ultimately be rewritten into fully relational call.
When a relational constraint is directly supported by a solver the function When a relational constraint is directly supported by a solver the function
should be declared within an expression body. Any call to such function is should be declared within an expression body. Any call to such a function is
directly placed in the flattened model. directly placed in the flattened model.
\subsection{MiniZinc Expressions}% \subsection{MiniZinc Expressions}%
@ -273,10 +274,7 @@ read, but are transformed to fit the structure best suited to the chosen
\solver{}. We will now briefly discuss the most important \minizinc\ expressions \solver{}. We will now briefly discuss the most important \minizinc\ expressions
and the general methods employed when flattening them. A detailed overview of and the general methods employed when flattening them. A detailed overview of
the full syntactic structure of the \minizinc\ expressions in \minizinc\ 2.5.5 the full syntactic structure of the \minizinc\ expressions in \minizinc\ 2.5.5
can be found in \cref{sec:mzn-grammar-expressions}. Nethercote et al.\ and can be found in \cref{sec:mzn-grammar-expressions}.
Mariott et al.\ offer a detailed discussion of the expression language of
\minizinc\ and its predecessor \zinc\ respectively
\autocite*{nethercote-2007-minizinc,marriott-2008-zinc}.
\Glspl{global} are the basic building blocks in the \minizinc\ language. These \Glspl{global} are the basic building blocks in the \minizinc\ language. These
expressions capture common (complex) relations between \variables{}. expressions capture common (complex) relations between \variables{}.
@ -340,7 +338,7 @@ expressions. You could, for example, force that the absolute value of
\mzninline{a} is bigger than \mzninline{b} using the constraint \mzninline{a} is bigger than \mzninline{b} using the constraint
\begin{mzn} \begin{mzn}
constraint if b >= 0 then a > b else b < a endif; constraint if a >= 0 then a > b else b < a endif;
\end{mzn} \end{mzn}
In \minizinc\ the result of a \gls{conditional} expression is, however, not In \minizinc\ the result of a \gls{conditional} expression is, however, not
@ -373,7 +371,7 @@ modellers to provide a custom index set.
Like the previous expressions, the selector \mzninline{i} can be both a Like the previous expressions, the selector \mzninline{i} can be both a
\parameter{} or a \variable{}. If the expression is a \gls{variable}, then the \parameter{} or a \variable{}. If the expression is a \gls{variable}, then the
expression is flattened as being an \mzninline{element} function. Otherwise, the expression is flattened to be an \mzninline{element} function. Otherwise, the
flattening will replace the \gls{array} access expression by the element flattening will replace the \gls{array} access expression by the element
referenced by expression. referenced by expression.
@ -394,11 +392,11 @@ parts:
when the filtering condition succeeds. when the filtering condition succeeds.
\end{description} \end{description}
The following example composes an \gls{array} that contains the doubled even The following example composes an \gls{array} that contains the tripled even
values of an \gls{array} \mzninline{x}. values of an \gls{array} \mzninline{x}.
\begin{mzn} \begin{mzn}
[ xi * 2 | xi in x where x mod 2 == 0] [ xi * 3 | xi in x where x mod 2 == 0]
\end{mzn} \end{mzn}
The evaluated expression will be added to the new array. This means that the The evaluated expression will be added to the new array. This means that the
@ -418,24 +416,24 @@ resulting definition. There are three main purposes for \glspl{let}:
\begin{enumerate} \begin{enumerate}
\item To name an intermediate expression, so it can be used multiple times or \item To name an intermediate expression, so it can be used multiple times or
to simplify the expression. For example, the constraint to simplify the expression. For example, the constraint
%
\begin{mzn} \begin{mzn}
constraint let { var int: tmp = x div 2; } in tmp mod 2 == 0 \/ tmp = 0; constraint let { var int: tmp = x div 2; } in tmp mod 2 == 0 \/ tmp = 1;
\end{mzn} \end{mzn}
%
constrains that half of \mzninline{x} is even or zero. constrains that half of \mzninline{x} is even or one.
\item To introduce a scoped \variable{}. For example, the constraint \item To introduce a scoped \variable{}. For example, the constraint
%
\begin{mzn} \begin{mzn}
let {var -2..2: slack;} in x + slack = y; constraint let {var -2..2: slack;} in x + slack = y;
\end{mzn} \end{mzn}
%
constrains that \mzninline{x} and \mzninline{y} are at most two apart. constrains that \mzninline{x} and \mzninline{y} are at most two apart.
\item To constrain the resulting expression. For example, the following \item To constrain the resulting expression. For example, the following
function function
%
\begin{mzn} \begin{mzn}
function var int: int_times(var int: x, var int: y) = function var int: int_times(var int: x, var int: y) =
let { let {
@ -443,7 +441,7 @@ resulting definition. There are three main purposes for \glspl{let}:
constraint pred_int_times(x, y, z); constraint pred_int_times(x, y, z);
} in z; } in z;
\end{mzn} \end{mzn}
%
returns a new \variable{} \mzninline{z} that is constrained to be the returns a new \variable{} \mzninline{z} that is constrained to be the
multiplication of \mzninline{x} and \mzninline{y} by the relational multiplication of \mzninline{x} and \mzninline{y} by the relational
multiplication constraint \mzninline{pred_int_times}. multiplication constraint \mzninline{pred_int_times}.
@ -486,14 +484,17 @@ corresponding constraint \mzninline{c(...)} holds.
reified variables it can set to \mzninline{true}. reified variables it can set to \mzninline{true}.
\end{example} \end{example}
We say that the same expression can be used in \emph{root context} as well as in When an expression occurs in a position where it can be globally enforced, we
a \emph{reified context}. In \minizinc{}, almost all expressions can be used in say it occurs in \emph{root context}. Contrarily, an expression that occurs in a
both contexts. \emph{non-root context} will be reified during the flattening process. In
\minizinc{}, almost all expressions can be used in both contexts.
\subsection{Handling Undefined Expressions}% \subsection{Handling Undefined Expressions}%
\label{subsec:back-mzn-partial} \label{subsec:back-mzn-partial}
Some expressions in the \cmls\ do not always have a well-defined result. Some expressions in the \cmls\ do not always have a well-defined result. Part of
the semantics of a \cmls{} is the choice as to how to treat these partial
functions.
\begin{example}\label{ex:back-undef} \begin{example}\label{ex:back-undef}
Consider, for example, the following ``complex constraint'' Consider, for example, the following ``complex constraint''
@ -512,8 +513,7 @@ Some expressions in the \cmls\ do not always have a well-defined result.
the constraint should be trivially true. the constraint should be trivially true.
\end{example} \end{example}
Part of the semantics of a \cmls{} is the choice as to how to treat these Other examples of \minizinc{} expressions that result in partial functions are:
partial functions. Examples of such expressions in \minizinc\ are:
\begin{itemize} \begin{itemize}
\item Division (or modulus) when the divisor is zero: \item Division (or modulus) when the divisor is zero:
@ -522,12 +522,6 @@ partial functions. Examples of such expressions in \minizinc\ are:
x div 0 = @??@ x div 0 = @??@
\end{mzn} \end{mzn}
\item Array access when the index is outside the given index set:
\begin{mzn}
array1d(1..3, [1,2,3])[0] = @??@
\end{mzn}
\item Finding the minimum or maximum or an empty set: \item Finding the minimum or maximum or an empty set:
\begin{mzn} \begin{mzn}
@ -595,8 +589,7 @@ For example, one might deal with a zero divisor using a disjunction:
In this case we expect the undefinedness of the division to be contained within In this case we expect the undefinedness of the division to be contained within
the second part of the disjunction. This corresponds to ``relational'' the second part of the disjunction. This corresponds to ``relational''
semantics. \jip{TODO:\@ This also corresponds to Kleene semantics, maybe I semantics.
should use a different example}
Frisch and Stuckey also show that different \solvers{} often employ different Frisch and Stuckey also show that different \solvers{} often employ different
semantics \autocite*{frisch-2009-undefinedness}. It is therefore important that, semantics \autocite*{frisch-2009-undefinedness}. It is therefore important that,
@ -642,7 +635,7 @@ targets and their input language.
When given a \gls{csp}, one might wonder what the best way is to find a solution When given a \gls{csp}, one might wonder what the best way is to find a solution
to the problem. The simplest solution would be to apply ``brute force'': try to the problem. The simplest solution would be to apply ``brute force'': try
every value in the \gls{domain} all \variables{}. It will not surprise the every value in the \gls{domain} of all \variables{}. It will not surprise the
reader that this is an inefficient approach. Given, for example, the constraint reader that this is an inefficient approach. Given, for example, the constraint
\begin{mzn} \begin{mzn}
@ -650,22 +643,22 @@ reader that this is an inefficient approach. Given, for example, the constraint
\end{mzn} \end{mzn}
It is clear that when the value \mzninline{a} is known, then the value of It is clear that when the value \mzninline{a} is known, then the value of
\mzninline{b} can be deduced. \gls{cp} is the idea solving \glspl{csp} by \mzninline{b} can be deduced. \gls{cp} is the idea of solving \glspl{csp} by
performing an intelligent search by inferring which values are still feasible performing an intelligent search by inferring which values are still feasible
for each \variable{} \autocite{rossi-2006-cp}. for each \variable{} \autocite{rossi-2006-cp}.
To find a solution to a given \gls{csp}, a \gls{cp} \solver{} will perform a To find a solution to a given \gls{csp}, a \gls{cp} \solver{} will perform a
depth first search. At each node, the \solver{} will try and eliminate any depth first search. At each node, the \solver{} will try to eliminate any
impossible value using a process called \gls{propagation}. For each impossible value using a process called \gls{propagation}. For each
\constraint{} the \solver{} has a chosen algorithm called a \gls{propagator}. \constraint{} the \solver{} has a chosen algorithm called a \gls{propagator}.
Triggered by changes in the \glspl{domain} of its \variables{}, the Triggered by changes in the \glspl{domain} of its \variables{}, the
\gls{propagator} will analyse and prune the any values that are proven to be \gls{propagator} will analyse and prune any values that are proven to be
inconsistent. inconsistent.
In the best case scenario, \gls{propagation} will eliminate all impossible value In the best case scenario, \gls{propagation} will eliminate all impossible
and all \variables{} have been fixed to a single value. In this case we have values and all \variables{} have been fixed to a single value. In this case we
arrived at a solution. Often, \gls{propagation} alone will not be enough to find have arrived at a solution. Often, \gls{propagation} alone will not be enough to
a solution to the problem. Instead, when no more \glspl{propagator} are find a solution to the problem. Instead, when no more \glspl{propagator} are
triggered (we have reached a \gls{fixpoint}), the \solver{} has to make a search triggered (we have reached a \gls{fixpoint}), the \solver{} has to make a search
decision. It will fix a \variable{} to a value or add a new \constraint{}. This decision. It will fix a \variable{} to a value or add a new \constraint{}. This
search decision is an assumption made by the \solver{} in the hope of finding a search decision is an assumption made by the \solver{} in the hope of finding a
@ -673,12 +666,12 @@ solution. If no solution is found using the search decision, then it needs to
try making the opposite decision: excluding the chosen value or adding the try making the opposite decision: excluding the chosen value or adding the
opposite constraint. opposite constraint.
Note that the important difference between values \gls{propagation} and making Note that the important difference between values excluded by \gls{propagation}
search decisions is that value excluded by a \gls{propagator} are guaranteed to and making search decisions is that value excluded by a \gls{propagator} are
not occur in any solution, but values excluded by a search heuristic are merely guaranteed to not occur in any solution, but values excluded by a search
removed locally and might still be part of a solution. A \gls{cp} \solver{} is heuristic are merely removed locally and might still be part of a solution. A
only able to prove that the problem is unsatisfiable by exploring the full \gls{cp} \solver{} is only able to prove that the problem is unsatisfiable by
search space. exploring the full search space.
\Gls{propagation} is not only used when starting the search, but also after \Gls{propagation} is not only used when starting the search, but also after
making each search decision. This means that some \gls{propagation} depends on making each search decision. This means that some \gls{propagation} depends on
@ -718,17 +711,19 @@ constraints otherwise.
\begin{mzn} \begin{mzn}
int: n; int: n;
array [1..n] of var 1..n: q; set of int: ROW = 1..n;
set of int: COL = 1..n;
array [ROW] of var COL: q;
constraint all_different(q); constraint all_different(q);
constraint all_different([q[i] + i | i in 1..n]); constraint all_different([q[i] + i | i in ROW]);
constraint all_different([q[i] - i | i in 1..n]); constraint all_different([q[i] - i | i in ROW]);
\end{mzn} \end{mzn}
Since we know that there can only be one queen per column, the decision in the Since we know that there can only be one queen per row, the decision in the
model left to make is, for every queen, where in the column the piece is model left to make is, for every queen, where in the row the piece is placed.
placed. The \constraints{} in the model the remaining rules of the problem: no The \constraints{} in the model the remaining rules of the problem: no two
two queen can be placed in the same row, no two queen can be place in the same queen can be placed in the same row, no two queen can be place in the same
upward diagonal, and no two queens can be place in the same downward diagonal. upward diagonal, and no two queens can be place in the same downward diagonal.
This model can be directly used in most \gls{cp} \solvers{}, since integer This model can be directly used in most \gls{cp} \solvers{}, since integer
\variables{} and an \mzninline{all_different} \gls{propagator} are common. \variables{} and an \mzninline{all_different} \gls{propagator} are common.
@ -753,8 +748,8 @@ propagating a constraint and the amount of search that is otherwise required.
The golden standard for a \gls{propagator} is to be \gls{domain-con}, meaning The golden standard for a \gls{propagator} is to be \gls{domain-con}, meaning
that all values left in the \glspl{domain} of its \variables{} there is at least that all values left in the \glspl{domain} of its \variables{} there is at least
one possible variable assignment that satisfies the constraint. Designing an one possible variable assignment that satisfies the constraint. Designing an
algorithm that reaches this level of consistency is, however, an easy task and algorithm that reaches this level of consistency is, however, not an easy task
might require high complexity. Instead, it can sometimes be better to use a and might require high complexity. Instead, it can sometimes be better to use a
propagator with a lower level of consistency. Although it might not eliminate propagator with a lower level of consistency. Although it might not eliminate
all possible values of the domain, searching the values that are not eliminated all possible values of the domain, searching the values that are not eliminated
might take less time than achieving \gls{domain-con}. might take less time than achieving \gls{domain-con}.
@ -762,10 +757,11 @@ might take less time than achieving \gls{domain-con}.
This is, for example, the case for integer linear constraints: This is, for example, the case for integer linear constraints:
\[ \sum_{i} c_{i} x_{i} = d\] where \(c_{i}\) and \(d\) are integer \[ \sum_{i} c_{i} x_{i} = d\] where \(c_{i}\) and \(d\) are integer
\parameters{} and \(x_{i}\) are integer \variable{}. For these constraints, no \parameters{} and \(x_{i}\) are integer \variable{}. For these constraints, no
realistic \gls{domain-con} \gls{propagator} exists. Instead, \solvers{} realistic \gls{domain-con} \gls{propagator} exists because the problem is
generally use a \gls{bounds-con} \gls{propagator}, which guarantee only that the \gls{np}-hard \autocite{choi-2006-fin-cons}. Instead, \solvers{} generally use a
minimum and maximum values in the \glspl{domain} of the \variables{} are used in \gls{bounds-con} \gls{propagator}, which guarantee only that the minimum and
at least one possible assignment that satisfies the constraint. maximum values in the \glspl{domain} of the \variables{} are used in at least
one possible assignment that satisfies the constraint.
Thus far, we have only considered \glspl{csp}. \gls{cp} solving can, however, Thus far, we have only considered \glspl{csp}. \gls{cp} solving can, however,
also be used to solve optimisation problems using a method called \gls{bnb}. The also be used to solve optimisation problems using a method called \gls{bnb}. The
@ -782,8 +778,8 @@ better solutions than the current incumbent solution.
\gls{cp} solvers like Chuffed \autocite{chuffed-2021-chuffed}, Choco \gls{cp} solvers like Chuffed \autocite{chuffed-2021-chuffed}, Choco
\autocite{prudhomme-2016-choco}, \gls{gecode} \autocite{gecode-2021-gecode}, and \autocite{prudhomme-2016-choco}, \gls{gecode} \autocite{gecode-2021-gecode}, and
OR-Tools \autocite{perron-2021-ortools} have long been one of the leading method OR-Tools \autocite{perron-2021-ortools} have long been one of the leading
to solve \minizinc\ instances. methods to solve \minizinc\ instances.
\subsection{Mathematical Programming}% \subsection{Mathematical Programming}%
\label{subsec:back-mip} \label{subsec:back-mip}
@ -794,14 +790,14 @@ One of the oldest techniques to solve optimisation problems is the use of
\gls{lp} \autocite{schrijver-1998-mip}. A linear program describes a problem \gls{lp} \autocite{schrijver-1998-mip}. A linear program describes a problem
using a set of linear equations over continuous variables. In general, a linear using a set of linear equations over continuous variables. In general, a linear
program can be expressed in the form: program can be expressed in the form:
%
\begin{align*} \begin{align*}
\text{maximise} \hspace{2em} & \sum_{j=1}^{V} c_{j} x_{j} & \\ \text{maximise} \hspace{2em} & \sum_{j=1}^{V} c_{j} x_{j} & \\
\text{subject to} \hspace{2em} & l_{i} \leq \sum_{j=0}^{V} a_{ij} x_{j} \leq u_{i} & \forall_{i=1}^{C} \\ \text{subject to} \hspace{2em} & l_{i} \leq \sum_{j=0}^{V} a_{ij} x_{j} \leq u_{i} & \forall_{i=1}^{C} \\
& x_{i} \in \mathbb{R} & \forall_{i=1}^{V} & x_{i} \in \mathbb{R} & \forall_{i=1}^{V}
\end{align*} \end{align*}
%
where \(V\) and \(C\) represent the number of variables and number of \noindent{}where \(V\) and \(C\) represent the number of variables and number of
constraints respectively. The vector \(c\) holds the coefficients of the constraints respectively. The vector \(c\) holds the coefficients of the
objective function and the matrix \(a\) holds the coefficients for the objective function and the matrix \(a\) holds the coefficients for the
constraints. The vectors \(l\) and \(u\) respectively contain the lower and constraints. The vectors \(l\) and \(u\) respectively contain the lower and
@ -809,10 +805,13 @@ upper bounds of the constraints. Finally, the \variables{} of the linear program
held in the \(x\) vector. held in the \(x\) vector.
For problems that are in the form of a linear program, there are proven methods For problems that are in the form of a linear program, there are proven methods
to find the optimal solution. The most prominent method, the simplex method, can to find the optimal solution. In 1947 Dantzig introduced the simplex method,
find the optimal solution of a linear program in polynomial time. that can find the optimal solution of a linear program in worst-case exponential
time. It was questioned whether the same problem could be solved in worst-case
polynomial time, until Khachiyan proved this possible when he introduced the
first of the so-called \emph{interior point} methods.
The same method provides the foundation for a harder problem. In \gls{lp} our These methods provide the foundation for a harder problem. In \gls{lp} our
variables must be continuous. If we require that one or more take a discrete variables must be continuous. If we require that one or more take a discrete
value (\(x_{i} \in \mathbb{N}\)), then the problem suddenly becomes much harder. value (\(x_{i} \in \mathbb{N}\)), then the problem suddenly becomes much harder.
The problem is referred to as \gls{mip} (or Integer Programming if \textbf{all} The problem is referred to as \gls{mip} (or Integer Programming if \textbf{all}
@ -845,15 +844,15 @@ Over the years \gls{lp} and \gls{mip} \solvers{} have developed immensely.
often worthwhile to encode problem as a mixed integer program to find a often worthwhile to encode problem as a mixed integer program to find a
solution. solution.
\glspl{csp} can be often be encoded as mixed integer programs. This does, To solve a \gls{csp}, it can be encoded as a mixed integer program. This
however, come with its challenges. Most \constraints{} in a \minizinc\ model are does, however, come with its challenges. Most \constraints{} in a \minizinc\
not linear equations. The translation of a single \constraint{} can introduce model are not linear equations. The translation of a single \constraint{} can
many linear \constraints{} and even new \variables{}. For example, when a introduce many linear \constraints{} and even new \variables{}. For example,
\constraint{} reasons about the value that a variable will take, to encode it we when a \constraint{} reasons about the value that a variable will take, to
will need to introduce \glspl{indicator-var}. The \glspl{indicator-var} encode it we will need to introduce \glspl{indicator-var}. The
\(y_{i}\) for a \variable{} \(x\) take the value 1 if \(x = i\) and 0 otherwise. \glspl{indicator-var} \(y_{i}\) for a \variable{} \(x\) take the value 1 if
\constraints{} reasoning about the value of \(x\) can then be rewritten as \(x = i\) and 0 otherwise. \constraints{} reasoning about the value of \(x\) can
linear \constraints{} using the \variables{} \(y_{i}\). then be rewritten as linear \constraints{} using the \variables{} \(y_{i}\).
\begin{example} \begin{example}
Let us again consider the N-Queens problem from \cref{ex:back-nqueens}. The Let us again consider the N-Queens problem from \cref{ex:back-nqueens}. The
@ -878,7 +877,7 @@ linear \constraints{} using the \variables{} \(y_{i}\).
The \cref{line:back-mip-channel} is used to connect the \(q\) and \(y\) The \cref{line:back-mip-channel} is used to connect the \(q\) and \(y\)
\variables{} and make sure that their values correspond. \variables{} and make sure that their values correspond.
\Cref{line:back-mip-row} ensures that only one queen is placed in the same \Cref{line:back-mip-row} ensures that only one queen is placed in the same
row. Finally, \cref{line:back-mip-diag1,line:back-mip-diag2} constrain all column. Finally, \cref{line:back-mip-diag1,line:back-mip-diag2} constrain all
diagonals to contain only one queen. diagonals to contain only one queen.
\end{example} \end{example}
@ -887,26 +886,26 @@ linear \constraints{} using the \variables{} \(y_{i}\).
\glsreset{sat} \glsreset{sat}
\glsreset{maxsat} \glsreset{maxsat}
\gls{sat} was the first problem to be proven to be \gls{np-comp} \gls{sat} was the first problem to be proven to be \gls{np}-complete
\autocite{cook-1971-sat}. The problem asks if there is an assignment for the \autocite{cook-1971-sat}. The problem asks if there is an assignment for the
variables of a given Boolean formula, such that the formula is satisfied. This variables of a given Boolean formula, such that the formula is satisfied. This
problem can be seen as a restriction of the general \gls{csp} where \variables{} problem can be seen as a restriction of the general \gls{csp} where \variables{}
can only be of a Boolean type. can only be of a Boolean type.
There is a field of research dedicated to solving \gls{sat} problems. In this There is a field of research dedicated to solving \gls{sat} problems
field a \gls{sat} problem is generally standardised to be in \gls{cnf}. A \autocite{biere-2021-sat}. In this field a \gls{sat} problem is generally
\gls{cnf} is formulated in terms of Boolean literals. These are variables \(x\) standardised to be in \gls{cnf}. A \gls{cnf} is formulated in terms of Boolean
or their negations \(\neg x\). These literals are then used in a conjunction of literals. These are variables \(x\) or their negations \(\neg x\). These
disjunctive clauses: a Boolean formula in the form literals are then used in a conjunction of disjunctive clauses: a Boolean
\(\forall_{i \in P} \exists_{b \in C_{i}} b\). To solve the \gls{sat} problem, formula in the form \(\forall_{i \in P} \exists_{b \in C_{i}} b\). To solve the
the \solver{} has to find an assignment for the \variables{} where at least one \gls{sat} problem, the \solver{} has to find an assignment for the \variables{}
literal is true in every clause. where at least one literal is true in every clause.
Even though the problem is proven to be hard to solve, a lot of progress has Even though the problem is proven to be hard to solve, a lot of progress has
been made towards solving even the biggest the most complex \gls{sat} problems been made towards solving even the biggest the most complex \gls{sat} problems.
\autocite{biere-2021-sat}. Modern day \gls{sat} solvers, like Kissat Modern day \gls{sat} solvers, like Kissat \autocite{biere-2021-kissat} and Clasp
\autocite{biere-2021-kissat} and Clasp \autocite{gebser-2012-clasp}, can solve \autocite{gebser-2012-clasp}, can solve instances of the problem with thousands
instances of the problem with thousands of \variables{} and clauses. of \variables{} and clauses.
Many real world problems modelled in \cmls\ directly correspond to \gls{sat}. Many real world problems modelled in \cmls\ directly correspond to \gls{sat}.
However, even problems that contain \variables{} with types other than Boolean However, even problems that contain \variables{} with types other than Boolean
@ -932,7 +931,7 @@ efficient way to solve the problem.
The encoding of the problem uses a Boolean \variable{} for every position of The encoding of the problem uses a Boolean \variable{} for every position of
the chess board. Each \variable{} represents if a queen will be located on the chess board. Each \variable{} represents if a queen will be located on
this position or not. \Cref{line:back-sat-at-least} forces that a queen is this position or not. \Cref{line:back-sat-at-least} forces that a queen is
placed on every column of the chess board. placed on every row of the chess board.
\Cref{line:back-sat-row,line:back-sat-col} ensure that only one queens is \Cref{line:back-sat-row,line:back-sat-col} ensure that only one queens is
place in each row and column respectively. place in each row and column respectively.
\Cref{line:back-sat-diag1,line:back-sat-diag2} similarly constrain each \Cref{line:back-sat-diag1,line:back-sat-diag2} similarly constrain each
@ -1147,8 +1146,8 @@ the solver. Take, for example, the following \gls{opl} search definition:
This search strategy will ensure that we first try and find a solution where the This search strategy will ensure that we first try and find a solution where the
\variable{} \mzninline{x} takes a value smaller than \mzninline{y}, if it does \variable{} \mzninline{x} takes a value smaller than \mzninline{y}, if it does
not find a solution, then it will try finding a solution where the oposite is not find a solution, then it will try finding a solution where the opposite is
true. This search specification, like many other imaginable, cannot be enforce true. This search specification, like many others imaginable, cannot be enforced
using \minizinc\ \gls{search-heuristic} \glspl{annotation}. using \minizinc\ \gls{search-heuristic} \glspl{annotation}.
To support \gls{opl}'s dedicated search language, the language is tightly To support \gls{opl}'s dedicated search language, the language is tightly
@ -1175,7 +1174,7 @@ variable types that are contained in \minizinc{}, \gls{essence} also contains:
Since sets, multi-sets, and functions can be defined on any other type, these Since sets, multi-sets, and functions can be defined on any other type, these
types can be arbitrary nested and the modeller can define, for example, a types can be arbitrary nested and the modeller can define, for example, a
\variable{} that is a sets of sets of integers. Partitions can be defined for \variable{} that is a sets of sets of integers. Partitions can be defined for
finite types. These types in \gls{essence} are restricted to Boolean, finite types. The base types in \gls{essence} are restricted to Boolean,
enumerated types, or a restricted set of integers. enumerated types, or a restricted set of integers.
\begin{example} \begin{example}
@ -1246,15 +1245,17 @@ the targeted solver.
\label{sec:back-term} \label{sec:back-term}
\glsreset{trs} \glsreset{trs}
At the heart of the flattening process lies a \gls{trs}. A \gls{trs} At the heart of the flattening process, the process as described in
\autocite{baader-1998-term-rewriting} describes a computational model the full \cref{sec:back-minizinc} that translates a \minizinc{} instance into solver
process can be described as the application of rules level \flatzinc{}, lies a \gls{trs}. A \gls{trs} describes a computational model
\(l \rightarrow r_{1}, \ldots r_{n}\), that replace a \gls{term} \(l\) with one the full process can be described as the application of rules
or more \glspl{term} \(r_{1}, \ldots r_{n}\). A \gls{term} is an expression with \(l \rightarrow r_{1}, \ldots, r_{n}\), that replace a \gls{term} \(l\) with one
nested sub-expressions consisting of \emph{function} and \emph{constant} or more \glspl{term} \(r_{1}, \ldots, r_{n}\)
symbols. An example of a term is \(F(0 + 1,F(1,0))\), where \(F\) and \(+\) are \autocite{baader-1998-term-rewriting}. A \gls{term} is an expression with nested
function symbols and \(0\) and \(1\) are constant symbols. In a term rewriting sub-expressions consisting of \emph{function} and \emph{constant} symbols. An
rule, a term can also contain a \emph{term variable} which captures a term example of a term is \(F(0 + 1,F(1,0))\), where \(F\) and \(+\) are function
symbols and \(0\) and \(1\) are constant symbols. In a term rewriting rule, a
term can also contain a \emph{term variable} which captures a term
sub-expression. sub-expression.
\begin{example} \begin{example}
@ -1323,9 +1324,10 @@ symbol might be replaced or equated with a constant symbol, but, different from
\cmls{}, this is not a requirement. A variable can remain a name in the solution \cmls{}, this is not a requirement. A variable can remain a name in the solution
of a constraint logic program. This means that the solution of a constraint of a constraint logic program. This means that the solution of a constraint
logic program can be a relationship between different variables. In cases where logic program can be a relationship between different variables. In cases where
an instantiated solution is required, a special \mzninline{labeling} constraint an instantiated solution is required, a special \mzninline{labeling}
can be used to force a variable to take a constant value. Similarly, there is a \constraint{} can be used to force a variable to take a constant value.
\mzninline{minimize} that can be used to find the optimal value for a variable. Similarly, there is a \mzninline{minimize} \constraint{} that can be used to
find the optimal value for a variable.
The evaluation of a constraint logic program rewrites the list of constraints, The evaluation of a constraint logic program rewrites the list of constraints,
called the goal, in the order given by the programmer. The rewriting of the called the goal, in the order given by the programmer. The rewriting of the
@ -1534,17 +1536,17 @@ happens in one of two ways:
\begin{itemize} \begin{itemize}
\item For Boolean expressions in a reified context, the new \variable{} is \item For Boolean expressions in a non-root context, the new \variable{} is
inserted by the flattening process itself. To constrain this inserted by the flattening process itself. To constrain this
\variable{}, the flattener will then add a new reified constraint. This \variable{}, the flattener will then add the \gls{reification} of the
constraint contains a call a variation of the call that would have been constraint. This constraint contains a call a variation of the call that
generated for the expression in root context. The name of the function would have been generated for the expression in root context. The name
is appended with \mzninline{_reif} and an extra Boolean \variable{} of the function is appended with \mzninline{_reif} and an extra Boolean
argument is added to the call. The definition of this constraint should \variable{} argument is added to the call. The definition of this
implement the reification of the original expression: setting the constraint should implement the reification of the original expression:
additional argument to \mzninline{true} if the constraint is satisfied, setting the additional argument to \mzninline{true} if the constraint is
and \mzninline{false} otherwise. For example, the constraint in satisfied, and \mzninline{false} otherwise. For example, the constraint
\minizinc{} in \minizinc{}
\begin{mzn} \begin{mzn}
constraint b \/ this_call(x, y); constraint b \/ this_call(x, y);
@ -1763,9 +1765,8 @@ they directly received the equivalent linear \constraint{}:
constraint int_lin_le([1,2,-1], [x,y,z], 0) constraint int_lin_le([1,2,-1], [x,y,z], 0)
\end{mzn} \end{mzn}
Since many solvers support linear constraints, it is often an Since many solvers support linear constraints, it is often an additional burden
additional burden to have intermediate values that have to be given a value in to have intermediate values that have to be given a value in the solution.
the solution.
This can be resolved using the \gls{aggregation} of constraints. When we This can be resolved using the \gls{aggregation} of constraints. When we
aggregate constraints we collect multiple \minizinc\ expressions, that would aggregate constraints we collect multiple \minizinc\ expressions, that would
@ -1840,22 +1841,24 @@ the \glspl{domain} of \variables{} used by other delayed \constraints{}.
\label{subsec:back-fzn-optimisation} \label{subsec:back-fzn-optimisation}
After the compiler is done flattening the \minizinc\ instance, it enters the After the compiler is done flattening the \minizinc\ instance, it enters the
optimisation phase. This phase occurs at the same stage as the solver input optimisation phase. This phase occurs at the level at which the targeted
language. Depending on the targeted \solver{}, the \minizinc\ flattener might \solver{} operates. Depending on this \solver{}, the \minizinc\ flattener might
still understand the meaning of certain constraints. In these cases, still understand the meaning of certain \constraints{}. In these cases,
\gls{propagation} methods (as discussed in \cref{subsec:back-cp}) can be used to \gls{propagation} methods, as discussed in \cref{subsec:back-cp}, can be used to
eliminate values from variable \glspl{domain} and simplify \constraints{}. eliminate values from variable \glspl{domain} and simplify \constraints{}.
In the current implementation the main focus of the flattener is to propagate In the current implementation the main focus of the flattener is to propagate
Boolean constraint. The flattener try and reduce the number of Boolean variables Boolean \constraints{}. The flattener tries to reduce the number of Boolean
and try and reduce the number of literals in clauses or logical and constraints. \variables{} and tries to reduce the number of literals in clauses and
The additional propagation might fix the reification of a constraint. If this conjunctions. The additional propagation might fix the result of the
constraint is not yet rewritten, then the \solver{} will know to use a direct \gls{reification} of a constraint. If this constraint is not yet rewritten, then
constraint instead of a reified version. the \solver{} will know to use a direct constraint instead of a reified version.
Even more important than the Boolean constraints, are equality \constraints{}. Even more important than the Boolean \constraints{}, are equality
The flattening is in the unique position to \gls{unify} \variables{} when they \constraints{}. The flattening is in the unique position to \gls{unify}
are found to be equal. Since they both have to take the same value, only a \variables{} when they are found to be equal. Since they both have to take the
single \variable{} is required in the \flatzinc\ model to represent them both. same value, only a single \variable{} is required in the \flatzinc\ model to
Whenever any (recognisable) equality constraint is found during the optimisation represent them both. Whenever any (recognisable) equality constraint is found
phase, it is removed and the two \variables{} are unified. during the optimisation phase, it is removed and the two \variables{} are
unified. Once initialised, it is not always possible for \solvers{} to
\gls{unify} \variables{} internally.