58 lines
4.6 KiB
TeX
58 lines
4.6 KiB
TeX
%************************************************
|
|
\chapter{Conclusions}\label{ch:conclusions}
|
|
%************************************************
|
|
|
|
\noindent{}High-level \cmls{} make it easy to express decision problems.
|
|
They allow the modeller to reason at the level close to the problem, while the tooling of the language is able to create specifications for a range of potential \solvers{}.
|
|
Although the importance of creating specifications that can be solved efficiently is well-known, changes in the usage of these languages are raising questions about the time required to perform this transformation.
|
|
First, \constraint{} models are solved using low-level \solvers{}, such as \gls{mip} and \gls{sat}.
|
|
Because of the level at which these technologies reason, specifications are more sizable and the process to reach them is more complex.
|
|
Second, we have seen a development of the use of meta-search heuristics.
|
|
These heuristics incrementally adjust the \constraint{} model, after which it has to be rewritten to be solved.
|
|
Both these methods put additional pressure on the rewriting process, which can often be a bottle-neck in the overall process.
|
|
|
|
In the previous chapters of this thesis, we have explored in detail and presented improvements to the process of rewriting high-level \constraint{} models into \solver{} specifications.
|
|
These improvements focus both on the performance of the rewriting process in general, and for incremental adjustments of \constraint{} models in particular.
|
|
Crucially, the proposed improvements in the performance of the rewriting process themselves do not impact the quality of the \solver{} specification constructed.
|
|
This chapter presents the conclusions of this thesis.
|
|
We present a summary of the research and its contributions and discuss the future work arising from them.
|
|
|
|
\paragraph{Architecture}
|
|
|
|
\paragraph{Half Reification}
|
|
|
|
\paragraph{Incremental}
|
|
|
|
\paragraph{Summary}
|
|
|
|
\par\noindent\rule{\textwidth}{0.4pt}
|
|
|
|
This section should probably have the following components:
|
|
|
|
\begin{itemize}
|
|
\item Quick restatement of problem/importance/motivation
|
|
\item Contributions, preferably discussed per section. Relate them back to the research objectives.
|
|
\item Limitation and Future work. This can also focus on what my work makes possible, not just what to explore next.
|
|
\item Concluding remarks. Maybe a summary of the findings.
|
|
\end{itemize}
|
|
|
|
\par\noindent\rule{\textwidth}{0.4pt}
|
|
|
|
The work conducted during my candidature presents significant improvements in the infrastructure surrounding the use of high-level constraint modelling languages.
|
|
The implementation of my work can significantly reduce the overhead of the use of these languages.
|
|
This will both improve the current usage of these languages and will allow the uses of these languages to continue to grow.
|
|
|
|
Although the results for the investigated areas of research are very positive, the experiments were all conducted as a comparison to the current status quo.
|
|
To provide a more complete analysis of the work conducted, additional comparisons need to be added to compare between the different prototypes created during my candidature (e.g., comparing the different meta-search approaches) and to compare with other constraint modelling systems.
|
|
Even the comparison with low-level constraint modelling languages might be beneficial as a upper bound on the performance that could be achieved.
|
|
|
|
In the area of the compilation of constraint modelling languages, there is much room for future work that will not be part of my candidature.
|
|
The prototype tool chain that we have developed for \minizinc\ is incomplete and leaves out some parts of the complete \minizinc\ language.
|
|
In particular, float and set types are only partially supported.
|
|
In addition to the implementation of all currently accepted \minizinc\ types, there is room for a more formal exploration of the type systems employed in constraint modelling languages.
|
|
An interesting phenomenon that occurs is that certain types, that are not supported by the underlying solver technology, will be replaced by a collection of values of another type.
|
|
Similarly, our architecture describes where various kinds of simplifications and optimisations can be applied, but we do not fully explore the almost endless list of possible compilation optimisation, partial evaluation, and redefinition approaches that could potentially be applied.
|
|
Finally, the improvements in the meta-search capabilities of high-level constraint modelling languages should allow for more applications of meta-search from these languages.
|
|
These capabilities could likely improve existing systems based on these languages.
|
|
|