Fix indentation using latexindent
This commit is contained in:
parent
097d359724
commit
fb565cf28c
@ -4,7 +4,7 @@
|
||||
year = 1978,
|
||||
isbn = {007001115X},
|
||||
publisher = {McGraw-Hill, Inc.},
|
||||
address = {USA},
|
||||
address = {USA}
|
||||
}
|
||||
|
||||
@inproceedings{araya-2008-cse-numcsp,
|
||||
@ -29,7 +29,7 @@
|
||||
@book{baader-1998-term-rewriting,
|
||||
place = {Cambridge},
|
||||
title = {Term Rewriting and All That},
|
||||
DOI = {10.1017/CBO9781139172752},
|
||||
doi = {10.1017/CBO9781139172752},
|
||||
publisher = {Cambridge University Press},
|
||||
author = {Baader, Franz and Nipkow, Tobias},
|
||||
year = 1998
|
||||
@ -107,6 +107,13 @@
|
||||
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||
}
|
||||
|
||||
@software{biere-2021-kissat,
|
||||
title = {Kissat},
|
||||
version = {2021},
|
||||
author = {Armin Biere},
|
||||
url = {http://fmv.jku.at/kissat/}
|
||||
}
|
||||
|
||||
@book{biere-2021-sat,
|
||||
title = {Handbook of Satisfiability},
|
||||
author = {Biere, A. and Heule, M. and Van Maaren, H. and Walsh, T.},
|
||||
@ -115,7 +122,7 @@
|
||||
url = {https://books.google.com.au/books?id=YVSM3sxhBhcC},
|
||||
year = 2021,
|
||||
publisher = {IOS Press},
|
||||
edition = 2,
|
||||
edition = 2
|
||||
}
|
||||
|
||||
@article{bjordal-2015-fzn2oscarcbls,
|
||||
@ -184,11 +191,18 @@
|
||||
url = {https://doi.org/10.1007/s10732-011-9158-2},
|
||||
doi = {10.1007/s10732-011-9158-2},
|
||||
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}
|
||||
}
|
||||
|
||||
@software{chuffed-2021-chuffed,
|
||||
author = {Geoffrey Chu and Peter J. Stuckey and Andreas Schutt and Thorsten Ehlers and Graeme Gange and Kathryn Francis},
|
||||
title = {Chuffed, a lazy clause generation solver},
|
||||
year = 2021,
|
||||
url = {https://github.com/chuffed/chuffed},
|
||||
version = {0.10.3}
|
||||
}
|
||||
|
||||
@article{cocke-1970-cse,
|
||||
author = {Cocke, John},
|
||||
title = {Global Common Subexpression Elimination},
|
||||
@ -287,20 +301,27 @@
|
||||
bibsource = {dblp computer science bibliography, https://dblp.org}
|
||||
}
|
||||
|
||||
@software{chuffed-2021-chuffed,
|
||||
author = {Geoffrey Chu and Peter J. Stuckey and Andreas Schutt and Thorsten Ehlers and Graeme Gange and Kathryn Francis},
|
||||
title = {Chuffed, a lazy clause generation solver},
|
||||
year = 2021,
|
||||
url = {https://github.com/chuffed/chuffed},
|
||||
version = {0.10.3},
|
||||
}
|
||||
|
||||
@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},
|
||||
@software{forrest-2020-cbc,
|
||||
author = {Forrest, J. and
|
||||
Stefan Vigerske and
|
||||
Haroldo Gambini Santos and
|
||||
Ted Ralphs and
|
||||
Lou Hafer and
|
||||
Bjarni Kristjansson and
|
||||
Fasano, J.P. and
|
||||
EdwinStraver and
|
||||
Miles Lubin and
|
||||
Lougee-Heimer, R. and
|
||||
jpgoncal1 and
|
||||
Gassmann, H.I. and
|
||||
Matthew Saltzman},
|
||||
title = {coin-or/Cbc: Version 2.10.5},
|
||||
month = mar,
|
||||
year = 2020,
|
||||
publisher = {Zenodo},
|
||||
version = {releases/2.10.5},
|
||||
doi = {10.5281/zenodo.3700700},
|
||||
url = {https://doi.org/10.5281/zenodo.3700700}
|
||||
}
|
||||
|
||||
@article{fourer-2002-amplcp,
|
||||
@ -319,14 +340,6 @@
|
||||
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},
|
||||
}
|
||||
|
||||
@book{fourer-2003-ampl,
|
||||
title = {AMPL: A Modeling Language for Mathematical Programming},
|
||||
author = {Fourer, R. and Gay, D.M. and Kernighan, B.W.},
|
||||
@ -404,6 +417,17 @@
|
||||
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{gebser-2012-clasp,
|
||||
author = {Martin Gebser and Benjamin Kaufmann and Torsten Schaub},
|
||||
title = {Conflict-driven answer set solving: From theory to
|
||||
@ -419,11 +443,19 @@
|
||||
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,
|
||||
author = {{Gurobi Optimization, LLC}},
|
||||
title = {Gurobi Optimizer Reference Manual},
|
||||
year = 2021,
|
||||
url = {http://www.gurobi.com},
|
||||
url = {http://www.gurobi.com}
|
||||
}
|
||||
|
||||
@inproceedings{hebrard-2005-diverse,
|
||||
@ -516,11 +548,10 @@
|
||||
year = 1997,
|
||||
issn = {0377-2217},
|
||||
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},
|
||||
keywords = {Project scheduling, Resource constraints, Benchmark
|
||||
instances},
|
||||
instances}
|
||||
}
|
||||
|
||||
@inproceedings{lagerkvist-2009-groups,
|
||||
@ -596,17 +627,6 @@
|
||||
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}
|
||||
}
|
||||
|
||||
@book{marriott-1998-clp,
|
||||
location = {Cambridge, Mass},
|
||||
title = {Programming with constraints: an introduction},
|
||||
@ -617,7 +637,7 @@
|
||||
author = {Marriott, Kim and Stuckey, Peter J.},
|
||||
date = 1998,
|
||||
keywords = {Constraint programming (Computer science), Logic
|
||||
programming},
|
||||
programming}
|
||||
}
|
||||
|
||||
@article{marriott-2008-zinc,
|
||||
@ -633,8 +653,7 @@
|
||||
url = {https://doi.org/10.1007/s10601-008-9041-4},
|
||||
doi = {10.1007/s10601-008-9041-4},
|
||||
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}
|
||||
}
|
||||
|
||||
@ -677,6 +696,14 @@
|
||||
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{nethercote-2007-minizinc,
|
||||
author = {Nicholas Nethercote and Peter J. Stuckey and Ralph Becket
|
||||
and Sebastian Brand and Gregory J. Duck and Guido Tack},
|
||||
@ -697,6 +724,15 @@
|
||||
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,
|
||||
author = {David Pisinger and Stefan Ropke},
|
||||
title = {A general heuristic for vehicle routing problems},
|
||||
@ -734,7 +770,7 @@
|
||||
year = 2016,
|
||||
organization = {TASC, INRIA Rennes, LINA CNRS UMR 6241, COSLING S.A.S.},
|
||||
timestamp = {Tue, 9 Feb 2016},
|
||||
url = {http://www.choco-solver.org },
|
||||
url = {http://www.choco-solver.org }
|
||||
}
|
||||
|
||||
@inproceedings{rendl-2009-enhanced-tailoring,
|
||||
@ -748,13 +784,23 @@
|
||||
8-10 August 2009},
|
||||
publisher = {{AAAI}},
|
||||
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},
|
||||
biburl = {https://dblp.org/rec/conf/sara/RendlMGJ09.bib},
|
||||
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,
|
||||
author = {Andrea Rendl and Tias Guns and Peter J. Stuckey and Guido
|
||||
Tack},
|
||||
@ -813,22 +859,10 @@
|
||||
url = {https://doi.org/10.1007/s10601-018-9289-2},
|
||||
doi = {10.1007/s10601-018-9289-2},
|
||||
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}
|
||||
}
|
||||
|
||||
@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}
|
||||
}
|
||||
|
||||
@book{schrijver-1998-mip,
|
||||
title = {Theory of Linear and Integer Programming},
|
||||
author = {Schrijver, A.},
|
||||
@ -851,8 +885,7 @@
|
||||
url = {https://doi.org/10.1007/s10601-012-9137-8},
|
||||
doi = {10.1007/s10601-012-9137-8},
|
||||
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}
|
||||
}
|
||||
|
||||
@ -1013,7 +1046,7 @@
|
||||
title = {Constraint processing in cc(FD)},
|
||||
author = {Van Hentenryck, P. and Saraswat, V. and Deville, Y.},
|
||||
year = 1992,
|
||||
note = {Manuscript},
|
||||
note = {Manuscript}
|
||||
}
|
||||
|
||||
@book{van-hentenryck-1999-opl,
|
||||
@ -1048,29 +1081,6 @@
|
||||
combinatorial optimization}
|
||||
}
|
||||
|
||||
@software{forrest-2020-cbc,
|
||||
author = {Forrest, J. and
|
||||
Stefan Vigerske and
|
||||
Haroldo Gambini Santos and
|
||||
Ted Ralphs and
|
||||
Lou Hafer and
|
||||
Bjarni Kristjansson and
|
||||
Fasano, J.P. and
|
||||
EdwinStraver and
|
||||
Miles Lubin and
|
||||
Lougee-Heimer, R. and
|
||||
jpgoncal1 and
|
||||
Gassmann, H.I. and
|
||||
Matthew Saltzman},
|
||||
title = {coin-or/Cbc: Version 2.10.5},
|
||||
month = mar,
|
||||
year = 2020,
|
||||
publisher = {Zenodo},
|
||||
version = {releases/2.10.5},
|
||||
doi = {10.5281/zenodo.3700700},
|
||||
url = {https://doi.org/10.5281/zenodo.3700700}
|
||||
}
|
||||
|
||||
@book{wallis-2011-combinatorics,
|
||||
title = {Introduction to Combinatorics},
|
||||
author = {Wallis, W.D. and George, J.},
|
||||
@ -1080,15 +1090,6 @@
|
||||
publisher = {Taylor \& Francis}
|
||||
}
|
||||
|
||||
@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{warren-1983-wam,
|
||||
title = {An abstract Prolog instruction set},
|
||||
author = {Warren, David HD},
|
||||
@ -1097,13 +1098,6 @@
|
||||
publisher = {SRI International}
|
||||
}
|
||||
|
||||
@software{biere-2021-kissat,
|
||||
title = {Kissat},
|
||||
version = {2021},
|
||||
author = {Armin Biere},
|
||||
url = {http://fmv.jku.at/kissat/},
|
||||
}
|
||||
|
||||
@book{wolsey-1988-mip,
|
||||
title = {Integer and Combinatorial Optimization},
|
||||
author = {Wolsey, L.A. and Nemhauser, G.L.},
|
||||
|
||||
@ -1,3 +1,5 @@
|
||||
\usepackage{silence}
|
||||
\WarningFilter{biblatex}{File 'australian-apa.lbx'}
|
||||
\hfuzz=1.5pt
|
||||
\usepackage{fvextra}
|
||||
\usepackage{csquotes}
|
||||
@ -10,36 +12,36 @@
|
||||
\usepackage{fontspec}
|
||||
%% Main font
|
||||
\setmainfont{IBMPlexSerif}[
|
||||
Path=assets/fonts/IBM-Plex-Serif/,
|
||||
Extension=.otf,
|
||||
UprightFont=*-Regular,
|
||||
BoldFont=*-Bold,
|
||||
ItalicFont=*-Italic,
|
||||
BoldItalicFont=*-BoldItalic,
|
||||
Path=assets/fonts/IBM-Plex-Serif/,
|
||||
Extension=.otf,
|
||||
UprightFont=*-Regular,
|
||||
BoldFont=*-Bold,
|
||||
ItalicFont=*-Italic,
|
||||
BoldItalicFont=*-BoldItalic,
|
||||
]
|
||||
%% Title font
|
||||
\newfontfamily{\ibmplexsanscondensed}{IBMPlexSansCondensed}[
|
||||
Path=assets/fonts/IBM-Plex-Sans-Condensed/,
|
||||
Extension=.otf,
|
||||
UprightFont=*-Regular,
|
||||
BoldFont=*-Bold,
|
||||
ItalicFont=*-Italic,
|
||||
BoldItalicFont=*-BoldItalic,
|
||||
Path=assets/fonts/IBM-Plex-Sans-Condensed/,
|
||||
Extension=.otf,
|
||||
UprightFont=*-Regular,
|
||||
BoldFont=*-Bold,
|
||||
ItalicFont=*-Italic,
|
||||
BoldItalicFont=*-BoldItalic,
|
||||
]
|
||||
\newfontfamily{\satisfyfont}{Satisfy}[
|
||||
Path=assets/fonts/Satisfy/,
|
||||
Extension=.ttf,
|
||||
UprightFont=*-Regular,
|
||||
Path=assets/fonts/Satisfy/,
|
||||
Extension=.ttf,
|
||||
UprightFont=*-Regular,
|
||||
]
|
||||
%% Monospace font
|
||||
\setmonofont{IBMPlexMono}[
|
||||
Ligatures=TeX,
|
||||
Path=assets/fonts/IBM-Plex-Mono/,
|
||||
Extension=.otf,
|
||||
UprightFont=*-Regular,
|
||||
BoldFont=*-Bold,
|
||||
ItalicFont=*-Italic,
|
||||
BoldItalicFont=*-BoldItalic,
|
||||
Ligatures=TeX,
|
||||
Path=assets/fonts/IBM-Plex-Mono/,
|
||||
Extension=.otf,
|
||||
UprightFont=*-Regular,
|
||||
BoldFont=*-Bold,
|
||||
ItalicFont=*-Italic,
|
||||
BoldItalicFont=*-BoldItalic,
|
||||
]
|
||||
%% Mathmatical font
|
||||
\usepackage{amsmath}
|
||||
@ -48,7 +50,7 @@ BoldItalicFont=*-BoldItalic,
|
||||
|
||||
% References
|
||||
\usepackage[
|
||||
style=apa,
|
||||
style=apa,
|
||||
]{biblatex}
|
||||
\usepackage[noabbrev]{cleveref}
|
||||
|
||||
@ -134,9 +136,9 @@ style=apa,
|
||||
|
||||
% Code formatting
|
||||
\usepackage[
|
||||
chapter,
|
||||
cachedir=listings,
|
||||
outputdir=build,
|
||||
chapter,
|
||||
cachedir=listings,
|
||||
outputdir=build,
|
||||
]{minted}
|
||||
\usemintedstyle{borland}
|
||||
|
||||
@ -164,7 +166,7 @@ outputdir=build,
|
||||
colframe=white,
|
||||
}
|
||||
\BeforeBeginEnvironment{minted}{\begin{listingbox}}
|
||||
\AfterEndEnvironment{minted}{\end{listingbox}}
|
||||
\AfterEndEnvironment{minted}{\end{listingbox}}
|
||||
|
||||
\newcommand{\ptinline}[1]{{\texttt{\small {#1}}}}
|
||||
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
\chapter{Introduction}\label{ch:introduction}
|
||||
%************************************************
|
||||
|
||||
High-level \cmls, like \minizinc, were originally designed as a convenient input
|
||||
High-level \cmls{}, like \minizinc{}, were originally designed as a convenient input
|
||||
language for \gls{cp} solvers \autocite{marriott-1998-clp}. A user would write a
|
||||
model consisting of a few loops or comprehensions; given a data file for the
|
||||
parameters, this would be rewritten into a relatively small set of constraints
|
||||
@ -14,13 +14,13 @@ acceptable: models (both before and after translation) were small, translation
|
||||
was fast, and the expected results of translation were obvious. The current
|
||||
architecture is illustrated in \Cref{sfig:4-oldarch}.
|
||||
|
||||
But over time, the uses of high-level \cmls\ have expanded greatly from this
|
||||
But over time, the uses of high-level \cmls{} have expanded greatly from this
|
||||
original vision. It is now used to generate input for wildly different solver
|
||||
technologies: not just \gls{cp}, but also \gls{mip} \autocite{wolsey-1988-mip},
|
||||
\gls{sat} \autocite{davis-1962-dpll} and \gls{cbls}
|
||||
\autocite{bjordal-2015-fzn2oscarcbls} solvers. Crucially, the same constraint
|
||||
model can be used with any of these solvers, which is achieved through the use
|
||||
of solver-specific libraries of constraint definitions. In \minizinc, these
|
||||
of solver-specific libraries of constraint definitions. In \minizinc{}, these
|
||||
solver libraries are written in the same language.
|
||||
|
||||
As such, \minizinc\ turned out to be much more expressive than expected, so more
|
||||
@ -36,31 +36,32 @@ weaknesses of the existing \minizinc\ tool chain. In particular:
|
||||
|
||||
\begin{itemize}
|
||||
\item The \minizinc\ compiler is inefficient. It does a surprisingly large
|
||||
amount of work for each expression (especially resolving sub-typing and
|
||||
overloading), which may be repeated many times --- for example, inside
|
||||
the body of a comprehension. And as models generated for other solver
|
||||
technologies (particularly \gls{mip}) can be quite large, the resulting
|
||||
flattening procedure can be intolerably slow. As the model
|
||||
transformations implemented in \minizinc\ become more sophisticated,
|
||||
these performance problems are simply magnified.
|
||||
\item The generated models often contain unnecessary constraints. During the
|
||||
transformation, functional expressions are replaced with constraints.
|
||||
But this breaks the functional dependencies: if the original expression
|
||||
later becomes redundant (due to model simplifications), \minizinc\ may
|
||||
fail to detect that the constraint can be removed.
|
||||
amount of work for each expression (especially resolving sub-typing
|
||||
and overloading), which may be repeated many times --- for example,
|
||||
inside the body of a comprehension. And as models generated for
|
||||
other solver technologies (particularly \gls{mip}) can be quite
|
||||
large, the resulting flattening procedure can be intolerably slow.
|
||||
As the model transformations implemented in \minizinc\ become more
|
||||
sophisticated, these performance problems are simply magnified.
|
||||
\item The generated models often contain unnecessary constraints. During
|
||||
the transformation, functional expressions are replaced with
|
||||
constraints. But this breaks the functional dependencies: if the
|
||||
original expression later becomes redundant (due to model
|
||||
simplifications), \minizinc\ may fail to detect that the constraint
|
||||
can be removed.
|
||||
\item Monolithic flattening is wasteful. When \minizinc\ is used for
|
||||
multi-shot solving, there is typically a large base model common to all
|
||||
subproblems, and a small set of constraints which are added or removed
|
||||
in each iteration. But with the existing \minizinc\ architecture, the
|
||||
whole model must be re-flattened each time. Many use cases involve
|
||||
generating a base model, then repeatedly adding or removing a few
|
||||
constraints before re-solving. In the current tool chain, the whole
|
||||
model must be fully re-flattened each time. Not only does this repeat
|
||||
all the work done to flatten the base model, This means a large
|
||||
(sometimes dominant) portion of runtime is simply flattening the core
|
||||
model over and over again. But it also prevents \emph{the solver} from
|
||||
carrying over anything it learnt from one problem to the next, closely
|
||||
related, problem.
|
||||
multi-shot solving, there is typically a large base model common to
|
||||
all sub-problems, and a small set of constraints which are added or
|
||||
removed in each iteration. But with the existing \minizinc\
|
||||
architecture, the whole model must be re-flattened each time. Many
|
||||
use cases involve generating a base model, then repeatedly adding or
|
||||
removing a few constraints before re-solving. In the current tool
|
||||
chain, the whole model must be fully re-flattened each time. Not
|
||||
only does this repeat all the work done to flatten the base model,
|
||||
This means a large (sometimes dominant) portion of runtime is simply
|
||||
flattening the core model over and over again. But it also prevents
|
||||
\emph{the solver} from carrying over anything it learnt from one
|
||||
problem to the next, closely related, problem.
|
||||
\end{itemize}
|
||||
|
||||
In this thesis, we revisit the rewriting of high-level \cmls\ into solver-level
|
||||
|
||||
@ -1,5 +1,5 @@
|
||||
%************************************************
|
||||
\chapter{Review of Literature}\label{ch:background}
|
||||
\chapter{Background}\label{ch:background}
|
||||
%************************************************
|
||||
|
||||
A goal shared between all programming languages is to provide a certain level of
|
||||
@ -34,12 +34,6 @@ solution, these models can generally be given to a dedicated solving program, or
|
||||
\solver{} for short, that can find a solution that fits the requirements of the
|
||||
model.
|
||||
|
||||
\begin{listing}
|
||||
\pyfile{assets/py/2_dyn_knapsack.py}
|
||||
\caption{\label{lst:2-dyn-knapsack} A Python program that solves a 0-1 knapsack
|
||||
problem using dynamic programming}
|
||||
\end{listing}
|
||||
|
||||
\begin{example}%
|
||||
\label{ex:back-knapsack}
|
||||
|
||||
@ -78,6 +72,12 @@ model.
|
||||
|
||||
\end{example}
|
||||
|
||||
\begin{listing}
|
||||
\pyfile{assets/py/2_dyn_knapsack.py}
|
||||
\caption{\label{lst:2-dyn-knapsack} A Python program that solves a 0-1 knapsack
|
||||
problem using dynamic programming}
|
||||
\end{listing}
|
||||
|
||||
In the remainder of this chapter we will first, in \cref{sec:back-minizinc} we
|
||||
introduce \minizinc\ as the leading \cml\ used within this thesis. In
|
||||
\cref{sec:back-solving} we discuss how \gls{cp} can be used to solve a
|
||||
@ -445,14 +445,13 @@ resulting definition. There are three main purposes for \glspl{let}:
|
||||
multiplication constraint \mzninline{pred_int_times}.
|
||||
\end{enumerate}
|
||||
|
||||
An important detail in flattening \glspl{let} is that any \variables{} that
|
||||
are introduced might need to be renamed in the resulting solver level model.
|
||||
Different from top-level definitions, the \variables{} declared in
|
||||
\glspl{let} can be flattened multiple times when used in loops, function
|
||||
definitions (that are called multiple times), and \gls{array}
|
||||
\glspl{comprehension}. In these cases the flattener must assign any
|
||||
\variables{} in the \gls{let} a new name and use this name in any subsequent
|
||||
definitions and in the resulting expression.
|
||||
An important detail in flattening \glspl{let} is that any \variables{} that are
|
||||
introduced might need to be renamed in the resulting solver level model.
|
||||
Different from top-level definitions, the \variables{} declared in \glspl{let}
|
||||
can be flattened multiple times when used in loops, function definitions (that
|
||||
are called multiple times), and \gls{array} \glspl{comprehension}. In these
|
||||
cases the flattener must assign any \variables{} in the \gls{let} a new name and
|
||||
use this name in any subsequent definitions and in the resulting expression.
|
||||
|
||||
\subsection{Reification}%
|
||||
\label{subsec:back-reification}
|
||||
@ -460,8 +459,8 @@ definitions and in the resulting expression.
|
||||
With the rich expression language in \minizinc{}, \constraints{} can consist of
|
||||
complex expressions that do not translate to a single constraint at the
|
||||
\solver{} level. Instead, different parts of a complex expression will be
|
||||
translated into different \constraints{}. Not all of these \constraints{} will be
|
||||
globally enforced by the solver. \constraints{} stemming for sub-expressions
|
||||
translated into different \constraints{}. Not all of these \constraints{} will
|
||||
be globally enforced by the solver. \constraints{} stemming for sub-expressions
|
||||
will typically be \emph{reified} into a Boolean variable. \Gls{reification}
|
||||
means that a variable \mzninline{b} is constrained to be true if and only if a
|
||||
corresponding constraint \mzninline{c(...)} holds.
|
||||
@ -509,8 +508,8 @@ Some expressions in the \cmls\ do not always have a well-defined result.
|
||||
the constraint should be trivially true.
|
||||
\end{example}
|
||||
|
||||
Part of the semantics of a \cmls{} is the choice as to how to treat these partial
|
||||
functions. Examples of such expressions in \minizinc\ are:
|
||||
Part of the semantics of a \cmls{} is the choice as to how to treat these
|
||||
partial functions. Examples of such expressions in \minizinc\ are:
|
||||
|
||||
\begin{itemize}
|
||||
\item Division (or modulus) when the divisor is zero:
|
||||
|
||||
@ -22,7 +22,7 @@ larger.
|
||||
|
||||
In this chapter, we revisit the rewriting of high-level \cmls\ into solver-level
|
||||
constraint models. We describe a new \textbf{systematic view of the execution of
|
||||
\minizinc{}} and build on this to propose a new tool chain. We show how this
|
||||
\minizinc{}} and build on this to propose a new tool chain. We show how this
|
||||
tool chain allows us to:
|
||||
|
||||
\begin{itemize}
|
||||
@ -409,24 +409,24 @@ identifiers are fresh (\ie\ not used in the rest of the \nanozinc\ program), by
|
||||
suitable alpha renaming.
|
||||
|
||||
\begin{figure*}
|
||||
\centering
|
||||
\begin{prooftree}
|
||||
\centering
|
||||
\begin{prooftree}
|
||||
\hypo{\texttt{function} ~t\texttt{:}~\ptinline{F(\(p_1, \ldots{}, p_k\)) = E;} \in{} \Prog{} \text{~where the~} p_i \text{~are fresh}}
|
||||
\infer[no rule]1{\Sem{\(\ptinline{E}_{[p_i \mapsto a_i, \forall{} 1 \leq{} i \leq{} k]}\)}{\Prog, \Env} \Rightarrow{} \tuple{v, \Env'}}
|
||||
\infer1[(Call)]{\Sem{F(\(a_1, \ldots, a_k\))}{\Prog, \Env} \Rightarrow{} \tuple{v, \Env'}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\ptinline{F} \in \text{Builtins}}
|
||||
\infer1[(CallBuiltin)]{\Sem{F(\(a_1, \ldots, a_k\))}{\Prog, \Env} \Rightarrow{} \tuple{\ensuremath{\mathit{eval}(\ptinline{F}(a_1,\ldots, a_k))}, \Env}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\texttt{predicate}~\ptinline{F(\(p_1, \ldots, p_k\));} \in \Prog}
|
||||
\infer1[(CallPredicate)]{\Sem{F(\(a_1, \ldots, a_k\))}{\Prog, \Env} \Rightarrow{}
|
||||
\tuple{\ensuremath{\texttt{constraint}~\ptinline{F}(a_1, \ldots, a_k), \Env}}}
|
||||
\end{prooftree}
|
||||
\caption{\label{fig:4-rewrite-to-nzn-calls} Rewriting rules for partial evaluation
|
||||
\end{prooftree}
|
||||
\caption{\label{fig:4-rewrite-to-nzn-calls} Rewriting rules for partial evaluation
|
||||
of \microzinc\ calls to \nanozinc{}.}
|
||||
\end{figure*}
|
||||
|
||||
@ -449,46 +449,46 @@ considered primitives, and as such simply need to be transferred into the
|
||||
\nanozinc\ program.
|
||||
|
||||
\begin{figure*}
|
||||
\centering
|
||||
\begin{prooftree}
|
||||
\centering
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(\mathbf{I} \mid{} \mathbf{X}\)}{\Prog, \Env, \emptyset} \Rightarrow \tuple{x, \Env'}}
|
||||
\infer1[(Let)]{\Sem{let \{ \(\mathbf{I}\) \} in \(\mathbf{X}\)}{\Prog, \Env} \Rightarrow\ \tuple{x, \Env'}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(\mathbf{X}\)}{\Prog, \{ t : x \} \cup{} \Env} \Rightarrow \tuple{x, \{ t: x \} \cup{} \Env'}}
|
||||
\infer1[(Item0)]{\Sem{\(\epsilon{} \mid{} \mathbf{X}\)}{\Prog, \{ t: x \}\cup{}\Env, \Ctx} \Rightarrow{} \tuple{x, \{ t: x \texttt{~↳~} \Ctx{} \} \cup{} \Env'}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(\mathbf{I} \mid{} \mathbf{X}\)}{\Prog, \Env\ \cup\ \{t : x\}, \Ctx} \Rightarrow \tuple{x, \Env'}}
|
||||
\infer1[(ItemT)]{\Sem{\(t\texttt{:}~x\texttt{;} \mathbf{I} \mid{} \mathbf{X}\)}{\Prog, \Env, \Ctx} \Rightarrow{} \tuple{x, \Env'}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(E\)}{\Prog, \Env} \Rightarrow \tuple{v, \Env'}}
|
||||
\hypo{\Sem{\(\mathbf{I}_{[x \mapsto v]} \mid{} \mathbf{X}_{[x \mapsto v]}\)}{\Prog, \Env', \Ctx} \Rightarrow\ \tuple{x, \Env''}}
|
||||
\infer2[(ItemTE)]{\Sem{\(t\texttt{:}~x = E\texttt{;} \mathbf{I} \mid{} \mathbf{X}\)}{\Prog, \Env, \Ctx} \Rightarrow\ \tuple{x, \Env''}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(E_{i}\)}{\Prog,\Env^{i-1}} \Rightarrow \tuple{v_{i}, \Env^{i}}, \forall{} 1 \leq{} i \leq{} k}
|
||||
\infer[no rule]1{\Sem{\(\mathbf{I}_{[x_{\langle{}i\rangle} \mapsto v_{i}, \forall{} 1 \leq{} i \leq{} k]} \mid{} \mathbf{X}_{[x_{\langle{}i\rangle} \mapsto v_{i}, \forall{} 1 \leq{} i \leq{} k]}\)}{\Prog, \Env^{k}, \Ctx} \Rightarrow\ \tuple{x, \Env'}}
|
||||
\infer1[(ItemTupC)]{\Sem{\( \texttt{tuple(}t_{1}, \ldots, t_{k}\texttt{):}~x = \left(E_{1}, \ldots, E_{k}\right)\)}{\Prog, \Env^{0}, \Ctx} \Rightarrow{} \tuple{x, \Env'}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(E\)}{\Prog, \Env} \Rightarrow \tuple{\left(v_{\langle{}1\rangle}, \ldots, v_{\langle{}k\rangle}\right), \Env'}}
|
||||
\infer[no rule]1{\Sem{\(\mathbf{I}_{[x_{i} \mapsto v_{\langle{}i\rangle}, \forall{} 1 \leq{} i \leq{} k]} \mid{} \mathbf{X}_{[x_{i} \mapsto v_{\langle{}i\rangle}, \forall{} 1 \leq{} i \leq{} k]}\)}{\Prog, \Env', \Ctx} \Rightarrow\ \tuple{x, \Env''}}
|
||||
\infer1[(ItemTupD)]{\Sem{\(\left(t_{1}\texttt{:}~x_{1}, \ldots, t_{k}\texttt{:}~x_{k}\right) = E\texttt{;} \mathbf{I} \mid{} \mathbf{X}\)}{\Prog, \Env, \Ctx} \Rightarrow\ \tuple{x, \Env''}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(C\)}{\Prog, \Env} \Rightarrow \tuple{c, \Env'}}
|
||||
\hypo{\Sem{\(\mathbf{I} \mid{} \mathbf{X}\)}{\Prog, \Env', \{c\}\cup\Ctx} \Rightarrow \tuple{x, \Env''}}
|
||||
\infer2[(ItemC)]{\Sem{\(\mbox{constraint}~C\texttt{;} \mathbf{I} \mid{} \mathbf{X}\)}{\Prog, \Env, \Ctx} \Rightarrow\ \tuple{x, \Env''}}
|
||||
\end{prooftree}
|
||||
\caption{\label{fig:4-rewrite-to-nzn-let} Rewriting rules for partial evaluation
|
||||
\end{prooftree}
|
||||
\caption{\label{fig:4-rewrite-to-nzn-let} Rewriting rules for partial evaluation
|
||||
of \microzinc\ let expressions to \nanozinc{}.}
|
||||
\end{figure*}
|
||||
|
||||
@ -506,53 +506,53 @@ to mark the \(i^{\text{th}}\) member of the tuple \(x\) in our substitution
|
||||
notation.
|
||||
|
||||
\begin{figure*}
|
||||
\centering
|
||||
\begin{prooftree}
|
||||
\centering
|
||||
\begin{prooftree}
|
||||
\hypo{x \in \langle \text{ident} \rangle}
|
||||
\hypo{\{t: x \texttt{~↳~} \phi\ \} \in \Env}
|
||||
\infer2[(IdX)]{\Sem{\(x\)}{\Prog, \Env} \Rightarrow{} \tuple{x, \Env}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(x\)}{\Prog, \Env} \Rightarrow \tuple{[x_{1}, \ldots, x_{n}], \Env'}}
|
||||
\hypo{\Sem{\(i\)}{\Prog, \Env'} \Rightarrow \tuple{v, \Env''}}
|
||||
\hypo{v \in [1 \ldots{} n]}
|
||||
\infer3[(Access)]{\Sem{\(x\texttt{[}i\texttt{]}\)}{\Prog, \Env} \Rightarrow{} \tuple{x_{v}, \Env''}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{c \text{~constant}}
|
||||
\infer1[(Const)]{\Sem{\(c\)}{\Prog, \Env} \Rightarrow{} \tuple{c, \Env}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(C\)}{\Prog, \Env} \Rightarrow \tuple{\ptinline{true}, \_}}
|
||||
\infer1[(If\(_T\))]{\Sem{if \(C\) then \(E_t\) else \(E_e\) endif}{\Prog, \Env} \Rightarrow{} \Sem{\(E_t\)}{\Prog, \Env}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(C\)}{\Prog, \Env} \Rightarrow \tuple{\ptinline{false}, \_}}
|
||||
\infer1[(If\(_F\))]{\Sem{if \(C\) then \(E_t\) else \(E_e\) endif}{\Prog, \Env} \Rightarrow{} \Sem{\(E_e\)}{\Prog, \Env}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{G}{\Prog,\Env} \Rightarrow \tuple{ \ptinline{true}, \_}}
|
||||
\hypo{\Sem{\(E\)}{\Prog, \Env} \Rightarrow \tuple {v, \Env'}}
|
||||
\infer2[(WhereT)]{\Sem{\([E ~|~ \mbox{where~} G]\)}{\Prog, \Env} \Rightarrow{} \tuple{[v], \Env'}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{G}{\Prog,\Env} \Rightarrow \tuple{\ptinline{false}, \_}}
|
||||
\infer1[(WhereF)]{\Sem{\([E ~|~ \mbox{where~} G]\)}{\Prog, \Env} \Rightarrow{} \tuple{[], \Env}}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\end{prooftree} \\
|
||||
\bigskip
|
||||
\begin{prooftree}
|
||||
\hypo{\Sem{\(\mathit{PE}\)}{\Prog,\Env} \Rightarrow \tuple{S, \_}}
|
||||
\infer[no rule]1{\Sem{\([E ~|~ \mathit{GE} \mbox{~where~} G]\)}{\Prog, \Env_{[x \mapsto{} v]}} \Rightarrow{} \tuple{A_v, \Env_{[x \mapsto{} v]} \cup{} \Env{}_{v}}, \forall{} v \in{} S }
|
||||
\infer1[(ListG)]{\Sem{\([E~|~ x \mbox{~in~} \mathit{PE}, \mathit{GE} \mbox{~where~} G]\)}{\Prog, \Env} \Rightarrow{}
|
||||
\tuple{\mbox{concat} [ A_v~|~v \in{} S ], \Env{} \cup{} \bigcup{}_{v \in{} S} \Env{}_{v}}}
|
||||
\end{prooftree}
|
||||
\caption{\label{fig:4-rewrite-to-nzn-other} Rewriting rules for partial evaluation
|
||||
\end{prooftree}
|
||||
\caption{\label{fig:4-rewrite-to-nzn-other} Rewriting rules for partial evaluation
|
||||
of other \microzinc\ expressions to \nanozinc{}.}
|
||||
\end{figure*}
|
||||
|
||||
@ -1028,7 +1028,7 @@ Complex \minizinc\ expression can sometimes result in the creation of many new
|
||||
variables that represent intermediate results. This is in particular true for
|
||||
linear and boolean equations that are generally written using \minizinc\
|
||||
operators. For example the evaluation of the linear constraint \mzninline{x +
|
||||
2*y <= z} will result in the following \nanozinc:
|
||||
2*y <= z} will result in the following \nanozinc:
|
||||
|
||||
\begin{nzn}
|
||||
var int: x;
|
||||
@ -1045,7 +1045,7 @@ These \nanozinc\ definitions are correct, but, at least for \gls{mip} solvers,
|
||||
the existence of the intermediate variables is likely to have a negative impact
|
||||
on the \gls{solver}'s performance. These \glspl{solver} would likely perform
|
||||
better had they received the linear constraint \mzninline{int_lin_le([1,2,-1],
|
||||
[x,y,z], 0)} directly. Since many solvers support linear constraints, it is
|
||||
[x,y,z], 0)} directly. Since many solvers support linear constraints, it is
|
||||
often an additional burden to have intermediate values that have to be given a
|
||||
value in the solution.
|
||||
|
||||
|
||||
@ -40,10 +40,10 @@ the propagator, and hence make its propagation faster.
|
||||
|
||||
When full reification is applicable (where we are not using half reified
|
||||
predicates) an alternative to half reification is to implement full reification
|
||||
\mzninline{x <-> pred(...)} by two half reified propagators \mzinline{x ->
|
||||
\mzninline{x <-> pred(...)} by two half reified propagators \mzninline{x ->
|
||||
pred(...)}, \mzninline{y \half \neg pred(...)}, \mzninline{x <-> not y}. This
|
||||
does not lose propagation strength. For Booleans appearing in a positive context
|
||||
we can make the the propagator \mzninline{y -> not pred(...)} run at the lowest
|
||||
we can make the propagator \mzninline{y -> not pred(...)} run at the lowest
|
||||
priority, since it will never cause failure. Similarly in negative contexts we
|
||||
can make the propagator \mzninline{b -> pred(...)} run at the lowest priority.
|
||||
This means that Boolean variables are still fixed at the same time, but there is
|
||||
@ -56,23 +56,23 @@ less overhead.
|
||||
\label{sec:half-context}
|
||||
|
||||
\begin{tabular}{ccc}
|
||||
\(
|
||||
\begin{array}{lcl}
|
||||
\changepos \rootc & = &\posc \\
|
||||
\changepos \posc & =& \posc \\
|
||||
\changepos \negc & =& \negc \\
|
||||
\changepos \mixc & =& \mixc
|
||||
\end{array}
|
||||
\)
|
||||
&~&
|
||||
\(
|
||||
\begin{array}{lcl}
|
||||
\negop \rootc & = &\negc \\
|
||||
\negop \posc & = & \negc \\
|
||||
\negop \negc & = & \posc \\
|
||||
\negop \mixc & = & \mixc
|
||||
\end{array}
|
||||
\)
|
||||
\(
|
||||
\begin{array}{lcl}
|
||||
\changepos \rootc & = & \posc \\
|
||||
\changepos \posc & = & \posc \\
|
||||
\changepos \negc & = & \negc \\
|
||||
\changepos \mixc & = & \mixc
|
||||
\end{array}
|
||||
\)
|
||||
& ~ &
|
||||
\(
|
||||
\begin{array}{lcl}
|
||||
\changeneg \rootc & = & \negc \\
|
||||
\changeneg \posc & = & \negc \\
|
||||
\changeneg \negc & = & \posc \\
|
||||
\changeneg \mixc & = & \mixc
|
||||
\end{array}
|
||||
\)
|
||||
\end{tabular}
|
||||
|
||||
\begin{itemize}
|
||||
|
||||
@ -43,8 +43,8 @@ may be removed again.
|
||||
|
||||
The usage of these methods is not new to \gls{constraint-modelling}, and they
|
||||
have proven to be very useful \autocite{schrijvers-2013-combinators,
|
||||
rendl-2015-minisearch, schiendorfer-2018-minibrass, ek-2020-online,
|
||||
ingmar-2020-diverse}. In its most basic form, a simple scripting language is
|
||||
rendl-2015-minisearch, schiendorfer-2018-minibrass, ek-2020-online,
|
||||
ingmar-2020-diverse}. In its most basic form, a simple scripting language is
|
||||
sufficient to implement these methods, by repeatedly calling on the
|
||||
\gls{constraint-modelling} infrastructure to compile and solve the adjusted
|
||||
constraint models. While improvements of the compilation of constraint models,
|
||||
@ -566,9 +566,9 @@ The definition of these new functions follows the same pattern as for
|
||||
\mzninline{sol}, \mzninline{status}, and \mzninline{last_val}. The MiniZinc
|
||||
definition of the \mzninline{uniform_nbh} function is shown in
|
||||
\Cref{lst:6-int-rnd}. \footnote{Random number functions need to be marked as
|
||||
\mzninline{::impure} for the compiler not to apply \gls{cse}
|
||||
\autocite{stuckey-2013-functions} if they are called multiple times with the
|
||||
same arguments.} Note that the function accepts variable arguments \mzninline{l}
|
||||
\mzninline{::impure} for the compiler not to apply \gls{cse}
|
||||
\autocite{stuckey-2013-functions} if they are called multiple times with the
|
||||
same arguments.} Note that the function accepts variable arguments \mzninline{l}
|
||||
and \mzninline{u}, so that it can be used in combination with other functions,
|
||||
such as \mzninline{sol}.
|
||||
|
||||
@ -693,19 +693,19 @@ the call had on the \nanozinc\ program have to be undone, including results of
|
||||
propagation, \gls{cse} and other simplifications.
|
||||
|
||||
\begin{example}\label{ex:6-incremental}
|
||||
Consider the following \minizinc\ fragment:
|
||||
Consider the following \minizinc\ fragment:
|
||||
|
||||
\begin{mzn}
|
||||
\begin{mzn}
|
||||
constraint x < 10;
|
||||
constraint y < x;
|
||||
\end{mzn}
|
||||
|
||||
After evaluating the first constraint, the domain of \mzninline{x} is changed to
|
||||
be less than 10. Evaluating the second constraint causes the domain of
|
||||
\mzninline{y} to be less than 9. If we now, however, try to remove the first
|
||||
constraint, it is not just the direct inference on the domain of \mzninline{x}
|
||||
that has to be undone, but also any further effects of those changes --- in this
|
||||
case, the changes to the domain of \mzninline{y}.
|
||||
After evaluating the first constraint, the domain of \mzninline{x} is changed to
|
||||
be less than 10. Evaluating the second constraint causes the domain of
|
||||
\mzninline{y} to be less than 9. If we now, however, try to remove the first
|
||||
constraint, it is not just the direct inference on the domain of \mzninline{x}
|
||||
that has to be undone, but also any further effects of those changes --- in this
|
||||
case, the changes to the domain of \mzninline{y}.
|
||||
\end{example}
|
||||
|
||||
Due to this complex interaction between calls, we only support the removal of
|
||||
@ -955,8 +955,8 @@ development version of Chuffed; and \chuffedMzn{}, Chuffed performing \gls{lns}
|
||||
with \flatzinc\ neighbourhoods. These experiments illustrate that the \gls{lns}
|
||||
implementations indeed perform well compared to the standard
|
||||
solvers.\footnote{Our implementations are available at
|
||||
\texttt{\justify{}https://github.com/Dekker1/\{libminizinc,gecode,chuffed\}} on
|
||||
branches containing the keyword \texttt{on\_restart}.} All experiments were run
|
||||
\texttt{\justify{}https://github.com/Dekker1/\{libminizinc,gecode,chuffed\}} on
|
||||
branches containing the keyword \texttt{on\_restart}.} All experiments were run
|
||||
on a single core of an Intel Core i5 CPU @ 3.4 GHz with 4 cores and 16 GB RAM
|
||||
running macOS High Sierra. \gls{lns} benchmarks are repeated with 10 different
|
||||
random seeds and the average is shown. The overall timeout for each run is 120
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@ -94,7 +94,7 @@ following publication:
|
||||
\printbibliography[heading=none]
|
||||
\end{refsection}
|
||||
|
||||
\chapter{Acknoledgements}
|
||||
\chapter{Acknowledgements}
|
||||
|
||||
|
||||
\mainmatter{}
|
||||
|
||||
Reference in New Issue
Block a user