Eclipse CLP标签：排除排列

Question

I am solving a scheduling problem (briefly described here: SWI Prolog CLP(FD) scheduling switched to ECLP).

I am able to get some solution quickly, but now I want to incorporate some optimization task.

A part of the problem/schedule row looks like D1,D2,N1,N2,A0,A1,A2,..,A9 where some cost for this variables is C1,C1,C1,C1,C2,C2,C2,...,C2 . So from this point of view any permutation of assignments to A0..A9 has the same cost. But, obviously, during the labeling process the solver backtracks through all the possibilities.

Short note: I am calculating this only in my head, but I think the search space only for this described part is like number of subsets of size 10 from domain of size 15 * 10! . This is quite some amount of space to backtrack through. And from the point of view of cost/optimization as well as the constraint satisfaction, each permutation has the same cost/satisfiability - the order of variables does not matter.

Can I somehow affect the labeling/search procedure to do not bother with order of variables within some list? Or can you provide some way how to remodel the problem to be able to work this way?

Answer 1

What you are talking about is the issue of symmetry in modelling, and there is a whole research area dedicated to it. I would say there are essentially three ways of addressing this:

1. reformulate the model with different variables such that there are inherently fewer ways of representing equivalent solutions
2. add symmetry-breaking constraints to reduce the total number of solutions but keep at least one of each equivalence class. This is typically done with arithmetic or lexicographic ordering constraints, which effectively define how a "canonical" representation of a solution should look like.
3. try a dynamic symmetry breaking technique that your system provides, such as ldsb . These typically take a description of the symmetry, and try to do something about it (but don't expect wonders).

In your case, I would start with point 1: you currently have variables A[I,D]=W meaning "slot I of type A on day D is filled with worker W" although all your A-slots are equivalent.

You could instead have binary variables JobA[D,W]=1 "worker W does a job of type A on day D", together with a constraint sum(JobA[D,*])#=10 to make sure you have 10 slots filled.

Another model I can imagine is having variables Job[D,W]=T "worker W does job of type T on day D" (encoding your job types T as 1..3) and use occurrences/3 or gcc/2 constraints to enforce your various conditions.