### Comet: regular constraint, a much faster Nonogram with the regular constraint, some OPL models, and more

Since the last time some more Comet model has been written.

### Much faster Nonogram model using the regular constraint

In More Comet models, e.g. Nonogram, Steiner triplets, and different set covering problems I presented nonogram.co, a solver for Nonogram puzzles, and also noted that is was quite slow:*Well, it is nice to have some more optimization to do (or more probably, a complete remodelling)...*.

Inspired by the announcement this week of the ECLiPSe example of Nonogram solver using the regular constraint (see nono_regular.ecl.txt and regular.ecl.txt) - and also my earlier Gecode/R model nonogram.rb which used "regular expressions" - I created a Nonogram model in Comet using the regular constraint: nonogram_regular.co.

Let us first look at the `regular`

constraint.

**Regular constraint**

The `regular`

constraint (see the Comet model regular.co for my implementation) is a global constraint using a DFA (deterministic finite automata) which accepts (or not accepts) an input sequence given a "transition matrix". The constraint was presented by Gilles Pesant in "A Regular Language Membership Constraint for Finite Sequences of Variables" (2004).

My implementation of the `regular`

constraint is heavily borrowed from MiniZinc's builtin `regular`

predicate (from `lib/zinc/globals.mzn`

); the translation to Comet was very straightforward (omitting just some asserts).

An exemple of the usage of the constraint: We want to match the regular expression "123*21" (i.e. first "1", then "2", then zero or more "3", then "2", and last a "1"). Note: The length of the sequence is 10, so there must be 6 "3":s since "123" and "21" are "anchored" at the beginning and the end.

int len = 10;

int n_states = 5; // number of states

int input_max = 3; // the states are 1,2, and 3

int initial_state = 1; // we start with the 1 state

set{int} accepting_states = {n_states}; // This is the last state

// The transition matrix

int transition_fn[1..n_states, 1..input_max] =

[[2, 0, 0], // transitions from state 1: "1" -> state 2

[0, 3, 0], // transitions from state 2: "2" -> state 3

[0, 4, 3], // transitions from state 3: "2" -> state 4 | "3" -> state 3 (loop)

[5, 0, 0], // transitions from state 4: "1" -> state 5

[0, 0, 0]]; // transitions from state 5: END state...

exploreall

{

regular(reg_input, n_states, input_max, transition_fn, initial_state, accepting_states);

} using {

// ....

}

The unique sequence resulting from this automata is thus `1 2 3 3 3 3 3 3 2 1`

.

For using `regular`

in the Nonogram problem, the automata for each row/column clue, must be built, preferably by a function. In regular.co this is done with the function `make_transition_matrix`

, which by far was the hardest part of this problem (and surely could be written in a smoother way).

For the Nonogram clue `[3,2,1]`

- which represents the regular expression "0*1110*110*10*" - the following automata (transition matrix) is generated:

1 2

0 3

0 4

5 0

5 6

0 7

8 0

8 9

9 0

Note that the `regular`

function uses 0 (zero) as the failing state, so the states must start with 1. This is taken care in the model as the resulting value is subtracted by 1.

As usual in my models, the regular constraint is just a "convenience function", i.e. not using special written propagation methods etc.

The `regular`

constraint has - of course - more applications than for Nonogram solving. I plan to look more into this.

**The Nonogram solver: nonogram_regular.co**

After the `regular`

constraint and the automata generator was written, it was quite easy to change the old Nonogram solver to use these new tools. The result is in nonogram_regular.co. I was quite curious how fast this version should be compared to the former slow model. In short: it is much faster.

As comparison the Lambda instace took about 12 seconds with the old model; with the new model it takes 0.5 seconds, which is a nice improvement. I never finished a run for Nonunique problem with the older model; the new model takes 0.5 seconds (including the startup of the Comet program). Etc.

The P200 problem nonogram_p200.co now takes 2:05 minutes, which can be compared with 57 seconds for the Gecode/R model. Thus, the Comet model is still slow compared to Gecode version and the ECLiPSe version, which solves the P200 problem in just a second or two. Maybe some creative labeling or a "proper" regular constraint can fasten things up...

Update some hour later: One way to gain about 30 seconds to 1:30 minutes on the P200 problem was to explicitly state the consistency level to `onDomain`

, e.g. `cp.post(a[m] == q0, onDomains)`

, and to use another labeling strategy:

forall(i in 1..rows, j in 1..cols : !board[i,j].bound()) {

// label(board[i,j]); // the former strategy

tryall

}

Some more Nonogram problems have been coded:

- nonogram_bear.co: Bear

- nonogram_castle.co: Castle

- nonogram_crocodile.co: Crocodile

- nonogram_p199.co Problem P199

- nonogram_p200.co Problem P200 (see above)

- nonogram_ps.co Problem PS

- nonogram_soccer_player.co: Soccer player

**An aside about regular expressions**

I have been very interested in regular expressions (especially the more expressive Perl type) for a long time. In 1997 I wrote a simple Perl program MakeRegex which returns a regular expression given a list of words. It was later Appletized in MakeRegexApplet. Now there are better programs/modules for this.

### OPL Models

One of my projects is to translate the OPL models from Pascal Van Hentenryck "The OPL Optimization Programming Language" into Comet. Even if OPL and Comet are different languages the reading of the book has been very awarding. Thanks again, Pascal!Some OPL models already have been published, but now I've been more systematic and started from the beginning. More models to come.

- queens8.co: 8-queens
- queensn.co: n-queens
- magic1.co: Magic sequence
- magic2.co: Mmagic sequence
- The OPL model magic3.mod has already been published as magic_sequence.co
- map.co: Coloring a map
- house2.co. Scheduling building a house. Note: this not exactly the same as the books, since I can't get setCapacityMax to work as expected
- stable_marriage.co: Stable marriage

**Finding: arrays in a tuple**

In Comet: New models, e.g. Einstein puzzle, KenKen, Kakuro, Killer Sudoku, Stigler's Diet problem, translations of OPL models I wrote

One big difference here: In Comet it is not allowed to have an array in a tuple, so the use data must be a separate matrix.

I've found a way of using arrays in a tuple, by first initialize the values in a matrix and then - by using the `all`

function - "slice" the values into the tuple array. This has been done in the models fixed_charge2.co and production3.co.

Example from fixed_charge2.co:

tuple productType {

int profit;

set{Machines} machines;

int[] use;

}

int use[Products, Resources] = [[3,4],[2,3], [6,4]];

productType Product[Products] =

[productType(6, {shirtM},all(i in Resources) use[shirt,i]),

productType(4, {shortM},all(i in Resources) use[shorts,i]),

productType(7, {pantM},all(i in Resources) use[pants,i])];

### Combining different models

The alphametic problem`SEND + MOST = MONEY has the additional requirement to maximize the value of ````
MONEY. The older model send_most_money.co does that and nothing more.
```One natural extension of the problem is the following:

* first find the maximum value of `MONEY`

* then find all the solutions with this value.

```
```The model send_most_money2.co has two functions:

* `smm`

which is just the constraint for the alphametic problem

* `send_most_money`

which has a parameter `money`

.

`send_most_money`

is first called with 0, indicating that is should maximize the value of `MONEY`

, and then returns that value. The next call to `send_most_money is with the calculated MONEY value, which indicates that all solutions should be generated. `

```
```The answer is

check all solutions for MONEY = 10876

x[9,7,8,2,1,0,4,6] MONEY: 10876

x[9,7,8,4,1,0,2,6] MONEY: 10876

### Jim Orlin's Logic Puzzle

In Colored letters, labeled dice: a logic puzzle Jim Orlin stated a logic puzzle:
My daughter Jenn bough a puzzle book, and showed me a cute puzzle. There are 13 words as follows: BUOY, CAVE, CELT, FLUB, FORK, HEMP, JUDY, JUNK, LIMN, QUIP, SWAG, VISA, WISH.
There are 24 different letters that appear in the 13 words. The question is: can one assign the 24 letters to 4 different cubes so that the four letters of each word appears on different cubes. (There is one letter from each word on each cube.) It might be fun for you to try it. I’ll give a small hint at the end of this post. The puzzle was created by Humphrey Dudley.

...

If anyone wants to write an Excel spreadsheet and solve it via integer programming, please let me know. I’d be happy to post the Excel spreadsheet if you send it to me, or link to it if you post it and send me the URL.

This was a fun puzzle, so I modeled the problem in labeled_dice.co, and mailed Jim the link.

Some days later he wrote Update on Logic Puzzle where the contributed models were presented. There where another Comet model WordPuzzleSchaus.co by Pierre Schaus, one of Comet's developers. Pierres model use an different and more elegant approach than mine.

Jim also linked to some other logical puzzles from the great collection brownbuffalo.sourceforge.net (which have solutions in ECLiPSe/Prolog). One of these puzzles was Building Blocks, in the same vein as his labeled dice puzzle. Hence I had to make a Comet model of this problem: building_blocks.co.

He concludes the post with the following:

Incidentally, the ease for solving it using Constraint Programming makes me think that Constraint Programming should be considered a fundamental tool in the OR toolkit.

### Other Comet models this week

Here are the other Comet models created/published this week. Some of them where very easy to do since they are translations of my MiniZinc models.
- assignment.co: Assignment problem (Winston, "Operations Research", page 393f)
- assignment2.co: Assignment problem, swimming team exam (Winston, "Operations Research", page 398)
- assignment3.co: Assignment problem, desert island example (Winston, "Operations Research", page 399, problem 3)
- assignment6.co: Assignment problem (GLPK)
- building_blocks.co: Building blocks (Dell logic puzzle), see aboce
- car.co: Car sequencing (OPL)
- coins3.co: Coins problem (ECLiPSe)
- four_islands.co: Four island puzzle (Dell Logic Puzzles)
- golomb_ruler.co: Golomb ruler (CSPLib problem 6)
- minAssignment_test.co: Minimum assignment problem, using the builtin constraint minAssignment
- pigeon_hole.co: Pigeon hole problem
- sliding_sum.co: Global constraint sliding sum
- social_golfer1.co: Social golfer proble, (CSPLib problem 10)
- subset_sum.co: Subset sum problem (Murty)

```
```

```
```

## Comments

Pierre Schaus' model may be more elegant, but I find it harder to read and it also contains a bug. The bug is easy to spot in the output: one cube is assigned 5 letters, while another one is assigned 7 (using Comet 1.2). What's missing is of course a constraint that states how many times each cube's index may appear in the list 'cube':

int occ[1..4] = [6,6,6,6];

cp.post(exactly(occ, cube));

Once that's added, the solution is correct.

Posted by: Thorsten Winterer | March 24, 2009 01:34 PM

Thorsten: Thanks for the clarification of Pierre's model.

I tend to program more for readabilty than elegance, which makes my programs sometimes look quite boring...

Posted by: hakank | March 24, 2009 09:43 PM