[gecode-users] Gecode terminates on incomplete solution

[Christian Schulte]

The linear constraints for Boolean are in fact specialized versions that are
as smart as possible, they are linear only by name ;-)

But there is one thing that will never go away: Gecode has not been built to
be good at Booleans! You might be much better off with a SAT solver or a
Pseudo Boolean solver... If you have a mix of integers and Booleans then
Gecode is fine.

Cheers
Christian

--
Christian Schulte, KTH, web.it.kth.se/~cschulte/

-----Original Message-----
From: Philipp Keck [mailto:philipp.keck at gmx.de] 
Sent: Thursday, June 12, 2014 09:15 PM
To: cschulte at kth.se
Cc: users at gecode.org
Subject: Re: [gecode-users] Gecode terminates on incomplete solution

Hi Christian,

thanks for your reply!

You are right, the boolean variants of these constraints can be modeled like
that. In fact, my current solution works fine with "linear" - but it's slow.
Therefore, I was looking for specialized constraints like "distinct" or
"atmost", because Max indicated that they might be faster ("They usually
perform much better than linear constraints.").
If however the "linear" constraint in Gecode is already as good as possible
(I use the first one here
http://www.gecode.org/doc-latest/reference/group__TaskModelIntLB.html#ga7dba
f2c0ceb605f34731328004c73b57),
I'll stick with that. Since I don't know that much about constraint
propagation, I imagine (!) that a linear constraint requires some sort of
computation to sum up a (weighted) array, while an implementation of
"atmost_1" would only need to store the single variable from the array that
is currently true, and then prevent the rest from being set to true. That's
why I currently believe (!) that "linear" might by unnecessarily powerful
and not optimally efficient for my use case. 
Again, I may well be wrong.

A "distinct" constraint on boolean variables would only make sense for two
variables, obviously. What I need is something like "distinct except 0" 
(http://www.emn.fr/z-info/sdemasse/gccat/Calldifferent_except_0.html),
i.e. variables set to zero/false are ignored and only one variable is
allowed to be true/one. I can't achieve that with inequality, because two
variables may be 0, actually even all variables may be 0.

It does work with a pair-wise NAND constraint implemented like that:
forall i != j do: rel(*this, variables[i], BOT_AND, variables[j], 0); But
that gives me O(n^2) constraints only to express the single requirement that
at most one of these variables can be true. And I have
O(m^2) of these if m is my problem size, so I would end up with O(m^4)
constraints in Gecode. Am I overlooking something like an inequality
constraint for multiple boolean variables?

Best
Philipp

Am 12.06.2014 17:19, schrieb Christian Schulte:
> Hi,
>
> Yes, it is true that these constraints do not exist for 0/1 as they 
> are not
> needed:
>   - distinct for Boolean variables is inequality
>   - atmost/count is linear for 0/1! Check MPG.
>
> Best
> Christian
>
> --
> Christian Schulte, Professor of Computer Science, KTH, 
> www.ict.kth.se/~cschulte/
>
>
> -----Original Message-----
> From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On 
> Behalf Of Philipp Keck
> Sent: Thursday, June 12, 2014 3:27 PM
> To: Max Ostrowski; tack at gecode.org; users at gecode.org
> Subject: Re: [gecode-users] Gecode terminates on incomplete solution
>
> Hi Guido, Hi Max,
>
> thank you very much for taking your time! Your tips and ideas just 
> doubled the size of my todo list :-), that's why it took me so long to 
> reply. In particular, the tip about pseudo-boolean solvers was great. 
> I am now experimenting with Sat4J (both PB and MinCostSAT), which is a 
> lot slower than Gecode, but solves some more problem instances on 
> which Gecode needs to search a large tree. But because it is only 
> quick on decision problems and too inefficient for my optimization 
> problems, I continue my experiments with Gecode.
>
> About the initial problem mentioned in the subject of this mail:
> BoolVarArray was indeed the solution. I didn't copy it from the 
> examples at first, because I don't know in advance how much variables 
> there will be, so I thought I couldn't use it. But by first reading 
> all the variables to a list and then placing them in an (uninitialized)
BoolVarArray works fine.
> Thank you!
>
> Thanks to Gist, I can now try to experiment with different kinds of 
> constraints. It looks like the search space is simply too large right now.
> With Gist activated, Gecode explores around 500 failures every two 
> seconds - no matter which way I model the constraints. In comparison 
> to the entire
> (binary) search tree, that's almost nothing. After a few hours, more 
> than 90% of the search tree is still linear (to the left), i.e. has 
> not yet been explored.
>
> Is it true that alldifferent/distinct/atmost/count only exist for 
> integer variables? And according to the manual BoolVars can't be casted to
IntVars.
> But maybe this is a solution (I don't know enough C++ to
> tell): As described in the manual Figure 27.4, one could use 
> Gecode::Int::Count::LqInt<VX,VY> to implement a "count" or "atmost"
> method that accepts a BoolVarArray instead of a IntVarArray. Is that 
> possible?
> The kind of constraint I need should ensure that at most one of a 
> given list of boolean variables is true. So it could be "all different 
> except 0", "distinct except 0", "Multi-XOR", or it could be modeled 
> with "atmost" or "count", if they are able to handle boolean variables.
>
> Best,
> Philipp
>
> Am 19.05.2014 09:36, schrieb Max Ostrowski:
>> Hi,
>>
>> On 05/18/2014 06:38 PM, Philipp Keck wrote:
>>> Hi,
>>>
>>> I am new to Gecode and also to Constraint Programming. While my 
>>> first problem may be a general CP question (so off-topic here? In 
>>> that case ignore it please.), my second problem is Gecode-specific.
>>>
>>> My first problem is that Gecode either finds a solution immediately
>>> (<1ms) and without any backtracking (peak-depth equals explored 
>>> nodes-1), or takes longer than I want to wait (at least 2 hours).
>>> This problem might be related to my problem instances, because 
>>> or-tools shows exactly the same behaviour. My problem instances have
>>> 1,000 to 10,000 boolean variables and 400 to 2,500 constraints. 
>>> There are both large and small instances that can be solved within 
>>> milliseconds, and both large and small instances that take a long 
>>> time. For those that take more than
>>> 2 hours, I still am sure that there is a solution, because Gurobi 
>>> finds one when I formulate the same problem as an LP.
>>> How could I improve the running time of Gecode here? Does adding 
>>> more constraints make finding (any feasible) solution faster 
>>> (because the search space is more restricted and therefore the 
>>> search tree is
>>> smaller) or slower (because there are simply less solutions)? Should 
>>> I add redundant constraints?
>> If adding more constraints make the search faster or not can not be 
>> said in general.
>> Adding redundant constraints is always worse a try, if you can 
>> improve propagation strength with it.
>>> For a set of boolean variables, if I want at most one of them to be 
>>> 1, is it better to add "a+b+c+... <= 1" using a linear-Constraint, 
>>> or should I use "a!=b", "a!=c", "b!=c", ... instead? Unfortunately I 
>>> have difficulties finding out the answers by experimenting because 
>>> Gecode runs for such long times. Is there a way to get some output 
>>> during the computation?
>> The first thing you can try is using global cosntraints that exactly 
>> fit your needs.
>> In this case, allDifferent or atmost, etc...
>> They usually perform much better than linear constraints.
>> (It may be the case that Gecode automatically detects this in your 
>> case and replaces the linear constraints with the global constraints.
>> )
>>
>> Furthermore, your problem sounds like a PB(Pseudo-Boolean) problem.
>> So maybe you should try a PB solver.
>>
>> Best,
>> Max
>>
>>> My second problem is a weird behaviour of Gecode terminating with 
>>> some variables remaining unassigned:
>>> My models have the following structure: I have boolean variables 
>>> only and two kinds of constraints. The first kind of constraints 
>>> requires exactly c variables out of a certain subset to be 1, e.g. 
>>> "a+c+d+x+y = 3" or "a+b = 1". The second kind allows at most one 
>>> variable to be 1, e.g. "a+b+r <= 1". That's all.
>>> As mentioned above, Gecode either terminates immediately, or takes a 
>>> very long time. However, I have a particular problem instances that 
>>> makes Gecode terminate and report "solutions: 1" without having all 
>>> the variables set. So there are variables that still have [0..1] 
>>> instead of a specific value and val() throws ValOfUnassignedVar. Why 
>>> does Gecode terminate before it has a solution?
>>> I call it like this:
>>> branch(*this, allVariablesArgs, INT_VAR_NONE(), INT_VAL_MIN()); 
>>> Using this call on the other hand makes Gecode compute forever (i.e.
>>> more than 2 hours):
>>> branch(*this, allVariablesArgs, INT_VAR_RND(someRnd), 
>>> INT_VAL_RND(someOtherRnd));
>>>
>>> The problem might be related to how I implemented the copy function.
>>> I have my variables inside a std::map<std::string, BoolVar> *and* 
>>> inside a BoolVarArgs and clone them like this:
>>> variablesMap = s.variablesMap;
>>> allVariablesArgs = BoolVarArgs(s.allVariablesArgs); I don't know if 
>>> that's the correct way to go. In particular, my copy implementation 
>>> never uses the share-parameter.
>>> After reading the thread "Integer Variable Randomization" on this 
>>> mailing list, I also tried setting -c-d and -a-d to high values, but 
>>> still the copy-method was called many times.
>>>
>>> Thank you for any help!
>>> Philipp
>>>
>>> Platform: Windows 7 x64, Visual Studio 2013 x64, Gecode 4.2.1
>>>
>>> _______________________________________________
>>> Gecode users mailing list
>>> users at gecode.org
>>> https://www.gecode.org/mailman/listinfo/gecode-users
>
> _______________________________________________
> Gecode users mailing list
> users at gecode.org
> https://www.gecode.org/mailman/listinfo/gecode-users
>