" /> My Constraint Programming Blog: August 2009 Archives

« July 2009 | Main | September 2009 »

August 30, 2009

Off topic: The Pop-11 programming language and Poplog environment

This is off topic, but it might interest you anyway.

Some weeks ago I started to more systematically learn the programming language Pop-11 and its environment Poplog. Pop-11 is a great but rather unknown programming language started in the '70s and was used (and is still used) for example in Artificial Intelligence research and education. Poplog also includes implementations of Common Lisp. Prolog and ML.

Today I wrote about Pop-11 and Poplog in The Pop-11 programming language and Poplog environment (at my other blog hakank.blogg, normally a Swedish spoken blog but this entry is in English).

I have also collected some of my Pop-11 programs at My Pop-11/Poplog page.

August 23, 2009

Java Specification Requests JSR 331: Constraint Programming API

The Java Specification Request JSR 331: Constraint Programming API is a request for consolidating the Java constraint solvers.
This specification defines a Java runtime API for constraint programming. The CP API prescribes a set of fundamental operations used to define and solve constraint satisfaction and optimization problems.

The request

2.1 Please describe the proposed Specification:

This specification defines a Java runtime API for constraint programming. The standardized CP API aims to make CP technology more accessible for business software developers. It intends to create CP Standards that will define unified business interface(s) for modeling and solving real-world decision support problems as Constraint Satisfaction and Optimization Problems. Having unified interfaces will allow commercial application developers to model their problems in such a way that the same model can be tried with different CP Solvers. This will minimize vendor dependence without limiting vendor's innovation. At the same time the CP API will help to bring the latest research results to real-world business applications. The CP API prescribes a set of fundamental operations used to define and solve constraint satisfaction and optimization problems. The sets of operations will allow a user to express its decision support problem in terms of:
- Decision Variables defined as constrained integer, real, and set variables
- Constraints defined on these variables using the standardized unary, binary and global constraints.
Clearly separating the problem definition from problem resolution, the sets of operations will allow a user to apply standardized search strategies to find feasible and optimal solutions of the problem. The CP API will also allow a user to create custom constraints and search strategies in a unified way making them independent from a particular CP solver.

...

2.6 Why isn't this need met by existing specifications?

Today CP is a proven optimization technique and many CP solvers empower real-world business applications in such areas as scheduling, planning, configuration, resource allocation, and real-time decision support. However, the absence of standards still limits the acceptance of CP by the business world.

While dissimilar vendor-specific CP API specifications exist, their syntactic and semantic differences are significant enough to cause costly difficulties for application builders and platform vendors.

The development schedule

2.13 Please describe the anticipated schedule for the development of this specification.

1. Early Draft Review: November 20, 2009

2. Complete the Specification, Public Draft/Final Release: April 15, 2010

3. Maintenance Review: June 30, 2010

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

The JSR Specification Lead has already contacted major CP vendors and well-known CP experts and involved them in a preliminary discussion at www.cpstandards.org. We will invite them to join the Expert Group right after the initial JSR Review and acceptance. We plan to have an kick-off meeting during the oncoming major CP conference CP-2009 that will take place at Portugal on 20-24 September 2009. A preliminary Java CP API that will become a basis for the JSR is being discussed by CP experts at the Discussion Forum at www.cpstandards.org. During the first 3 months we plan to finalize the Expert Group that will include the most active contributors to the Early Draft.

Related

Other pages of interest:
* JSR #331 Constraint Programming API - JSR Review Ballot * Public forum for JSR 331.
* Standardization of Constraint Programming (www.cpstandards.org), forum with some discussion about the JSR

Also, see:
* My Choco page
* My JaCoP page
* My constraint programming page

August 16, 2009

JaCoP: a request from the developers (Knapsack and Geost) and Nonogram labeling

Here are some JaCoP related news.

A request from the developers: Knapsack and Geost

This is a request from the JaCoP developers, from the article Geost and Knapsack constraint:
Dear all, We have tested intiial but already optimized implementations of Geost constraint as well as Knapsack constraint. We need testers who will use and test the constraint in their problems. Feel free to contact me by email ( radoslaw [dot] szymanek {at} gmail (dot) com) to get source code for any of those two constraints. Geost constraint has been shown to be even 1000 times faster for problems of size 1000+ objects than other open-source implementation available. Knapsack constraint is also very efficient as it uses the sublinear algorithm presented in the literature. We have extended Knapsack constraint to be able to handle 0..n quantity variables as well knapsack capacity and profit specified as finite domain variables and not just integers. Geost constraint is a result of Master thesis done by Marc-Olivier Fleury. Knapsack constraint is based on the student project completed by Wadeck Follonier. best regards, Radoslaw Szymanek

Nonogram

In the latest version of JaCoP (2.3.2, from May 2009) there are 151 test instances for the Nonogram model. One of these is the well known (infamous) problem P200, which I have written about before, for example in Comet: Nonogram improved: solving problem P200 from 1:30 minutes to about 1 second, where I - aided by Pascal Van Hentenryck - happened to find a labeling that was quite good for the P200 problem (and not very bad for the other instances).

The labeling used in the JaCoP distribution of Nonogram.java is (according to the source) the "Zigzag based variable ordering". I thought it would be fun to compare it with the labeling used in the Comet model (also later used in the Gecode model).

The "new" labeling

The "new" labeling described in Comet: Nonogram improved: solving problem P200 from 1:30 minutes to about 1 second is simply to order the variables according to the length of the row rules and column rules:
if (board.length*row_rules.length <  board[0].length*col_rules.length) {
    // i first
    for (int i = 0; i < row_rules.length; i++) {
	for (int j = 0; j < col_rules.length; j++) {
            vars.add(board[i][j]);
	}
    }
} else {
    // j first
    for (int j = 0; j < col_rules.length; j++) {
        for (int i = 0; i < row_rules.length; i++) {
            vars.add(board[i][j]);
	}
    }
}
Here are the statistics of running the P200 problem with the two different labelings. P200 is the first (and hard coded) problem presented in Nonogram.java.

Original labeling:
Nodes : 6472
Decisions : 3236
Wrong Decisions : 3236
Backtracks : 3236
Max Depth : 38

...

Execution time = 3135 ms
The "New" labeling:
Nodes : 1040
Decisions : 520
Wrong Decisions : 520
Backtracks : 520
Max Depth : 22

...

Execution time = 638 ms
So, for P200 this new labeling was an improvement: nearly 5 times better time and about 6 times fewer backtracks.

Running all instances

But how good is the new labeling overall? As noted above, there are 150 test instances (plus P200). I ran all of them and compared the individual results with the two labelings. Note that the instance 83 is the "alien waving problem" instance which has a lot of solutions; I changed the code so it just finds one solution. For the rest of the instances the solving time is for finding all solutions (which happens to be unique).

All the times below are the reported time from the Nonogram model, excluding time for printing the model and the solution. It should also be noted that the time is from one single run.

Total solving time
Running all the 150 + 1 problem instances, the total solving time was:
Total original: 6102
Total new     : 5462
Total diff    : 640
The total of differences means that the newer labeling has better (total) solving time, about 0.5 second.

Individual instances
For a complete listing of the test instances see nonogram_all.txt. Here we will concentrate on a few cases.

Below is the times of the instances where the differences between the two labelings where larger than 10ms, what I call "dominating" instances:
38: orig:34 new:21 diff:13
51: orig:11 new:35 diff:-24
67: orig:35 new:10 diff:25
84: orig:1222 new:963 diff:259
91: orig:872 new:2800 diff:-1928
p200: orig:3006 new:700 diff:2306
As we can see, there are three problem that dominates the total times: 84, 91, and P200. Note that for one of these (instance #91) the new labeling is actually worse.

Here are all differences grouped depending on which labeling was the best. Last (in parenthesis) is the number of instances in each group:
original_best diffs: 
3 1 1 1 10 2 3 2 2 1 1 3 3 2 2 2 1 1 24 1 3 4 2 2 2 1 1 9 2 1 1928 1 1 1 2 1 1 1 2 3 1 2 1 2 1 1 2 1 3 (49)
new_best diffs     : 
1 3 1 2 1 3 4 3 3 4 1 3 1 1 2 1 13 1 1 2 2 1 3 1 1 25 2 1 3 259 1 3 3 1 2 2 3 3 3 1 1 3 1 1 1 3 1 2306  (48)
same               : 
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 (55)

Summary

To summarise: the "new" labeling is overall quite good, but not better than the original labeling in all cases. It was better for two of the three dominating problem instances, and worse on one. Well, as always, there is no silver bullet.

The dominating instances

I don't know the name of the two dominating instances #84 and #91 so here they are, together with the infamous P200, using the output from JaCoP's Nonogram model.
Problem P200
 00   00     000
0000  0 0    0 0000
 0000 0 00   0     0
0000  0 0 0  0  0  0
 00   0 0 00  000  00000
      0   0 0   0  00  0
     000  0 00000  0  00
   000 00  00    0 00  00
  00 0  0000   0 0 0    0
 00      00 0 00 0     00
 0  0     0 000 00   000
 0  0 00  0000000  000
 0 00     00 0 00000
 000  00 00  0  00
  000   00   0   00
    00000    0    00
  00   00    0     00
 0000   00   0    00
000000   00  000 00
0000000   0000 000  00
 0000000    0000   0000
0000000      0      0000
000000       0     0000
 0000       00      00
  00         0
Problem 84
                 0
     0           00
     00         000
     000       00 0
     0 00     000 0
     00 00   000 00
      00 00 0000 00  00
      000 00000  00   00
       00 00000 000 0 0
       000 0000 0000 00
 0000000000 00 0000 00
  0  0000000 0 000 000
   00 0000000 000 000
    00 000000 00 0000
     00 0000 00 000000000
00000000 000 0 00000  0
  0000000 00  0000  00
   0000000   00   000
    0000000 00 00000
     000000   0000
       000 00000000
         000000000000
      0      000000
       0
        0
Problem 91
      0      0           
      00    00           
      00000000           
     00  00  00          
    00        00         
    00  0  0  00         
    00        00         
   00000    00000        
   00 00000000 00        
   0000 0000 0000        
   000000 0000000        
    0 0000 000 0         
    0000 00 0000         
     0 000000 0          
     00 00 0 00          
      00000000           
00    00000000           
 000    0000             
   000000000000          
     000000000000        
    000       00000000000
   000           00000000
  000                0000
000                    00
00                       

See also

See also My JaCoP page for some JaCoP models and links.

August 11, 2009

Strimko - Latin squares puzzle with "streams"

Via the post A New Twist on Latin Squares from the interesting math blog 360, I learned the other day about a new grid puzzle Strimko, based on Latin squares (which for example Sudoku also is).

The rules of Strimko are quite simple:
Rule #1: Each row must contain different numbers.
Rule #2: Each column must contain different numbers.
Rule #3: Each stream must contain different numbers.
The stream is a third dimension of the puzzle: an connected "stream" of numbers which also must be distinct.

Here is an example of a Strimko puzzle (weekly #068, same as in the 360 post):
Strimko puzzle
(the link goes to a playable version).

MiniZinc model

This problem was simple to solve in MiniZinc: strimko.mzn, and the data file strimko_068.dzn.

Here are the constraints of the model: three calls to all_different, one for each rows, cols (these two are the latin square requirement), and also for each stream. The places is for handling the "hints" (the given numbers) in the puzzle.
constraint 
  % latin square
  forall(i in 1..n) (
      all_different([ x[i, j] | j in 1..n]) /\
      all_different([ x[j, i] | j in 1..n])
  )
  /\ % streams
  forall(i in 1..n) (
     all_different([x[streams[i,2*j+1],streams[i,2*j+2]] | j in 0..n-1])
  )
  /\ % placed
  forall(i in 1..num_placed) (
      x[placed[i,1], placed[i,2]] = placed[i,3]
  )
;
The data file strimko_068.dzn is shown below:. Note the representation of the puzzle: Each cell is represented with two numbers, row,column.
% Strimko Set 068
n = 4;
streams = array2d(1..n, 1..n*2, [
                    1,1, 2,2, 3,3, 4,4,
                    2,1, 1,2, 1,3, 2,4,
                    3,1, 4,2, 4,3, 3,4,
                    4,1, 3,2, 2,3, 1,4
                   ]);
num_placed = 3;
placed = array2d(1..num_placed, 1..3, [
                             2,2,3,
                             2,3,2,
                             3,3,1
                           ]);
Solution:
  4 2 3 1
  1 3 2 4
  2 4 1 3
  3 1 4 2

A better version

But it was quite boring and error prone to code the problem instance in that representation. There is - of course - a simpler way by represent the streams themselves, i.e. give each stream a unique "stream number", and all cells with the same numbers must be distinct. Data file: strimko2_068.dzn
% Strimko Weekly Set 068
streams = array2d(1..n, 1..n, [
                    1,2,2,4,
                    2,1,4,2,
                    3,4,1,3,
                    4,3,3,1
                  ]);
% ...
The model also needed a simple change to reflect this representation: strimko2.mzn:
  % ...
  /\ 
  % streams
  forall(s in 1..n) (
     all_different([x[i,j] | i,j in 1..n where streams[i,j] = s])
  )
  % ....
The main advantage of the second model is that it makes it easier to state the problem instances. Also it is somewhat smaller to represent the grid: n x n*2 versus n x n. However, I haven't noticed any difference between the performance of these two models, but the problems are all very small so it may not be visible.

The problem instances

Here are all the implemented models and the problem instances: For more information about Strimko, and some problems, see: For more about MiniZinc and some of my models, see My MiniZinc page.

August 02, 2009

MiniZinc: Some new implemented global constraints (decompositions)

For some reason I have implemented some more (decompositions of) global constraints from the great Global constraint catalog; all models use the stated example from that site.

I have tried as much as possible - and mostly succeeded - to make the predicates fully multi-directional, i.e. so that each and every parameter of a predicate can either be fix or free (decision variable).

See my other implementations of global constraint in MiniZinc here. Right now there are now about 150 of them, about of half of the 313 listed in the Global constraint catalog. Some other new MiniZinc models:

MiniZinc: the lazy clause generation solver

In the following two papers (for CP2009), a new Zinc/MiniZinc solver using both finite domain and SAT is discussed: the lazy clause generation solver:

  • T. Feydy and P.J. Stuckey: Lazy clause generation reengineered:
    Abstract Lazy clause generation is a powerful hybrid approach to com-
    binatorial optimization that combines features from SAT solving and fi-
    nite domain (FD) propagation. In lazy clause generation finite domain
    propagators are considered as clause generators that create a SAT de-
    scription of their behaviour for a SAT solver. The ability of the SAT
    solver to explain and record failure and perform conflict directed back-
    jumping are then applicable to FD problems. The original implemen-
    tation of lazy clause generation was constructed as a cut down finite
    domain propagation engine inside a SAT solver. In this paper we show
    how to engineer a lazy clause generation solver by embedding a SAT
    solver inside an FD solver. The resulting solver is flexible, efficient and
    easy to use. We give experiments illustrating the effect of different design
    choices in engineering the solver.

  • A. Schutt, T. Feydy, P.J. Stuckey, and M. Wallace: Why cumulative decomposition is not as bad as it sounds.
    AbstractThe global cumulative constraint was proposed for mod-
    elling cumulative resources in scheduling problems for finite domain (FD)
    propagation. Since that time a great deal of research has investigated new
    stronger and faster filtering techniques for cumulative, but still most of
    these techniques only pay off in limited cases or are not scalable. Re-
    cently, the “lazy clause generation” hybrid solving approach has been
    devised which allows a finite domain propagation engine possible to take
    advantage of advanced SAT technology, by “lazily” creating a SAT model
    of an FD problem as computation progresses. This allows the solver to
    make use of SAT nogood learning and autonomous search capabilities.
    In this paper we show that using lazy clause generation where we model
    cumulative constraint by decomposition gives a very competitive im-
    plementation of cumulative resource problems. We are able to close a
    number of open problems from the well-established PSPlib benchmark
    library of resource-constrained project scheduling problems.

This solver (the lazy solver) has been included in the MiniZinc distribution since version 1.0, and has been improved each version, e.g. by adding primitives it supports. See the NEWS file for more information.


I have tested the lazy solver with some problems, for example nonogram.mzn (which is implemented inefficient without the regular constraint), and am very impressed by it. It is very fast, though it cannot solve the P200 problem in a reasonable time.

Some comments about the lazy solver (some limitation is hopefully lifted in the future):

  • it cannot handle set vars.
  • all decision variables must be explicit bounded, e.g. var int: x; will not work, instead use something like var 1..10: x;.
  • Labeling: The papers state that the default labeling (e.g. solve satisfy) is often very good.

Conclusion: The lazy solver is definitely worth more testing.