[gecode-users] member function branching

Christian Schulte cschulte at kth.se
Fri Nov 14 14:22:45 CET 2008

Hi Patrik,

cheating is illegal in Gecode ;-) Recomputation is absolutely essential for
Gecode to be efficient! So switching off recomputation is not really an
option. Then, the alternative also disables an important feature of
recomputation (I also would expect that your idea does not work; in the best
case it will run into an infinite loop, in the worst case it will just go
boom): to make recomputation efficient, one keeps recording constraints
(that is what commit does). Then one only computes a single fixpoint doing
the actual propagation (that is what status does). Computing several
fixpoint during recomputation makes things realy sloooooow.

So you will have to bite the bullet and define a proper branching that
returns a branching description that has recorded all information (in your
case the values for that variables) your branching is going to need to redo
a decision during recomputation. This is as Mikael has spelled it out in one
the previous emails.


Christian Schulte, www.ict.kth.se/~cschulte/

-----Original Message-----
From: users-bounces at gecode.org [mailto:users-bounces at gecode.org] On Behalf
Of Patrik Haslum
Sent: Thursday, November 13, 2008 3:37 PM
To: Mikael Zayenz Lagerkvist
Cc: users at gecode.org
Subject: Re: [gecode-users] member function branching

Mikael Zayenz Lagerkvist wrote:

> The MemberFunctionBranch that was posted earlier can not be used in
> the way that you propose. The problem is in the part:
>     next_var = <some calculations to figure out next branching variable>;
> Due to batch recomputation, the MemberFunctionBranch must not depend
> on the values of the variables, since the space in most cases has not
> been propagated yet.

If that is the problem, then I can fix it by just setting the c-d 
parameter to 1, correct?

Alternatively, can I simply call space->status() in the branching 
(member) function to ensure that propagation is done before looking at 
current values of variables? (that would let recomputation still be done 
in batches when there are several variable branch points between two 
"figure out what to do next" branch points, although that doesn't happen 
very often).

	/P at trik

Gecode users mailing list
users at gecode.org

More information about the gecode-users mailing list