SweConsNet is the Network for Sweden-based researchers and practitioners of Constraint programming.]]>
Following the previous successful workshops, we would like to announce the 12th SweConsNet workshop, which will take place in Lund, Sweden on May 27th 2013. The purpose of this workshop is to learn about ongoing research in constraint programming, as well as existing projects and products. We will also discuss the further development of the network, such as a possible widening to other Nordic countries.
The workshop is open to everybody interested in the theory and practice of constraint programming, whether based in Sweden or elsewhere. The scope of the workshop spans all areas of Constraint Programming, and is open to presentations and discussions addressing topics related to both theory and application.
Please forward a link of this page to people who might be interested but are not yet on the SweConsNet mailing list. They can subscribe to it by sending a message to Justin.Pearson [at] it.uu.se.
We hope for your participation, and highly encourage you to submit a proposal for a presentation of your ongoing work, recent results, or of a relevant discussion topic. There are no paper submissions, reviews, or proceedings, hence recent conference/journal papers may also be presented.
To register for partcipation in the registration form no later than May 22. The workshop does not have a registration fee.
Program
Time Content 09.30 Registration and coffee 10.00 Jean-Noël Monette (Uppsala University)
Towards solver-independent propagatorsWe present an extension to indexicals to describe propagators for global constraints. The resulting language is compiled into actual propagators for different solvers, and is solver-independent. In addition, we show how this high-level description eases the proof of propagator properties, such as correctness and monotonicity. Experimental results show that propagators compiled from their indexical descriptions are sometimes not significantly slower than built-in propagators of Gecode. Therefore, our language can be used for the rapid prototyping of new global constraints
10.40 Mats Carlsson (SICS) (joint work with Nicolas Beldiceanu & Aranud Letort)
Scalable Scheduling ConstraintsThe topic of this talk is synchronized sweep-based filtering algorithms for resource and precedence constraints that are common in scheduling problems. We first describe a sweep-based implementation of the time-tabling method for "cumulative". Step by step, we then extend this algorithm to handle colored resources, multiple resources, and precedences. We also derive from the filtering algorithm a greedy assignment algorithm, which is useful for very large scale problems where normal tree search would run out of memory.
11.20 Mehmet A. Arslan (LTH)
Instruction Selection and Scheduling for DSP Kernels on Custom ArchitecturesAs custom architectures become more and more common for DSP applications, instruction selection and scheduling for such applications and architectures become important topics. In this paper, we explore the effects of defining the problem of finding an optimal instruction selection and scheduling as a constraint satisfaction problem (CSP). We incorporate methods based on sub-graph isomorphism and global constraints designed for scheduling. We experiment using several media applications on a custom architecture, a generic VLIW architecture and a RISC architecture, all three with several cores. Our results show that defining the problem with constraints gives flexibility in modeling, while state-of-the-art constraint solvers enable optimal solutions for large problems, hinting a new method for code generation.
12.00 LUNCH 13.00 Kim-Anh Tran (SICS)
Investigation of Implied Constraints in a Constraint-Based Compiler Back-end
Adding implied constraints addressing register allocation and instruction scheduling to the constraint model of a compiler back-end can be crucial to the performance of the code generator. In the hope of cutting down the search effort, implied constraints are investigated, implemented and evaluated. The talk will cover current findings of a master thesis on a set of implied constraints and give an insight into their actual impact on the code generation problem.13.40 Håkan Kjellerstrand
What I like about Constraint ProgrammingThis is a presentation about fascinating features in Constraint Programming: those I personally find very appealing and/or unique (e.g. compared to other programming paradigms/systems), especially regarding the modeling aspect.
14.20 Björn Regnell (LTH)
A Scala DSL for Constraint-based Requirement EngeineeringSoftware Requirements Engineering (RE) includes the challenging activities of release planning and prioritization, which both are suitable to be tackled by constraint solving. However, there is a need for integrating the representation of software requirements with the representation of constraints in a way that is easy to use by practitioners. This talk aims to interactively discuss what types of constraints are essential in this domain and present and invite feedback on a prototype tool that provides a Scala-internal DSL for Constraint-based RE, wrapping the JaCoP solver.
15.00 Coffee break 15.30 Krzysztof Kuchcinski (LTH)
Mapping Streaming Application into MPSoc16.10 Workshop closure
As mentioned earlier, I have a special interest in the CP Solvers: Modeling, Applications, Integration, and Standardization Workshop ]]>The following workshops will take place before the main conference on September 16.
WCB13: Constraint Based Methods for Bioinformatics
WCB'13 is the 9-th of a series of consecutive Workshop on Constraint Based Methods for Bioinformatics. The topics of interest are all those concerning bioinformatics and constraints and related techniques.
workshop homepageTRICS13: Techniques foR Implementing Constraint programming Systems
Constraint programming systems are software systems that support the modeling and solving of problems using constraint programming. Such systems include constraint programming libraries and runtime systems for constraint programming languages. This workshop, the fourth in the series, will focus on implementation issues of such systems.
workshop homepageCSP-SAT: 3rd International Workshop on the Cross-Fertilization between CSP and SAT
Constraint Satisfaction Problems (CSP’s) and Boolean Satisfiability Problems (SAT) have much in common. However, they also differ in many important aspects, which result in major differences in solution techniques. This workshop is designed as a venue for bridging the gap and for cross-fertilization between the two communities.
CP Solvers: Modeling, Applications, Integration, and Standardization
The objective of this workshop is to get an industrial overview of currently available CP solvers and their use in real-world applications. The focus of the workshop will be not on implementation but rather on modeling, applications, integration, and standardization. Such an overview will fill a gap in the program of recent CP conferences and will allow CP developers and researchers to share the most recent experience of the actual use of different CP-based tools.
workshop homepageWorkshop on Optimization for Smart Cities
Policy makers who run the complex network of diverse people, expected services and aging infrastructure are on a constant search for more efficient ways to analyse data, anticipate problems and coordinate resources in their cities. This workshop has the purpose of bringing together scholars and practitioners that work on the solution of problems related to the improvement of the quality of life and the use of resources in cities, to make cities smarter.
workshop homepageCOSpeL: Domain Specific Languages in Combinatorial Optimization
Domain Specific Languages (DSLs) are programming languages or libraries developed to handle specific tasks. The aim of COSpeL is to bring together people interested in the development and use of DSLs in the context of combinatorial optimization.
workshop homepageModRef: Constraint Modelling and Reformulation
This workshop covers modelling and reformulation techniques that make constraint programming more accessible and easier to use, widening the use of CP technology.
workshop homepage
If you an author of a CP solver, we ask you to fill out the following questionnaire (even if you do not plan to submit a presentation or attend the workshop). We plan to present a summary of all CP Solvers at this website before the start of the conference.And here is the link to the workshop page: Workshop "CP Solvers: Modeling, Applications, Integration, and Standardization".]]>
To be held at the 19th International Conference on the Principles and Practice of Constraint Programming (http://cp2013.a4cp.org/) in Uppsala, Sweden on Monday September 16, 2013.Please note that we invite authors of all CP solvers written using any languages to make brief presentations of their tools.
Objectives and Scope
The objective of this workshop is to get an industrial overview of currently available CP solvers and their use in real-world applications. The focus of the workshop will be not on implementation but rather on modeling, applications, integration, and standardization. Such an overview will fill a gap in the program of recent CP conferences and will allow CP developers and researchers to share the most recent experience of the actual use of different CP-based tools.We invite authors of all commercial and open source CP solvers to submit their presentations that should include (but not be limited to) the following topics:
If you an author of a CP solver, we ask you to fill out the following questionnaire (even if you do not plan to submit a presentation or attend the workshop). We plan to present a summary of all CP Solvers at this website before the start of the conference.
- Demonstration of modeling facilities using a commonly known problem from the CSPLib
- Implementation programming languages and why they were selected
- Covered variable types, global constraints, and search algorithms
- Integration with LP/MIP/SAT tools
- Integration with business rules, predictive analytics, and other decision making techniques
- Real-world use: positive and negative experience
- Standardization and future plans
We also welcome application developers and researchers who use different CP tools and who are willing to share their practical experience.
A special focus will be on CP standardization efforts including:
- Development of CP APIs for different programming environments
- CP XML for interchange of constraint satisfaction/optimization problems
- CP design patterns
- Libraries of commonly used constraints
- Collections of constraint satisfaction and optimization problems.
An expert panel discussion will be held at the end of this one-day workshop.
We hope that the workshop will help to improve communication between different CP vendors, between solver developers and their users, and will ultimately encourage a wider use of CP technology as a key component of the modern decision making applications.
Target Audience
- Developers and users of different CP solvers
- Business application developers who want to incorporate CP-based tools into their decision support systems
- CP researchers.
Schedule
[To be defined]Important Dates
- Sunday, June 16 Presentation title and abstract submission
- Tuesday, July 16 Acceptance notification
- Friday, August 16 Complete presentation submission
- Monday, September 16 Workshop
Organizing Committee
• Jacob Feldman, OpenRules, Monroe, NJ, USA jacobfeldman@openrules.com
• Helmut Simonis, 4C, Cork, Ireland h.simonis@4c.ucc.ie
• Hakan Kjellerstrand, Independent Researcher, Malmo, Sweden hakank@gmail.comSubmission
All abstracts and presentations must be submitted in PDF format using EasyChair. All accepted presentations will be made publicly available of the workshop’s website. At least one author of any accepted presentation must attend the event. An accepted presentation will be withdrawn if no such participation is secured with the payment of the workshop dues.
The 12th Workshop of the Network of Sweden-based researchers and practitioners of Constraint programmingI just registered my own talk: What I (still) like about Constraint Programming. with the Presentation abstract:
SweConsNet is the Network for Sweden-based researchers and practitioners of Constraint programming.
Following the previous successful workshops, we would like to announce the 12th SweConsNet workshop, which will take place in Lund, Sweden on May 27th 2013. The purpose of this workshop is to learn about ongoing research in constraint programming, as well as existing projects and products. We will also discuss the further development of the network, such as a possible widening to other Nordic countries.
The workshop is open to everybody interested in the theory and practice of constraint programming, whether based in Sweden or elsewhere. The scope of the workshop spans all areas of Constraint Programming, and is open to presentations and discussions addressing topics related to both theory and application.
Please forward a link of this page to people who might be interested but are not yet on the SweConsNet mailing list. They can subscribe to it by sending a message to Justin.Pearson [at] it.uu.se.
We hope for your participation, and highly encourage you to submit a proposal for a presentation of your ongoing work, recent results, or of a relevant discussion topic. There are no paper submissions, reviews, or proceedings, hence recent conference/journal papers may also be presented.
To register, please fill your data in the registration form. If you want to propose a presentation, please send also the title and the abstract of your talk. In order to facilitate organization, please notify us of your intention to participate as soon as possible, and at the latest before May 10th, 2013. The workshop does not have a registration fee.
In the program so far
Participants will be presented continously
1. Jean-Noël Monette (Uppsala University): Towards solver-independent propagators
2. Håkan Kjellerstrand: What I (still) like about Constraint Programming
3. Mats Carlsson (SICS), TBD.
4. Christian Schulte (KTH), TBD.
5. Björn Regnell (LTH),A Scala DSL for Constraint-based Requirement Engeineering
6. Mehmet A. Arslan (LTH), Instructions Selection and Scheduling for DSP Kernels on Custom Architectures.
This is a presentation about fascinating features in Constraint Programming: those I personally find very appealing and/or unique (e.g. compared to other programming paradigms/systems), especially regarding the modeling aspect.I guess that many/most of the attendants know these "fascinating features" already, but all might not agree (I hope) that they are as important (or fascinating) as I find them. ]]>
The aim of the MiniZinc Challenge is to start to compare various constraint solving technology on the same problems sets. The focus is on finite domain propagation solvers. An auxiliary aim is to build up a library of interesting problem models, which can be used to compare solvers and solving technologies.Here is the Call for Problem Submission:
Entrants to the challenge provide a FlatZinc solver and global constraint definitions specialized for their solver. Each solver is run on 100 MiniZinc model instances. We run the translator mzn2fzn on the MiniZinc model and instance using the provided global constraint definitions to create a FlatZinc file. The FlatZinc file is input to the provided solver. Points are awarded for solving problems, speed of solution, and goodness of solutions (for optimization problems).
Registration opens: Wed, 1 May 2013.
Problem submission deadline: Fri, 14 June 2013.
Initial submission round begins: Mon, 1 July 2013.
Initial submission round ends: Fri, 19 July 2013.
Final submissions: Fri, 2 August 2013.
Announcement of results at CP2013: 17 - 20 September 2013.
For details of the competition see:
http://www.minizinc.org/challenge2013/challenge.html
Note that the scoring system has slightly changed this year, so that solvers that obtain indistiguishable results in quality of solution split the points inversely proportional to the time taken
To register for the challenge please email
mzn-challenge@minizinc.org
The MiniZinc Challenge is an annual solver competition in the Constraint Programming (CP) community held before the International Conference on Principles and Practice of Constraint Programming. The MiniZinc Challenge 2013 is seeking interesting problem sets on which various constraint solving technologies should be compared on this year. Everyone is allowed to submit problems regardless of whether they are an entrant in the challenge.Also see: MiniZinc Challenge Medals 2008-2012
Important dates and deadlines:
Problem submission open: now
Problem submission deadline: Fri, 14 June 2013
Problem submission
Send an email with the subject line “[MZNC13] benchmark” to mzn-challenge 'at' minizinc.org
There are no restrictions on the kind of problems, but ideally they should be of interesting nature such as practice-related problems and puzzles etc. Problem submissions with real-world instances are welcome warmly. Models for the 2013 challenge can only use integer and Boolean variables.
The problem submitter provides a MiniZinc model of the problem and 20 instances ranging from easy-to-solve to hard-to-solve for an “ordinary” CP system. It is strongly encouraged to make use of the global constraint definitions provided in the MiniZinc 1.6 distribution. Please, follow the links below for submission instructions and requirements.
MiniZinc Challenge 2013
Changes in Version 4.0.0 (2013-03-14)Also see: ]]>This release adds a multitude of new features, fixes many bugs, and offers a number of performance improvements. There are too many major improvements to even summarize them here all, so here are just some highlights: LDSB as automatic symmetry breaking during search; restart-based search; complete redesign and reimplementation of branching enhancing the expressiveness massively (AFC with decay, activity, user-defined variable and value selection, tie-break control, better randomization, ...); half-reification; addition of floating point constraints.
It is recommended to read the new Chapter in MPG on branching as the changes are substantial and require you to change your programs, see also the full list of changes below.
As the interfaces has changed, please consult How to Change to Gecode 4.0.0.
- Kernel
- Additions
- The random seeds for variable and value branching options can now be initialized from a hardware random number generator (see MPG for details). (minor)
- All ArgArrays now accept STL vectors and input iterators for construction. (minor)
- The kernel now can record the activity of variables. The activity of a variable is defined as how often the domain of a variable has been pruned during search. For details, see "Modeling and Programming with Gecode". (major)
- Other changes
- The default constrain() function for best-solution search now does by default nothing (it used to throw an exception). (minor)
- The entire infrastructure for variable-value branchers has been reimplemented from scratch. The new design makes a much better compromise between code size, efficiency, and expressiveness: the efficiency is about the same (for examples with no propagation and just branching one can note a slowdown of 2-4%) while code size shrinks drastically (the overall code size for integer variables shrinks by 20%) and the architecture is much more expressive (in particular, it supports tie-break limits, see MPG). (major)
- Throw exception when the user-defined copy constructor of a class that inherits from Space does not call the Space copy constructor. (minor)
- Performance improvements
- Fixed a bug in the main memory allocation routine: now heap block sizes are decreased dynamically as they should be. Also changed the memory configuration parameters as explained in: Zandra Norman, Memory Management for Gecode. KTH Royal Institute of Technology, Sweden, Bachelor thesis, TRITA-ICT-EX-2012:143, 2012. (major, thanks to Zandra Norman)
- Search engines
- Additions
- Added support for restart-based search, see MPG for details. (major)
- Other changes
- Variable selection for branching used the quotient of size divided by degree, accumulated failure count, or activity. They now use the inverse. That is, for example, it is not any longer INT_VAR_SIZE_DEGREE_MIN() but INT_VAR_DEGREE_SIZE_MAX() (that is, largest degree divided by size). (major) That looks like an annoying change but is in fact essential: the strategies using accumulated failure count and activity now could have run into division by zero issues. And just changing the implementation is not good enough because the values of these measures can now be exposed during tie-breaking.
- The restart best solution search engine has been removed (it is subsumed by the new restart-based meta search engine RBS). (major)
- Performance improvements
- The search engines now do not allocate memory on the search stack for the rightmost branch of each node. This means that the search tree depth is now computed differently. It now represents the actual peak depth required at any one time, taking into account that rightmost branches reuse the stack entry of their parents. (minor)
- Finite domain integers
- Additions
- Gecode now supports Lightweight Dynamic Symmetry Breaking (LDSB), see MPG for details. (major , contributed by Christopher Mears)
- Added value selection strategies for branching INT_VAL_NEAR_MIN(), INT_VAL_NEAR_MAX(), INT_VAL_NEAR_INC(), and INT_VAL_NEAR_DEC(). They can take a previous assignment to the variables to branch on and try to choose values which are near (see MPG for details). (major, thanks to Manuel Loth)
- Added domain constraint that constrains a variable (or an array) according to the domain of another variable. (minor)
- Added variants of dom that copy the domain from one variable to another. (minor)
- The nooverlap constraint now allows sharing of unassigned variables in its argument arrays. (minor)
- Added half-reification for reified constraints (see Modeling and Programming with Gecode for details). (major)
- Added pow and nroot constraints. (major)
- The binpacking constraint now also accepts items of size zero. (minor, thanks to Kathrin Dannmann, Roberto Castañeda Lozano)
- Added activity-based branching strategies for integer and Boolean variables: INT_VAR_ACTIVITY_MIN, INT_VAR_ACTIVITY_MAX, INT_VAR_ACTIVITY_SIZE__MIN, INT_VAR_ACTIVITY_SIZE_MAX. For details, see "Modeling and Programming with Gecode". (major)
- Other changes
- The coefficients for linear constraints are now divided by their greatest common divisor. That means that some equations can be handled now that previously threw an OutOfLimits exception, and some equations can be handled with the more efficient integer precision propagators that previously required double precision. (minor)
- Generalized definition of no-overlap propagators for better reuse. (minor, thanks to Roberto Castañeda Lozano)
- The interface for branching on integer and Boolean variables has changed considerably (supporting user-defined variable and value selection, tie-break limit functions, handlers to created branchers, and more). In order to change, you have to add () to all variants of INT_VAR, INT_VAL, and INT_ASSIGN. For example, INT_VAR_SIZE_MIN becomes the function call INT_VAR_SIZE_MIN() and INT_VAL_MIN_MIN becomes the function call INT_VAL_MIN_MIN(). Some of these functions expect additional arguments and can take also optional arguments (this replaces the VarBranchOptions and ValBranchOptions). Please read the new "Branching" chapter in MPG. (major)
- Respect IntConLevel argument for reified linear constraints with a single integer variable. (minor)
- Bug fixes
- Fixed precede constraint with less than two values. (minor, thanks to Roberto Castañeda Lozano)
- Fixed a bug where bounds consistent distinct reported subsumption instead of failure in certain cases. (major, thanks to Lin Yong)
- Fixed potential rounding issues in sqr and sqrt constraints. (minor)
- Fixed copying of tuple sets in extensional constraints and IntSets in sequence constraints (could lead to crashes when using parallel search). (major, thanks to Manuel Baclet)
- Added missing propagation for nary min/max constraint. (minor, thanks to Jean-Noël Monette)
- Make extensional constraints work with empty tuple sets. (minor, thanks to Peter Nightingale)
- Fix count (global cardinality constraint) for multiple occurrences of the same value in the cover array. (minor, thanks to Peter Nightingale)
- Performance improvements
- Arithmetic, linear, and cumulative constraints now resort to internal operations using "long long int" rather than "double". This improves performance but also extends the range over integer coefficients that can be handled by linear constraints. (major)
- Finite integer sets
- Additions
- Gecode now supports Lightweight Dynamic Symmetry Breaking (LDSB), see MPG for details. (major , contributed by Christopher Mears)
- Added domain constraint that constrains a variable (or an array) according to the domain of another variable. (minor)
- Added domain constraints for arrays of set variables. (minor)
- Added half-reification for reified constraints (see Modeling and Programming with Gecode for details). (major)
- Added activity-based branching strategies for set variables: SET_VAR_ACTIVITY_MIN, SET_VAR_ACTIVITY_MAX, SET_VAR_ACTIVITY_SIZE_MIN, SET_VAR_ACTIVITY_SIZE_MAX. For details, see "Modeling and Programming with Gecode". (major)
- Added channeling constraint between arrays of set variables. (major , contributed by Denys Duchier)
- Other changes
- The interface for branching on integer and Boolean variables has changed considerably (supporting user-defined variable and value selection, tie-break limit functions, handlers to created branchers, and more). In order to change, you have to add () to all variants of SET_VAR, SET_VAL, and SET_ASSIGN. For example, SET_VAR_SIZE_MIN becomes the function call SET_VAR_SIZE_MIN() and SET_VAL_MIN_INC becomes the function call SET_VAL_MIN_INC(). Some of these functions expect additional arguments and can take also optional arguments (this replaces the VarBranchOptions and ValBranchOptions). Please read the new "Branching" chapter in MPG. (major)
- Bug fixes
- Fixed precede constraint with less than two values. (minor, thanks to Roberto Castañeda Lozano)
- Floats
- Additions
- Added support for float variables. (major , contributed by Vincent Barichard)
- Minimal modeling support
- Additions
- Added pow and nroot expressions for integer variables. (minor)
- Other changes
- Made implementations of MiniModel expressions private, so that the MiniModel headers do not have to include propagator headers like gecode/int/linear.hh any longer. (minor)
- Script commandline driver
- Additions
- Added commandline options to control restart-based search, see MPG for details. (major)
- Decay values can now be passed on the command line using the switch -decay. (minor)
- Added options -file-sol and -file-stat for writing solutions and statistics to arbitrary files and streams. (minor, thanks to Andrea Pretto)
- The command line -print-last configures whether only the last solution found is printed. (minor, thanks to Josef Eisl)
- Other changes
- Boolean options (BoolOption) can now be given a false or true argument and hence are in-line with all other option types. (minor)
- Range and value iterators
- Documentation fixes
- Clarified for several iterators that when using the assignment operator both iterators must be allocated from the very same region. (minor)
- Support algorithms and datastructures
- Bug fixes
- Fixed a concurrency problem that caused an exception to be thrown at the end of a multi-threaded search on some platforms. (minor)
- Fixed a bug in the allocation of very large bitsets. (minor, thanks to Max Ostrowski)
- Example scripts
- Additions
- New example: Colored matrix without monochromatic rectangles. (minor)
- Gist
- Additions
- Added option to invoke move cursors during the automatic search. (minor)
- Other changes
- Updated to compile with Qt version 5.0 (still works with Qt >= 4.3 as well). (minor)
- Gecode/FlatZinc
- Additions
- Added support for more search annotations (defined in gecode.mzn), and for the restart and decay command line options. (minor)
- Added native support for lex_less_bool and lex_lesseq_bool. (minor)
- Gecode/FlatZinc now supports float constraints and variables. (major)
- The FlatZinc interpreter now supports comparing of nodes in Gist. (major, thanks to Gabriel Hjort Blindell)
- Added native support for the inverse_set constraint. (minor)
- Other changes
- Renamed the FlatZinc executable to fzn-gecode, to better distinguish it when installed alongside other FlatZinc implementations. (minor)
- The FlatZinc interpreter no longer performs a complete search on variables annotated as var_is_introduced, but tries to extend a solution on the model variables to a solution that includes the introduced variables. Each solution on the model variables is therefore only reported once. (major)
- Bug fixes
- The mzn-gecode shell script now passes arguments correctly to the FlatZinc interpreter. (minor)
- Removed spurious debug output for among constraint. (minor, thanks to Simon Ekvy)
- Exported registry and helper functions so that users can add constraint handlers to the FlatZinc interpreter. (minor, thanks to Jean-Noël Monette)
- General
- Additions
- Added CMake build script for Gecode (CMakeLists.txt). (minor, thanks to Victor Zverovich)
- Variable selection using AFC now supports decay. Read more in MPG. (major)
- Other changes
- Compiles with MSVC 2012. (minor)
table) which
make dynamic programming easier (see some examples here). It also has an almost seamless support for changing between CLP(FD), LP/MIP, and SAT solver.
sendmore(Digits) :-
Digits = [S,E,N,D,M,O,R,Y],
Digits :: 0..9,
alldifferent(Digits),
S #> 0, M #> 0,
1000*S + 100*E + 10*N + D
+ 1000*M + 100*O + 10*R + E
#= 10000*M + 1000*O + 100*N + 10*E + Y,
labeling(Digits).
This is no different from most CLP(FD) systems. Note that there is no need to
load a specific clpfd module since everything is loaded already (and B-Prolog
currently don't support modules).
Digits :: 0..9: This means that all the elements in the
list Digits must be in the domain between 0..9.
#, e.g. #= and #>.
labeling(Digits): starts the search of the solution.
queens2(N, Q) :-
length(Q, N),
Q :: 1..N,
Q2 @= [Q[I]+I : I in 1..N],
Q3 @= [Q[I]-I : I in 1..N],
alldifferent(Q),
alldifferent(Q2),
alldifferent(Q3),
labeling([ff],Q).
The extraction the two diagonals is done via list comprehensions (Q2 and Q3), i.e.
Q2 @= [Q[I]+I : I in 1..N], alldifferent(Q2),This works since the special operator
V @= [....] extracts the elements
Q[I] (note the use of array index here).
queens2 in the file).
queens/2 is the same as the above but use alldistinct instead
of alldifferent:
alldifferent is faster than using alldistinct. The latter use
a stronger consistency checking, but that don't help in this encoding:
For N=400:
queens2/2: 0.62s 10 backtracks
queens5/2: 0.71s 10 backtracks
queens/2: 2.16s 1 backtrack
For N=499:
queens2/2: 0.76 1 backtracks
queens5/2: 1.1s 1 backtracks
queens/2: 4.168 0 backtracks
For N=500: too slow
For N=501:
queens5/2: 1.1s 1 backtracks
queens2/2: 3.14s 1 backtrack
queens/2: 3.524s 2 backtracks
For N=1000:
queens5/2: 8.9s 2 backtracks
queens2/2: 24.2s 2 backtracks
queens/2: 34.146s 0 backtracks
[I don't understand why N=500 is so hard when 499 and 501 is solved quite fast.
No other CP solver/system I've tested show this behaviour.]
go :-
L = [[_S,E,N,_D],[M,O,_R,E],[M,O,N,E,_Y]],
alphametic(L, Base, Res),
writeln(Res).
alphametic(L,Base, Vars) :-
reverse(L,Rev),
Rev = [Last|Sums],
term_variables(L, Vars),
Vars :: 0..Base-1,
alldifferent(Vars),
Vals #= sum([Val : S in Sums,[Val],calc(S,Base,Val)]),
calc(Last,Base,Vals),
foreach(S in Sums,S[1]#>0),
labeling([ff,split], Vars).
calc(X,Base,Y) :-
length(X,Len),
Y #= sum([X[I]*Base**(Len-I) : I in 1..Len]).
The main work here is done with term_variables/2 which extracts
the variables used, the sum/1 which sums all the terms, and
calc that is really a special case of scalar product.
go :-
time(solve(1)).
solve(ProblemName) :-
problem(ProblemName, Board),
print_board(Board),
sudoku(3, Board),
print_board(Board).
print_board(Board) :-
N @= Board^length,
foreach(I in 1..N,
(foreach(J in 1..N, [X],
(X @= Board[I,J],
(var(X) -> write(' _')
;
format(' ~q', [X]))
)),
nl)),
nl.
problem(1, [](
[](_, _, 2, _, _, 5, _, 7, 9),
[](1, _, 5, _, _, 3, _, _, _),
[](_, _, _, _, _, _, 6, _, _),
[](_, 1, _, 4, _, _, 9, _, _),
[](_, 9, _, _, _, _, _, 8, _),
[](_, _, 4, _, _, 9, _, 1, _),
[](_, _, 9, _, _, _, _, _, _),
[](_, _, _, 1, _, _, 3, _, 6),
[](6, 8, _, 3, _, _, 4, _, _))).
alldifferent_matrix(Board) :-
Rows @= Board^rows,
foreach(Row in Rows, alldifferent(Row)),
Columns @= Board^columns,
foreach(Column in Columns, alldifferent(Column)).
sudoku(N, Board) :-
N2 is N*N,
array_to_list(Board,BoardVar),
BoardVar :: 1..N2,
alldifferent_matrix(Board),
foreach(I in 1..N..N2, J in 1..N..N2,
[SubSquare],
(SubSquare @= [Board[I+K,J+L] :
K in 0..N-1, L in 0..N-1],
alldifferent(SubSquare))
),
labeling([ff,down], BoardVar).
One of the most interesting things here is the code for
the sub squares (SubSquare):
(SubSquare @= [Board[I+K,J+L] :
K in 0..N-1, L in 0..N-1]
I+K and J+L.
However this works only when the indices (I, J, K, L)
are ground integers. If any of the indices would be decision
variables, then one have to use element/3
(or perhaps nth1/3) to obtain the same thing.
See below for more about this.
_ _ 2 _ _ 5 _ 7 9 1 _ 5 _ _ 3 _ _ _ _ _ _ _ _ _ 6 _ _ _ 1 _ 4 _ _ 9 _ _ _ 9 _ _ _ _ _ 8 _ _ _ 4 _ _ 9 _ 1 _ _ _ 9 _ _ _ _ _ _ _ _ _ 1 _ _ 3 _ 6 6 8 _ 3 _ _ 4 _ _ 3 6 2 8 4 5 1 7 9 1 7 5 9 6 3 2 4 8 9 4 8 2 1 7 6 3 5 7 1 3 4 5 8 9 6 2 2 9 6 7 3 1 5 8 4 8 5 4 6 2 9 7 1 3 4 3 9 5 7 6 8 2 1 5 2 7 1 8 4 3 9 6 6 8 1 3 9 2 4 5 7Time and backtracks: Since there is no built-in predicate in B-Prolog for getting both time and number of backtracks (failures etc), let's add this:
time2(Goal):-
cputime(Start),
statistics(backtracks, Backtracks1),
call(Goal),
statistics(backtracks, Backtracks2),
cputime(End),
T is (End-Start)/1000,
Backtracks is Backtracks2 - Backtracks1,
format('CPU time ~w seconds. Backtracks: ~d\n', [T, Backtracks]).
Running this on the command line:
$ time bp -g "[sudoku], time2(solve(1)),halt"writes the following after the solution, i.e. that it's a 0 backtrack problem.
CPU time 0.0 seconds. Backtracks: 0In the model sudoku.pl there is a predicate
go3/0 which runs all the 13 problem
instances and shows the statistics (time and backtracks). The len:1
in the output is for ensuring that the solution
is unique (a requirement on traditional Sudoku problems).
This check caught two problem instances that was either typed in erroneously
by me or by the source I got them from (and thus I removed these two
problems from this model).
go3 :-
foreach(P in 1..13,
[L,Len],
(writeln(problem:P),
time2(findall(P,solve2(P),L)),
length(L,Len),
writeln(len:Len),
(Len > 1 ->
writeln('This has more than one solution!')
;
true
), nl)).
The result is:
problem:1 CPU time 0.004 seconds. Backtracks: 0 len:1 .... problem:13 CPU time 0.04 seconds. Backtracks: 0 len:1
@= it works to get a list comprehension (provided that
there's no problem with array access etc). If one want to use it directly in
a (global) constraint, then the requirement is that it
must be in an arithmetic context (I first missed that in the documentation).
sum/1 is a special function in an arithmetic
context:
Sum #= sum([X[I] : I in 1..N])However, using comprehensions in global constraints such as
alldifferent don't work since it's not in an arithmetic context:
% this don't work alldifferent([X[I]+I : I in 1..N])The following works (as we saw above in the N-Queens model) since we extract the elements to a list using
@= before using it.
% this works Q1 @= [X[I]+I : I in 1..N], alldifferent(Q1), % ...As mentioned above, array indexing don't work when the indices are decision variables. Then one must use
element/3
(or nth/3). See more about element below.
ac(Var, StartValue) (or ac1/2 which I have not
used much), which collects the local variables in the loop to a global variable
(here Var).
ac is in
photo_problem.pl
preferences(1, 7, [[1,5],
[1,6],
[2,1],
[2,5],
[4,6],
[4,3],
[7,4],
[7,3]]).
foreach([Pref1,Pref2] in Preferences,
ac(Diffs,[]), [P1,P2,Diff],
(
element(Pref1,Positions,P1),
element(Pref2,Positions,P2),
Diff #= (abs(P1-P2) #= 1),
Diffs^1 = [Diff|Diffs^0]
)),
Here the Diff list collects the differences of the positions
(from the local Diff variable). The local declarations
[P1,P2,Diff] is needed here, otherwise they would be considered
global variables in the model (with disastrous result).
Preferences,
so the foreach is not limited to integer ranges that is shown in a couple
of the other examples here.
new_array(Var,Dimensions):
N = 3, new_array(X,[N,N]),where
Dimensions is a list of the dimensions (of "any" size; I don't
know if there is any limitations of the number of dimensions).
new_array is an array structure such as
| ?- new_array(X,[3,3]) X = []([](_7a8,_7b0,_7b8),[](_7c8,_7d0,_7d8),[](_7e8,_7f0,_7f8))Converting an array structure to a list is done with
array_to_list(Array,List):
| ?- new_array(X,[3,3]), array_to_list(X,List) X = []([](_8e0,_8e8,_8f0),[](_900,_908,_910),[](_920,_928,_930)) List = [_8e0,_8e8,_8f0,_900,_908,_910,_920,_928,_930]Setting the domains for the variables in an array must be done via the converted list (i.e. not directly on the array structure):
N = 3, new_array(X, [N,N]), array_to_list(X, Vars), Vars :: 1..N*N, % ...After that conversion, one can freely use constraints on either the array structure (e.g. as a matrix) or on the list representation, such as
alldifferent(Vars). This
"dual representation" sometimes simplifies modeling much. Note that labeling must be
done via the list representation, or by using term_variables/2.
#= (equality), #=> (implication) and
#<=> (equivalence). Here is an decomposition of the global constraint
alldifferent_except_0.pl:
alldifferent_except_0(Xs) :-
Len @= Xs^length,
foreach(I in 1..Len, J in 1..Len,
(I #\=J #/\ Xs[I] #\= 0 #/\ Xs[J] #\= 0)
#=>
(Xs[I] #\= Xs[J])
).
One thing I noticed when playing with reifications was that foreach don't seems
be in boolean context. Example: this don't work as I expected (or hoped), i.e.
that if not all X[I] are larger than 0 then B is 0 (and vice versa):
% don't work foreach(I in 1..N, X[I] #> 0) #<=> (B #= 1)
table constraint is used in hidato_table.pl and is quite easy to use.
Connections
@= [(I1,J1,I2,J2) :
I1 in 1..N, J1 in 1..N,
I2 in 1..N, J2 in 1..N,
(abs(I1-I2) =< 1,
abs(J1-J2) =< 1,
(I1 \=I2; J1 \= J2)
)],
Then place all the numbers 1..N*N in the grid where the places are restriced by the
connections in Connections. Note that since we are using
decision variables for the indices (I1,J1,I2,J2) of the grid
(X), we cannot use array extraction. My solution of this is
to use the XVar list (which we must have for the labeling anyway),
and calculate the corresponding position in this list for each (I,J)
postition in the grid.
XVar @= [X[I,J] : I in 1..N, J in 1..N],
XVar :: 1..N*N,
% ....
% place all integers from 1..N*N
alldifferent(XVar),
foreach(K in 1..(N*N)-1,
[I1,J1,I2,J2,K2,Offset1,Offset2],
[ac(AllConn,[]),ac(Offsets,[])],
(
K2 is K+1,
[I1,J1,I2,J2] :: 1..N,
% [(I1,J1,I2,J2)] in Connections,
[Offset1,Offset2] :: 1..N*N,
Offset1 #= (I1-1)*N+J1,
element(Offset1,XVar,K),
Offset2 #= (I2-1)*N+J2,
element(Offset2,XVar,K2),
AllConn^1 = [(I1,J1,I2,J2)|AllConn^0],
Offsets^1 = [[Offset1,Offset2]|Offsets^0]
)
),
% the table constraint
AllConn in Connections,
...
The table constraint is used by simply putting all the variables in
a list of parenthesis structure (I1,J1,I2,J2) and then checking
all these using AllConn in Connections.
AllConn (the collection of selected connections)
as well as the offsets (collected in the Offsets list) is included in
the labeling to get faster results.
% ... term_variables([Offsets,XVar,AllConn],Vars), labeling([ff],Vars), % ...In my experiments with this model, it seems to be faster to put
Offsets before XVar and AllConn
in the labeling.
table constraint (the model
hidato.pl).
For example, problem instance #6 takes 6.5 seconds without the table constraint,
and 0.17 seconds with (both versions have 0 backtracks).
table.
Please don't confuse these two usages of "table".
element constraint. (Porting
to B-Prolog has not been the worst case in this matter, though.)
element is
encoded very natural). It's especially when using element in a matrix
where I had to stop in my "porting flow" (often the port was quite "flowy") and then use
element/nth1 constraints and often a few temporary variables.
matrix_element(X, I, J, Val) :- element(I, X, Row), element(J, Row, Val). matrix(_, []) :- !. matrix(L, [Dim|Dims]) :- length(L, Dim), foreach(X in L, matrix(X, Dims)).(The latter predicate was suggested by Mats Carlsson when I implemented a lot of SICStus Prolog models some years ago.)
husband and wife are lists of decision variables). Here's
a snippet from the MiniZinc model stable_marriage.mzn:
forall(m in 1..num_men) ( husband[wife[m]] = m )In B-Prolog, I use the following (using the same overall approach):
foreach(M in 1..NumMen,[WifeM,HusbandWifeM],
(element(M,Wife,WifeM),
element(WifeM,Husband,HusbandWifeM),
HusbandWifeM #= M )),
Another example is the Five element problem (from Charles W. Trigg):
five_elements.pl
Charles W. Trigg, PI MU EPSILON JOURNAL, Valume 6, Fall 1977, Number 5
"""
From the following square array of the first 25 positive integers,
choose five, no two of the same row or column, so that the maximum of
the five elements is as small as possible.
2 13 16 11 23
15 1 9 7 10
14 12 21 24 8
3 25 22 18 4
20 19 6 5 17
foreach(I in 1..N,
(sum([X[I,J] : J in 1..N]) #= 1,
sum([X[J,I] : J in 1..N]) #= 1
))
However, we also want to find the specific numbers in the matrix
for which X[I,J] #= 1. The following way do not work:
% This don't work
foreach(J in 1..N, [I],ac(Is,[]),
(I :: 1..N,
1 #= X[I,J],
Y[J] #= Matrix[I,J]
))
If we - still - want to use this matrix approach, then
freeze/2 can be used. However, we then have to
collect the I indices in an accumulator list
Is to be used in the labeling:
% Find the specific row I for which X[I,J] is 1.
foreach(J in 1..N, [I],ac(Is,[]),
(I :: 1..N,
freeze(I, 1 #= X[I,J]),
freeze(I, Y[J] #= Matrix[I,J]),
Is^1 = [I|Is^0])
),
MaxY #= max(Y),
term_variables([XVar,Y,MaxY,Is], Vars),
minof(labeling([ff], Vars),MaxY),
labeling(Vars),
% ....
Using freeze/2 is not ideal, but it makes the
code more intuitive than with a lot of element/3
or nth1/3, if that even work.
cp_solve.
$= instead of #=
(i.e. "$" instead of "#") to mark that it's a CLP constraint.
cp_solve, lp_solve,
ip_solve, and sat_solve.
$alldifferent and $element, and the usual arithmetic
sum/1, min/1, max/1, min/2, max/2. The CLP(FD) solver has support for
many more global constraints.
coins(N, C) :-
% N = 10, % 31 the grid size
% C = 6, % 14, number of coins per row/column
new_array(X, [N,N]),
array_to_list(X, Vars),
Vars :: 0..1,
Sum $>= 0,
foreach(I in 1..N,
(C $= sum([T : J in 1..N, [T], T @= X[I,J]]), % rows
C $= sum([T : J in 1..N, [T], T @= X[J,I]]) % columns
)),
% quadratic horizontal distance
Sum $= sum([
T : I in 1..N, J in 1..N, [T],
T @= (X[I,J] * abs(I-J)*abs(I-J))
]),
ip_solve([min(Sum),ff,reverse_split], Vars),
% cp_solve([min(Sum),ff,reverse_split], Vars),
% sat_solve([min(Sum),ff,reverse_split], Vars),
writeln(sum:Sum),
pretty_print(X).
By changing ip_solve to cp_solve (or sat_solve)
we use the CP solver (or SAT solver). This is quite nifty.
Picat is a general-purpose hybrid language that incorporates many declarative language features for better productivity of software development, including explicit non-determinism, explicit unification, functions, constraints, and tabling. Picat also provides imperative language constructs for programming everyday things. The Picat system will be used for not only symbolic computations, such as knowledge engineering, NLP, and search problems, but also for scripting tasks for the Web, games, and mobile applications.This sounds very interesting, and I will definitely give it a try when it's released (and perhaps blog about it as well).
....
The Picat implementation will be based on the B-Prolog engine and the first version that has the basic functionality is expected to be released by May, 2013. The project is open to anybody and you are welcome to join, as a developer, a sponsor, a user, or a reviewer. Please contact picat@picat-lang.org .
all_differ_from_at_least_k_pos
all_equal
all_min_dist
alldifferent_cst
alldifferent_except_0
alldifferent_modulo
alldifferent_on_intersection
among
among_seq
bin_packing
circuit
clique
cumulative
distribute
cumulative)
global_contiguity
global_cardinality
nvalue
nvalues
sequence
sliding_sum
lp_solve)
table
The 12th Workshop of the Network of Sweden-based researchers and practitioners of Constraint programmingHere's the first and preliminary program (the site will be updated continuously):
SweConsNet is the Network for Sweden-based researchers and practitioners of Constraint programming.
Following the previous successful workshops, we would like to announce the 12th SweConsNet workshop, which will take place in Lund, Sweden on May 27th 2013. The purpose of this workshop is to learn about ongoing research in constraint programming, as well as existing projects and products. We will also discuss the further development of the network, such as a possible widening to other Nordic countries.
The workshop is open to everybody interested in the theory and practice of constraint programming, whether based in Sweden or elsewhere. The scope of the workshop spans all areas of Constraint Programming, and is open to presentations and discussions addressing topics related to both theory and application.
...
We hope for your participation, and highly encourage you to submit a proposal for a presentation of your ongoing work, recent results, or of a relevant discussion topic. There are no paper submissions, reviews, or proceedings, hence recent conference/journal papers may also be presented.
The CP 2013 Workshop Chair invites proposals for the Workshops immediately preceding the main conference in Uppsala.
The CP workshops offer an informal venue where participants are given the opportunity to present discuss and brainstorm on new ideas, technical topics, exciting new application areas and cross-fertilization with other domains. The forums are meant as a petri dish for new ideas and emerging topics in the field of constraint programming. The topics can overspread many areas ranging from modeling, tools, techniques, algorithms, methodology, discrete and continuous optimization as well as complete and incomplete methods. Relevant areas showcasing or contributing to CP such as cloud computing, cryptography, energy, sustainability, databases, machine learning or data mining — to name just a few — are all equally encouraged.
All workshops will take place on September 16, 2013 at the site of the main conference. Workshops can follow a half-day or a full-day format. The details of the organization of each workshop are left to its organizers
The CP 2013 Tutorial Chair invites proposals for tutorials in Uppsala.
Tutorials are expected to give an in-depth presentation of emerging and exciting topics that are relevant to a broad swath of the constraint programming community. Past CP conferences featured tutorials on numeral CSPs, global constraints, languages, Disaster Management, Decision Diagrams and connection with mathematical programming. Topics currently at the fore-front of research activities with successes, major advances and significant impact are particularly welcome.
The tutorials will take place during the main technical program.
AIMMS offers an all-round development environment for the creation of high-performance decision support and advanced planning applications to optimize strategic operations. It allows organizations to rapidly improve the quality, service, profitability, and responsiveness of their operations. The AIMMS development environment possesses a unique combination of advanced features and design tools, such as the graphical model explorer, which allow you to build and maintain complex decision support applications and advanced planning systems in a fraction of the time required by conventional programming tools.One distinct feature of AIMMS is the integrated GUI where one both define the parameters, variable and constraints as well as the graphical input/output of the model. I should note that this is the first time in my CP experience that I've worked with this kind of tight integrated tool, which might explain some of the comments below.
Variable, Element Variable) used in CP modeling.
x with the index domain i (defined as a subset of Integers with the values {1,2,3,4,5,6,7,8}. Then all the parameters
(constants) S,E,N,D,M,O,R,Y are defined to be able to be index in x, e.g.
such as 1000*x(S)+ 100*x(E)+ 10*x(N)+x(D) (defining SEND) etc.
i is defined via the set ii (the name of the set is not so important except for documentation purposes). When defining the array (x) the size is defined by the range of the index. So we define the array x(i) (identifier: x, index domain: (i)) and makes it a Variable with the range of {0..9} (i.e. the domain of the values in x).
x(S) > 0 and x(M) > 0
(1000*x(S) + 100*x(E)+ 10*x(N) + x(D) +
1000*x(M) + 100*x(O)+ 10*x(R) + x(E)) =
(10000*x(M) + 1000*x(O) + 100*x(N) + 10*x(E) + x(Y))
View, Text Representation, All.
DECLARATION SECTION
SET:
identifier : ii
subset of : Integers
index : i
definition : {1,2,3,4,5,6,7,8} ;
CONSTRAINT:
identifier : SendMoreMoney
definition : (1000*x(S) + 100*x(E)+ 10*x(N) + x(D) +
1000*x(M) + 100*x(O)+ 10*x(R) + x(E)) =
(10000*x(M) + 1000*x(O) + 100*x(N) + 10*x(E) + x(Y)) ;
MATHEMATICAL PROGRAM:
identifier : SendMoreMoney2Plan
direction : minimize
constraints : AllConstraints
variables : AllVariables
type : CSP ;
CONSTRAINT:
identifier : SM
definition : x(S) > 0 and x(M) > 0 ;
VARIABLE:
identifier : x
index domain : (i)
range : {0..9} ;
PARAMETER:
identifier : S
definition : 1 ;
PARAMETER:
identifier : E
definition : 2 ;
PARAMETER:
identifier : N
definition : 3 ;
PARAMETER:
identifier : D
definition : 4 ;
PARAMETER:
identifier : M
definition : 5 ;
PARAMETER:
identifier : O
definition : 6 ;
PARAMETER:
identifier : R
definition : 7 ;
PARAMETER:
identifier : Y
definition : 8 ;
CONSTRAINT:
identifier : AllDiff
definition : cp::AllDifferent(i, x(i)) ;
ENDSECTION ;
PROCEDURE
identifier : MainInitialization
ENDPROCEDURE ;
PROCEDURE
identifier : MainExecution
body :
ShowProgressWindow;
solve SendMoreMoney2Plan;
ENDPROCEDURE ;
ENDMODEL Main_SendMoreMoney2 ;
The call cp::AllDifferent(i, x(i)) works like this: The first parameter i is the
"loop index" which is used to loop through the second argument x(i), i.e. it states that all
the elements in x should be distinct. This is how for-loops are done in AIMMS and is a very
common idiom.
ShowProgressWindow: the Progress window shows how the model progress as well as
the time, number of failures, etc.
solve SendMoreMoney2Plan which actuall start the solving process. This must be defined for all models.
SendMoreMoney2Plan is of type mathematical program (select this type of identifier via type options labeled "..."). For Constraint Satisfaction models like this, select Type: CSP, and let Direction be whatever (minimize or maximize). For optimization models, the type should be COP (Constraint OPtimization), and state the objective variable, and the direction. (Note: The objective variable must be Free for some reason.)
Main Execution (not
shown in the listing above since it belongs to the GUI.)
CONSTRAINT: identifier : C1 index domain : (i,j) definition : (i < j) and x(i) <> x(j) ; CONSTRAINT: identifier : C2 index domain : (i,j) definition : (i < j) and x(i) + i <> x(j) + j ; CONSTRAINT: identifier : C3 index domain : (i,j) definition : (i < j) and x(i) - i <> x(j) - j ; CONSTRAINT: identifier : AllDiff definition : cp::AllDifferent(i, x(i)) ;The more modern - and faster - version is shown in NQueens2.aim which use three
alldifferent constraints:
CONSTRAINT: identifier : alldiff1 definition : cp::AllDifferent(i, x(i)) ; CONSTRAINT: identifier : alldiff2 definition : cp::AllDifferent(i, x(i)-i) ; CONSTRAINT: identifier : alldiff3 definition : cp::AllDifferent(i, x(i)+i) ;To see the number of solutions of a model, just add this line last in MainExecution:
DialogMessage(GMP::Solution::Count('ProjectPlan'));
together with a large enough value of Solution storage limit in Setting, Project Settings, Specific Solvers, CPoptimizer 12.4, General.
Country Colors ------------------ Belgium 2 Denmark 1 France 4 Germany 3 Netherlands 1 Luxembourg 1which is perfectly fine. Without any symmetry breaking there are 144 solutions.
Index domain: c1 | c1 = "Belgium"
Colors(c1) = 1
The solution is now:
Country Colors ------------------ Belgium 1 Denmark 1 France 4 Germany 3 Netherlands 2 Luxembourg 2which is also a correct solution.
Colors is defined as:
data {red, blue, green, yellow}
It was also very easy to do the direct representation of the
connections between the countries. AIMMS converts automatically to a boolean
connection matrix (a nice feature):
DATA { (Belgium, [France, Germany, Netherlands, Luxembourg]),
(Denmark, [Germany]),
(France, [Belgium, Germany, Netherlands, Luxembourg]),
(Germany, [Belgium, Denmark, France, Netherlands, Luxembourg]),
(Netherlands, [Belgium, France, Germany]),
(Luxembourg, [Belgium, Germany]) }
However, it was a little bit harder to define the "DifferentColor" constraint using the
color names, but after changing CountryColors to a ElementVariable
and Range: Colors it worked as expected.
SET:
identifier : Countries
indices : c1, c2
definition : data {Belgium, Denmark, France, Germany, Netherlands, Luxembourg} ;
SET:
identifier : Colors
index : c
initial data : data {red, blue, green, yellow} ;
ELEMENT VARIABLE:
identifier : CountryColor
index domain : (c1)
range : Colors ;
CONSTRAINT:
identifier : DifferentColors
index domain : (c1,c2)
definition : if (c1 <> c2 and Connections(c1, c2) = 1) then
CountryColor(c1) <> CountryColor(c2)
endif ;
And the solution:
Solution:
Belgium blue
Denmark red
France yellow
Germany gree
Netherlands red
Luxembourg red
A specification is a square matrix of characters. Alphanumeric
characters represent the number of mines adjacent to that field.
Dots represent fields with an unknown number of mines adjacent to
it (or an actual mine).
E.g.
..2.3.
2.....
..24.3
1.34..
.....3
.3.3..
The main constraint states that the number in "this" cell (if > 0)
is the sum of the number of mines surrounding this cell.
The indices i and j are defined as sets 1..#rows
and 1..#cols, respectively. The four ifs in the Sum
constraint restricts the value of i+a and j+b to be
inside the matrix.
CONSTRAINT:
identifier : C1
index domain : (i,j)
definition :
if (Problem(i,j) > 0) then
Sum[(a,b), x(i+a, j+b) |
(i+a > 0) and
(j+b > 0) and
(i+a <= R) and
(j+b <= C)] =
Problem(i,j)
endif;
However, this constraint is not enough since it don't rule out
that a hint cell can contain a mine (or if a cell contains a hint, it
cannot contain a mine). So we must add either of these two constraints
CONSTRAINT:
identifier : C2
index domain : (i,j)
definition :
if (Problem(i,j) >= 0) then
x(i,j) = 0
endif
comment :
"If a cell contains a hint (>= 0) then there can be no mine.
Either C2 or C3 must be active." ;
CONSTRAINT:
identifier : C3
index domain : (i,j)
definition :
if (x(i,j) = 1) then
Problem(i,j) = -1
endif
comment :
"If this cell contains a mine, then there can be no hint
(i.e. >= 0). Either C2 or C3 must be active." ;
I tend to prefer constraint C2.
1 0 0 0 0 1 0 1 0 1 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 1 1 1 0 0 1 0 0 0 1 1(A more artistic modeler than me would show the result in a nicer way.)
CONSTRAINT:
identifier : FillData
index domain : (i,j)
definition : if (Problem(i,j) > 0) then
x(i,j) = Problem(i,j)
endif ;
Note that this can also be written without the if clause, which more show the
advantage of AIMMS modeling principle:
index domain: (i,j) | Problem(i,j) > 0 definition: x(i,j) = Problem(i,j)The Latin Square requirements are very easy to state, using two
alldifferent constraints:
index: i cp::alldifferent(i, x(i,j))and
index: j cp::alldifferent(i, x(i,j))However the block constraint is a little more tricky (as in all CP systems). In AIMMS one has (as I understand it) to define a special parameter,
Blocks to be used in the constraint:
PARAMETER: identifier : Blocks index domain : (i,j) definition : 1+N*Div(i-1,N)+Div(j-1,n) ; CONSTRAINT: identifier : C3 index domain : k definition : cp::AllDifferent( (i,j) | Blocks(i,j) = k, x(i,j) ) ;The unique solution to the problem instance is
7 9 5 1 4 6 8 2 3 6 4 3 8 2 5 7 9 1 2 1 8 3 9 7 4 6 5 5 2 7 9 6 1 3 8 4 8 6 4 7 5 3 2 1 9 1 3 9 2 8 4 6 5 7 4 5 1 6 7 2 9 3 8 9 7 6 5 3 8 1 4 2 3 8 2 4 1 9 5 7 6To ensure that this is a unique solution, simply counts the number of solutions: any value larger than 1 means that the model is wrong in some way. Here's to do it:
Solution storage limit in Setting, Project Settings, Specific Solvers, CPoptimizer 12.4, General to 2 (the default is 1).
MainExecution: DialogMessage(GMP::Solution::Count('Sudoku2Plan') + " solutions");
CAllDifferentExcept0 which states that all values in x
that are not 0 (zero) must be distinct (hence the name of the global constraint AllDifferentExcept0).
if (i < j and x(i) <> 0 and x(j) <> 0) then
x(i) <> x(j)
endif;
I also added an increasing constraint, CIncreasing:
if (ord(i) > 1) then
x(i-1) <= x(i)
endif;
Though it might be more clear to write it as:
index domain : i | ord(i) > 1
definition : x(i-1) <= x(i)
Hates and Richer are valid so I conclude that this model is correct (or rather: as correct as my
other versions of this problem).
Someone in Dreadsbury Mansion killed Aunt Agatha. Agatha, the butler, and Charles live in Dreadsbury Mansion, and are the only ones to live there. A killer always hates, and is no richer than his victim. Charles hates noone that Agatha hates. Agatha hates everybody except the butler. The butler hates everyone not richer than Aunt Agatha. The butler hates everyone whom Agatha hates. Noone hates everyone. Who killed Agatha?This was not as hard as I first thought it should be, though I had to experiment a little with
Element Variables to get it to work.
Hates and Richer are set to
Element Variables to be able to handle Element constraints such as
Hates(TheKiller, TheVictim) = 1 Richer(TheKiller, TheVictim) = 0Note that
TheKiller is a decision variable.
if-then else whether
or not decision variables or parameters are involved in the if clause.
This makes creating constraints much easier.
Hates) are are defined via the set (ij), defining the indices and their domains (i and j).
PARAMETER:
identifier : N
definition : 3 ;
SET:
identifier : ij
subset of : Integers
indices : i, j
definition : {1..N} ;
VARIABLE:
identifier : Hates
index domain : (i,j)
range : binary ;
CONSTRAINT:
identifier : KillerHatesAVictim
definition : hates(TheKiller, TheVictim) = 1 ;
CONSTRAINT:
identifier : ButlerHaveEveryoneWhomAgataHates
index domain : i
definition : if (Hates(Agatha, i) = 1) then
Hates(Butler, i) = 1
endif ;
(Sometimes I don't like to have to name all constraints in the model, but right now when
writing about them it's is quite useful.)
modulo constraint, which is quite essential for some recreational mathematics problems. AIMMS has support for this (otherwise I would have tried to implement it).
N <= 10
(the AIMMS model just show one of the alternative solutions):
2: [1] 4: [1, 2, 3] [3, 2, 1] 6: [1, 4, 3, 2, 5] [5, 4, 3, 2, 1] 8: [3, 2, 5, 4, 1, 6, 7] [5, 2, 3, 4, 7, 6, 1] [5, 6, 7, 4, 3, 2, 1] 10: [3, 8, 1, 6, 5, 4, 7, 2, 9]
MainExecution procedure
which saves the variables for the first solution to a file:
write AllVariables to file "DivisibleBy9Through1.wrt";
ParallelSchedule constraint is used, which is much
like the traditional cumulative constraint:
cp::ParallelSchedule(
upperLimit,
jobDomain,
jobStart,
jobDuration,
jobEnd,
jobHeight
)
Here are the specific values used in the model:
UpperLimit: 4 (resources, i.e. persons)
UpperLimit2: 120 (minutes)
jobDomain: j (index for domain Jobs: {1..UpperLimit2})
jobStart: Start (minutes, variable)
jobDuration: Duration (minutes, may involve variables)
jobEnd: End (minutes, variable)
jobHeight: Resources (persons, may involve variables)
The only trouble I had here was how to define jobDomain, but
after reading the definition a couple of times it's quite clear that
UpperLimit, and jobHeight should have the same unit (i.e.
resources), while the other are time (in minutes); that is, for this specific model.
jobEnd(i) = jobStart(i) + jobDuration(i)(In many other CP systems one have to ensure this explicitly.)
MaxEndTime is to be minimized, stated
in the mathematical program (here called FurnitureMovingPlan).
cumulative (e.g. some of MiniZinc's solvers)
I've seen that the total number of required resources can be a
decision variable as well (and thus can be an objective variable), but this variant
is not supported in AIMMS.
Langford's number problem (CSP lib problem 24)In this model I had some problems understanding how AIMMS' indices works, which emphasize that they don't work exactly as the "array based" indices that I'm used to from other CP systems.
Arrange 2 sets of positive integers 1..k to a sequence, such that, following the first occurence of an integer i, each subsequent occurrence of i, appears i+1 indices later than the last.
For example, for k=4, a solution would be 41312432
pos1 and pos3 shown below, it's important
to restrict the index j so it don't go "over the edge" of the position
array, which is interpreted by AIMMS as an error in the model, i.e. it throws an
UNSAT when this happens. [Or perhaps it's the solver CPLEX CP Optimizer that does
this interpretation.] Using the traditional "array based" for-loops this would have
been easier, at least for me using a traditional for-loop. So beware of this gotcha.
(Note: When writing this now much later, this behaviour actually makes much more sense
than when I did the model.)
CONSTRAINT: identifier : pos1 index domain : j |j <= k definition : position(j) + j+1 = position(j+k) comment : "Note the index domain." ; CONSTRAINT: identifier : pos2 index domain : (i) definition : solution(position(i)) = i ; CONSTRAINT: identifier : pos3 index domain : j |j <= k definition : solution(position(k+j)) = j comment : "Note the index domain." ;A similar case is in the AllInterval where one of the constraints is to restrict the index
i to not be the last
value of the Set i1 set (defined as the range 1..N), so it
restricts i in the DiffsK constraint to not be N.
SET:
identifier : i1
subset of : Integers
index : i
definition : {1..N} ;
...
CONSTRAINT:
identifier : DiffsK
index domain : i | i <> last( i1 )
definition : diffs(i) = Abs(x(i)-x(i+1))
comment : "Note the special handling of the index domain for this constraint." ;
These kind of behaviour (different to what I'm used to) have caused some long debugging
sessions.
UseSymmetry1 ... UseSymmetry4.
Search Type::Restart instead of Automatic. Using this option solves the problem for N=4 in about 3 seconds (with 168662 failures) compared to 20 seconds (663751 failures) when using Search Type: Automatic.
(i,j) | i > 1 and j > 1 and i < N and j < N
water(i,j) = Max(x(i,j), Min(water(i-1,j), water(i,j-1),
water(i+1,j), water(i,j+1)))
1..N, 1..N*N, and 1..N*N*N, it must be
done with two extra help parameters (N2, N*N, and N3, N*N*N) since
the Range Wizard for the variable cannot calculate formulas for the upper bound.
z) must be declared as a Free Range variable (-inf .. inf) and not using the Range domain (1..N3). Intuitively this seems to be a too large domain for the solver to handle, but perhaps the solver is intelligent in calculating the bounds.
Settings, Project Options... select Specific solvers, CPoptimizer 12.4, General and change Solution storage limit to a higher value, e.g. 1000.
DialogMessage("It was " + GMP::Solution::Count('ProjectPlan') + " solution(s).");
Parameter definition and keep it there.
Data, Load Case,
as active
Settings, Project, Startup & authorization,
Startup case.
Settings, Project Option,
Specific solvers, CPoptimizer 12.4, Search
View, Text Representational, All when in the Model Explorer.
ii to a subset of integers.
We describe a system which generates finite domain constraint models from positive example solutions, for highly structured problems. The system is based on the global constraint catalog, providing the library of constraints that can be used in modeling, and the Constraint Seeker tool, which finds a ranked list of matching constraints given one or more sample call patterns.A companion technical report presents the details of the 230 tested examples: A Model Seeker Description and Detailed Results (over 1400 pages).
We have tested the modeler with 230 examples, ranging from 4 to 6,500 variables, using between 1 and 7,000 samples. These examples come from a variety of domains, including puzzles, sports-scheduling, packing & placement, and design theory. When comparing against manually specified “canonical” models for the examples, we achieve a hit rate of 50%, processing the complete benchmark set in less than one hour on a laptop. Surprisingly, in many cases the system finds usable candidate lists even when working with a single, positive example.
CP'13, the 19th International Conference on the Principles and Practice of Constraint Programming, will be held at Uppsala University on 16 - 20 September 2013.More details will come.
| chuffed-fd | 1136 |
| g12_cpx-fd | 1060 |
| gecode-fd | 881 |
| g12_lazyfd-fd | 783 |
| jacop-fd | 548 |
| g12_fd-fd | 525 |
| or_tools-fd | 488 |
| choco-fd | 430 |
| bprolog-fd | 265 |
| chuffed-free | 2359 |
| g12_cpx-free | 1915 |
| g12_lazyfd-free | 1782 |
| gecode-free | 1620 |
| fzn2smt-free | 1522 |
| gurobi-free | 1481 |
| izplus-free | 1413 |
| cplex-free | 1367 |
| jacop-free | 1326 |
| bprolog-free | 1203 |
| mistral-free | 1199 |
| g12_fd-free | 998 |
| choco-free | 805 |
| or_tools-free | 692 |
| minisatid-free | 648 |
| cbc-free | 222 |
| chuffed-free | 2341 |
| g12_cpx-free | 1897 |
| gecode-par | 1846 |
| g12_lazyfd-free | 1758 |
| fzn2smt-free | 1504 |
| gurobi-par | 1499 |
| izplus-free | 1380 |
| cplex-par | 1351 |
| jacop-free | 1293 |
| bprolog-free | 1178 |
| mistral-free | 1173 |
| g12_fd-free | 974 |
| or_tools-par | 810 |
| choco-free | 789 |
| minisatid-free | 627 |
| cbc-free | 222 |