My ConstraintSolver.jl page

Specific Domains Optimization (Mathematical)
1

One of my (other) Julia-related interests is Ole Kröger’s Home · ConstraintSolver .

My ConstraintSolver.jl models are here: My Julia ConstraintSolver.jl page , also available at https://github.com/hakank/hakank/tree/master/julia/constraints .

The page contains about 120 constraint models, such as these mandatory CSP problems:

But also some that’s not very common problems:

And here are some of the (decomposition) of global constraints that’s missing in ConstraintsSolver.jl (available in http://www.hakank.org/julia/constraints/constraints_utils.jl ):

  • all_different_except_c
  • my_element
  • global_cardinality_count
  • cumulative
  • circuit and circuit_path
  • regular
  • atmost, atleast, and exactly
  • global_contiguity_regular

[I’ve also implemented constraint models in other constraint programming languages/systems, see my “Common constraint programming models” for some examples: http://www.hakank.org /common_cp_models/ ]

8 Likes
2

Woah! That looks like a lot of work. cc’ing @Wikunia

I’ve also implemented constraint models in other constraint programming languages/systems

Nice! We have an upcoming talk from the MiniZinc folks at JuMP-dev https://live.juliacon.org/talk/3BBA7L. Can you compare and contrast the ergonomics of writing models in JuMP and MiniZinc? What could we change/do better?

3 Likes
3

@odow Thanks!

I’m looking forward to hear all your reactions on MiniZinc. It’s a really great constraint modelling language.

Regarding JuMP vs MiniZinc, I can only talk from my experience from ConstraintSolver.jl (which use JuMP) as I haven’t done much “plain” JuMP myself. I know that JuMP is a powerful mathematical programming system but haven’t much detailed knowledge in it.

From a constraint programmer’s perspective, I currently - and in general - prefer MiniZinc (and Picat) over ConstraintSolver.jl, since it supports many global constraints which are not yet implemented in ConstraintSolver, such as element, regular, modulo etc; and my decompositions of these are often not efficient enough. Also MiniZinc support general non linear constraints.

On the other hand, MiniZinc is not a full fledged programming language, so one have to pre-/post process the data to/from the solved model. Having a solver integrated with a language such as julia is much easier to work with. There’s a Python wrapper for MiniZinc (MiniZinc Python — MiniZinc Python 0.7.0 documentation) but then it’s two different language one have to program in. (Hmm, I realized that I haven’t tested that Python package in Julia; I’ll put that on my TODO list.)

One other aspect is that MiniZinc requires that someone writes a FlatZinc solver. Here I think that JuMP has an advantage since it can use the Julia ecosystem with already existing solver.

I hope I somewhat answered your question.

2 Likes