" /> My Constraint Programming Blog: October 2009 Archives

« September 2009 | Main | November 2009 »

October 31, 2009

Some new models, etc

The readers that follows me on Twitter (hakankj) have probably already has seen this, but here follows a list of models, etc, not yet blogged about.

MiniZinc: Different models

The following four models are translation of my Comet models: And here are some new models:

Nonogram related

A large 40x50 Nonogram problem instance in MiniZinc: nonogram_stack_overflow.dzn to be used with nonogram_create_automaton2.mzn model. The problem was mentioned in Stack Overflow thread Solving Nonograms (Picross). It is solved in under 1 second and 0 failures.

Today my Nonogram model nonogram_create_automaton2.mzn was included in the great Survey of Paint-by-Number Puzzle Solvers (created by Jan Wolter).

My MiniZinc model is described and analyzed here. I'm not at all surprised that it's slower compared to the other solvers; it was quite expected.

Some comments:
Assessment: Slow on more complex puzzles.

...

Results: Run times are not really all that impressive, especially since it is only looking for one solution, not for two like most of the other programs reviewed here. I don't know what the differences are between this and Lagerkvist's system, but this seems much slower in all cases, even though both are ultimately being run in the Gecode library.
Update 2009-11-01
I later realized two things:

1) That the mzn2fzn translator did not use the -G gecode flag, which means that Gecode/FlatZinc uses a decomposition of the regular constraint instead of Gecode's built in, which is really the heart in this model. The model is basically two things: build an automata for a pattern and then run regular on it.
2) When Jan compiled Gecode, he set off all optmization for comparison reason. This is quite unfortunate since Gecode is crafted with knowledge of the specific optimizations.

I there have run all problems by myself and see how well it would done (at least the ballpart figure) when using an "normal" optimized Gecode and with the -G gecode flag for mzn2fzn.

Explanation of the values:
Problem: Name of the problem instance
Runtime: The value of runtime from Gecode/FlatZinc solver
Solvetime: The value of solvetime from Gecode/FlatZinc solver
Failures: Number of failures:
Total time: The Unix time for running the complete problem, including the time of mzn2fzn (which was not included in the benchmark).
A "--" means that a solution was not reached in 10 minutes.
Problem Runtime Solvetime Failures Total time
Dancer 0.002 0.000 0 1.327s
Cat 0.009 0.002 0 0.965s
Skid 0.012 0.006 13 0.660s
Bucks 0.015 0.004 3 0.866s
Edge 0.008 0.005 25 0.447s
Smoke 0.011 0.004 5 0.963s
Knot 0.026 0.006 0 1.450s
Swing 0.059 0.012 0 1.028s
Mum 0.120 0.093 20 1.811s
Tragic 6:24.273 6:23.607 394841 6:28,10
Merka -- -- -- --
Petro 2.571 2.545 1738 4.071s
M&M 0.591 0.510 89 1.961s
Signed 1.074 1.004 929 2.461s
Hot -- -- -- --
Flag -- [lazy solver: 2 solutions in 10 seconds] -- -- --
Lion -- -- -- --

It's interesting to note that the Lazy solver finds some solutions quite fast for the "Flag" problem. However, there where no other big differences compared to Gecode/FlatZinc. I also tested the problems with JaCoP's FlatZinc solver which solved the problems in about the same time as Gecode/FlatZinc with no dramatic differences.

As mentioned above, the exact values is not really comparable to the benchmark values. But it should give an indication of the result when using -G gecode and a "normal" optimized Gecode.

Unfortunately, I cannot link to the specific models due to copyright issues, but they can all be downloaded from the page Web Paint-by-Number Puzzle Export.

(End update)

Update 2009-11-02
Jan Wolter now have rerun the tests of my solver with the -G gecode option, and the time is much more like mine in the table above. The analysis is quite different with an assessment of Pretty decent, and the following under Result:
...

When comparing this to other solvers, it's important to note that nonogram_create_automaton2.mzn contains only about 100 lines of code. From Kjellerstrand's blog, it is obvious that these 100 lines are the result of a lot of thought and experimentation, and a lot of experience with MiniZinc, but the Olšák solver is something like 2,500 lines and pbnsolve approaches 7,000. If you tried turning this into a fully useful tool rather than a technology demo, with input file parsers and such, it would get a lot bigger, but clearly the CSP approach has big advantages.

(End update 2)

Also, the Gecode nonogram solver is included in the survey: called Lagerkvist. I'm not sure when it was added to the survey. It use the latest version of Gecode, so it must have been quite recent.

Some comments:
Assessment: Pretty decent.

...

Puzzles with blank lines seem to cause the program to crash with a segmentation fault.

Otherwise it performs quite well. There seems to be about 0.02 seconds of overhead in all runs, so even simple puzzles take at least that long to run. Aside from that, it generally outperforms the Wilk solver. It's not quite in the first rank, especially considering that it was only finding one solution, not checking for uniqueness, but it's still pretty darn good.

...
I mailed Jan today about the -solutions n options in the Gecode related solvers (he tested my MiniZinc model with Gecode/FlatZinc), as well as some other comments about my model. Also, I will download the problems tested and play with them.

Tailor/Essence': Zebra puzzle

Suddenly I realized that there where no Zebra problem, neither at Andrea's or here. So here it is: zebra.eprime: Zebra puzzle.

Gecode: Words square problem

See Gecode: Modeling with Element for matrices -- revisited for an earlier discussion of this problem.

Thanks to Christian Schulte my Word square model is now much faster: word_square2.cpp.

From the comment in the model:
Christian Schulte suggested 
using branch strategy INT_VAL_SPLIT_MIN 
instead of INT_VAL_MAX .
This made an improvement for size 7 from
322 failures to 42 and from 1:16 minutes
to 10 seconds (for 1 solution).
 
Now it manage to solve a size 8 in a reasonable 
time (1:33 minutes and 1018 failures):
  abastral
  bichrome
  achiotes
  shippers
  troponin
  rotenone
  amerinds
  lessness
 
But wait, there's more!

In the SVN trunk version of Gecode, there is now a version of this model: examples/word-square.cpp where Christian Schulte and Mikael Zayenz Lagerkvist has done a great job of improving it (using a slighly smaller word list, though). It solves a size 8 problem in about 14 seconds. There is also two different approaches with different strengths, etc. I have great hopes that it will improved even further...

October 25, 2009

Comet version 2.0.1 released

Comet version 2.0.1 has been released (this Wednesday). It can be downloaded here.

From the release notes:

Version 2.0.1 is a revision on 2.0 that includes several enhancements and bug fixes. The Comet Documentation is now also shipping as a separate installer for each OS so that it can be updated on a more frequent basis, independent of the release of the Comet System. The installers for the Comet System include the latest version of the documentation.

...

This release has the following new features [with bug tracking id where applicable]:
Major additions since 2.0:

* New FlexibleUnaryResource that allows to specify different durations for activity depending on which resource the activity is executed.
* New CP constraints over set variables, including: SetGlobalCardinality, allDisjoint, atleastIntersection,isExcluded, and unionOf.

Other improvements:

* Added ability to change the row of a VisualActivity in gant charts
* Added ability to use set variables in LNS[#395]
* New section on soft global constraints in CP in the manual
* Added tooltips and setColor to VisualActivities
* Added events to var<:CP>{bool} [#365]
* Class documentation now shows inherited methods [#373,#393]
* Improved error messages for set atRank method [#402]
* Better error messages when no solution is found in CP [#401]
* Improved error messages in LNS with no initial solution [#400]
* Improved error messages in DBStatement::setParam with index out of range [#385]
* Added methods excludes and requires to var{set} [#380]
* Added getValue method to var{float} [#356]
* Allow use of var{int} in by clause of a forall [#374]
* Improved error handling in atmost constraint [#362]
* Tooltips on VisualRectangle, VisualCircle, VisualLine, VisualText, and VisualTextTable. [#363]
* Improved error handling in VisualDisplayTable [#359]

Bug Fixes:

* Fixed rank and filtering algorithms of AlternativeUnaryResource[#381]
* Fixed rank on UnaryResource with optional activities[#239]
* Fixed exactIntersection constraint.[#397]
* Fixed bug in random seeds leading to correlated UniformDistribution objects [#384]
* Fixed bug in Graphical Debugger that caused the last line to not be shown [#361]
* Fixed element constraint on 3D matrices[#369]
* Fixed array out of bounds error on VisualDisplayTable [#370]
* Fixed rounding problem when using cotln with SCIP library [#398]
* Implemented getSwapDelta and getMultipleAssignDelta on DisequationSystem [#318]
* Fixed memory leaks in CP library [#293]
* Fixed bug in breakable activities [#388]
* Fixed segfault when returning an int[][] from a user plugin [#386]
* Implemented casting var{float} to an int [#355]


For more about Comet, see My Comet page.

October 14, 2009

Gecode News Archive and RSS feed

Short notice: Gecode now has a News Archive. There is also a RSS feed.

The latest news snippet is the following:


2009-10-14 Layout

The Gecode web site layout has been improved. We now provide a news section on the front page, a dedicated news page, and an RSS feed for all news updates.


MiniZinc version 1.0.3 released

MiniZinc version 1.0.3 has been released. It can be downloaded here.

From the NEWS:


G12 MiniZinc Distribution version 1.0.3
---------------------------------------

Bugs fixed in this release:

* A fencepost error that was being introduced into flattened array access
reifications has been fixed.

* Common subexpression elimination has been improved in order to eliminate
redundant int and float linear equations during flattening.

* A bug that caused flattening to abort if array_*_element built-ins were
redefined has been fixed. [Bug #82]

* A bug in the implementation of the FlatZinc set_lt and set_gt built-ins
has been fixed. Note that the expected outputs for the corresponding
tests in the FCTS were also previously incomplete.

* The omission of the string_lit tag from the XML-FlatZinc DTD has been
corrected.

October 13, 2009

Gecode: Modeling with Element for matrices -- revisited

In Learning constraint programming - part II: Modeling with the Element constraint I complained about the lack of support for Element for matrices in Gecode. It was also my main complaint of Gecode in SweConsNet 2009 talk.

I'm happy to say that Gecode version 3.2 now contains support for this. Thanks to the Gecode team, and especially Christian! See the API for details.

The models mentioned in the former blog post has now been updated to use the new version of Element. They have the same name as the original model, just with a "2" added. The old code is kept (but commented) in the new models for comparison.

Example: Word square

As an example, here is the old variant for handling element in a matrix of words:
void element_offset(Space& space, 
                    IntArgs words,
                    IntVar e, 
                    IntVar word_len, 
                    IntVar c,
                    IntVar res,
                    IntConLevel icl = ICL_BND) {

  element(space, words, 
                plus(space, 
                     mult(space, 
                          e, 
                          word_len, icl), 
                     c, icl), 
                res, icl);

  
} // element_offset

      // ... and was used as such: 
       element_offset(*this, words, E[i], word_len_v, C[j], tmp, opt.ic());

The new version of Element makes this much easier:
        // ...
        element(*this, words_m, C[j], E[i], tmp, opt.icl());

Performance

For the Word square model the improvement in performance is significant. Now it is very easy to generate a word square of larger orders: The new model gives a solution of order 5 in less than 1 second, whereas the old model took much longer, over a couple of minutes. Order 6 with the new model takes about 2 seconds (I haven't waited for the old model to give a solution).

Here is an example of an order 7 word square; took about a minute with the new model.
laissez
almonry
impling
solideo
snidest
ernesse
zygotes
It is probably possible to tweak this further.

Warning

Last, please note the following warning from Modeling with Gecode about using this feature:
Tip 6.2 (Element for matrix can compromise propagation). Whenever it is possible one should use an array rather than a matrix for posting element constraints, as an element constraint for a matrix will provide rather weak propagation for the row and column variables.

...

October 08, 2009

MiniZinc: All my public MiniZinc models are now at G12 Subversion repository

All my public MiniZinc models (and data files) are now in the G12 SVN MiniZinc examples repository: http://www.g12.cs.mu.oz.au/mzn, subdirectory hakank/.

The file hakank/README states the following:
In this directory I have collected all the MiniZinc
models, data files, and tools that are available from
   http://www.hakank.org/minizinc/

Any new models on the site will be transferred to this
SVN directory as soon as possible.

Hakan Kjellerstrand, hakank@bonetmail.com
http://www.hakank.org/minizinc/
This means that the models (and other files) which is published at My MiniZinc page is the master, and I will put the files to the G12 SVN repository as soon as possible, hopefully directly after.

The structure in the repository is exactly the same as for the web site, which means that all models are directly in the hakank directory, and then two specific data collections in nonogram_examples and sudoku_problems

Some statistics of the collection (as of writing):
* .mzn files: 742
* .dzn files: 234
* .pl files (Perl program): 2
* README files: 1
* index.html files: 3
* .zip files: 2
*.java files: 1

For a total of 985 files.

I hope there are some use of them.

Also, see The MiniZinc Wiki.

October 07, 2009

Gecode version 3.2 released

Gecode version 3.2 is released. It can be downloaded here.

From the Changelog:
Changes in Version 3.2.0 (2009-10-05)

This release has some important bug fixes (in particular for global cardinality aka count), the documentation has been improved (worked around some issues with generation by doxygen), integrates the FlatZinc interpreter into the Gecode source tree, provides propagators for disjunctive scheduling (experimental), and lots of small changes and fixes. For more consistent names, branchings are branchers now and branching descriptions are choices (this you might have to adapt to).

  • Kernel
    • Other changes
      • A branching is now a brancher and a branching description is now a choice. (major).
        Details: Classes and member functions have been renamed accordingly. The change is necessary due to proper explanation in the forthcoming "Programming with Gecode".
  • Search engines
    • Other changes
      • Optimized thread creation by thread pools, now the creation and deletion of arbitrarily many parallel search engines also works for platforms using pthreads (Linux and MacOS). (minor)
      • Path for search provides top and empty methods. (minor, thanks to Vincent Barichard)
    • Bug fixes
      • The memory reported could be sometimes too low (that could only happen when an advisor allocates memory which they do only now). (minor)
      • Compiles again if no threads available. (minor)
  • Finite domain integers
    • Additions
      • Added regret_min and regret_max for IntVar and BoolVar (they were only available for IntView). (minor, thanks to Kish Shen)
      • Added branch and assign for single integer and Boolean variable. (minor)
      • Added element constraints for Matrix arrays. (minor, thanks to Håkan Kjellerstrand)
    • Other changes
      • The element constraint now computes more accurate variable bounds when being posted (to avoid arithmetic overflow in naive models). (minor)
      • The element constraint now throws an exception if used with an empty array. (minor)
      • Moved cumulatives to the new scheduling library. (minor)
      • Moved circuit to the new graph library. (minor)
    • Bug fixes
      • Slightly improved strength of the division propagator. (minor, thanks to Jan Kelbel)
      • Fixed serious bug in the bounds propagator for global cardinality. (major)
    • Performance improvements
      • Extensional propagators using DFAs or REGs (aka regular) use a more compact state representation but create their state more eagerly. That can improve performance considerably (twice as fast) at a slight increase in memory. (minor, thanks to George Katsirelos, Nina Narodytska)
      • Optimized n-ary disjunction and conjunction and the clause constraint. (minor)
      • Linear constraints over Boolean variables with unit coefficients (aka Boolean cardinality constraints) have been reimplemented. Less memory (minus 30%) and more speed. For example, BIBD runs 10% faster now. (minor)
  • Finite integer sets
    • Additions
      • Added branch and assign for single set variable. (minor)
      • Added element constraints for Matrix arrays. (minor, thanks to Håkan Kjellerstrand)
    • Other changes
      • The element constraint with an integer index variable now throws an exception if used with an empty array. (minor)
  • Scheduling constraints
    • Additions
      • Added propagators for disjunctive scheduling (unary resource scheduling). This is still experimental as the propagators are not yet optimized and branching and modelling support is not yet available. (major)
      • Added a new module for scheduling. To use scheduling constraints, you have to include <gecode/scheduling.hh> and link against the scheduling library. (minor)
  • Graph constraints
    • Additions
      • Cost-based variants for circuit added. (minor)
      • Added a new module for graph constraints. To use graph constraints, you have to include <gecode/graph.hh> and link against the graph library. (minor)
  • Minimal modeling support
    • Additions
      • Added element constraints for Matrix interface to arrays. (minor, thanks to Håkan Kjellerstrand)
  • Script commandline driver
    • Additions
      • Added new standard option for options called symmetry. (minor)
    • Other changes
      • The driver takes copies of all string values passed top it. (minor, thanks to Luca Di Gaspero)
  • Support algorithms and datastructures
    • Other changes
      • No longer depend on availability of timersub. (minor, thanks to Alexandre Fayolle)
  • Example scripts
    • Additions
      • Added branching following Warnsdorff's heuristic for Knights. (minor)
    • Other changes
    • Bug fixes
      • Fixed wrong symmetry breaking for TSP. (minor, thanks to Geoffrey Chu)
      • Fixed zero cost edges in TSP examples. (minor)
  • Gist
    • Other changes
      • The Gist console now has a toolbar that provides buttons to clear the text as well as to configure the console window to stay on top of Gist. Furthermore, after adding output, the console now automatically scrolls to the bottom. (minor)
    • Bug fixes
      • Gist now places clones also on the leftmost branch during search. (minor)
  • Gecode/FlatZinc
    • Additions
      • The Gecode interpreter for the FlatZinc language is now part of the main Gecode source tree. (major)
  • General
    • Other changes
      • Compiles with MSVC 2005 again. (minor, thanks to David Rijsman)
    • Bug fixes
      • The configure script checked for Qt 4.2, although Gist requires at least Qt 4.3. (minor)
    • Documentation fixes
      • Cleaned up the generated reference documentation, and introduced a number of workarounds for issues in doxygen. In particular, the documentation for linear constraints over Boolean variables and for the thread abstractions is now generated properly. (major)
      • Mention that also grep is needed for building Gecode. (minor, thanks to Vivian De Smedt)
Also, don't forget to read the new version of Modeling with Gecode.

Note: I have yet to change my models at My Gecode page to version 3.2.

Update some hours later: The following three models was the only that has to be changed, all with the simple addition of #include <gecode/scheduling.hh>:

October 01, 2009

MiniZinc: 151 new Nonogram problem instances (from JaCoP)

The latest versions of JaCoP (download here) includes 151 Nonogram instances (ExamplesJaCoP/nonogramRepository/). I wrote about these and the included Nonogram solver in JaCoP: a request from the developers (Knapsack and Geost) and Nonogram labeling.

When I (beta) tested the new FlatZinc support for this version, I converted these instances to MiniZinc's data file (.dzn) for some tests. It is a fun way of testing a system.

Now all these problem instances have been published. They are to be used with the MiniZinc Nonogram model nonogram_create_automaton2.mzn. See At last 2: A Nonogram solver using regular written in "all MiniZinc" for more about this model.

All problem instances - in MiniZinc's .dzn format - are available in www.hakank.org/minizinc/nonogram_examples, and also packed in the Zip file nonogram_examples.zip. The name of each file corresponds to the files in JaCoP's ExamplesJaCoP/nonogramRepository/; the file data000.nin is here called nonogram_jacop_data000.dzn, etc. (A larger file, nonogram_examples_with_fzn.zip also includes the generated .fzn files. Note: I used mzn2fzn for MiniZinc version ROTD/2009-09-13 for this. See below how to generate these files.)

Batch running with JaCoP/Fz2jacop

Running many FlatZinc models with JaCoP's Fz2jacop is not optimal because of the overhead of the Java startup. Instead I used a Java program, JaCoPFznTest.java (based on a program from Krzysztof Kuchcinski, one of JaCoP's main developers. Thanks, Kris.).

The main call is

fz.main(new String[] {"-s", "-a", m});

which means that statistics should be shown and also require to return all solutions of the problem.

The FlatZinc (.fzn) files was generated from the .dzn files with the following command:

foreach_file 'mzn2fzn -G jacop --data $f -o $f.fzn nonogram_create_automaton2.mzn' '*.dzn'

ExamplesJaCoP.Nonogram vs. JaCoP/Fz2jacop

This time I just compared the run time of the two different approaches for solving Nonograms with JaCoP:
* The Java program ExamplesJaCoP.Nonogram
* Running JaCoP's MiniZinc/FlatZinc solver Fz2jacop

The program instances is, with one exception the same as in the distributed ExamplesJaCoP.Nonogram. Since I wanted both program to solve for all solutions, I excluded instance #83 (see below) since it has too many solutions. However, the P200 problem in included since it is hardwired in ExamplesJaCoP.Nonogram. This means that it it still 151 problems running.

The result:
* ExampleJaCoP.Nonogram took 14.8 seconds
* The Fz2jacop version took 17.8 seconds

I'm quite impressed with both of these results, especially Fz2jacop's As shown in JaCoP: a request from the developers (Knapsack and Geost) and Nonogram labeling, many problems are solved in "0" milliseconds, but still.

Instance #83

As mentioned above, problem instance #83 was excluded since it has too many solutions. Here are two of them. It looks like a person (alien?) standing on a spaceship waving.
                              #           #         
                            #       #               
                      # # # #       # # #           
                          #   # # #   # # #         
                  #                   #     #       
                #         #     # # # # #           
              #     #   #           # # #     #     
              #   #   #             # # #   #       
              # #   #               # # #           
              # #                   #   #           
                #                   #   #           
          # # # # # # # # # # # # # # # # #         
      # # # # # # # # # # # # # # # # # # # # #     
    # # # #     # #     # # #     # #     # # # #   
  # # # # #     # #     # # #     # #     # # # # # 
    # # # #     # #     # # #     # #     # # # #   
      # # # # # # # # # # # # # # # # # # # # #     
          # # # # # # # # # # # # # # # # #         
              # # # # # # # # # # # # #             
                  #       #       #                 
                # #       #       # #               
                #         #         #               
              # #         #         # #             
              #           #           #             
            # # #       # # #       # # #           
----------
                              #           #         
                            #       #               
                      # # # #       # # #           
                          #   # # #   # # #         
                  #                   #     #       
                #         #     # # # # #           
              #     #   #           # # #   #       
              #   #   #             # # #     #     
              # #   #               # # #           
              # #                   #   #           
                #                   #   #           
          # # # # # # # # # # # # # # # # #         
      # # # # # # # # # # # # # # # # # # # # #     
    # # # #     # #     # # #     # #     # # # #   
  # # # # #     # #     # # #     # #     # # # # # 
    # # # #     # #     # # #     # #     # # # #   
      # # # # # # # # # # # # # # # # # # # # #     
          # # # # # # # # # # # # # # # # #         
              # # # # # # # # # # # # #             
                  #       #       #                 
                # #       #       # #               
                #         #         #               
              # #         #         # #             
              #           #           #             
            # # #       # # #       # # #           
----------
This output was generated with the (very new) option {noresult} in mzn_show.pl. (This option don't display the real numeric results.)