[gecode-users] order in calls to status and commit...

[Guido Tack]

Sébastien Mouthuy wrote:

> Could you tell me what is exactly the order in which the functions
> status and commit are called ?

I presume you mean status and commit of a branching, right?

> For me it should be
>
> call to status with space S. if it returns true, then copy S. let's  
> call
> the copy Sc. Then call commit() with S and a=0. when we will have
> backtracked, commit will be called with Sc and a=1.

In principle, this is how it works. Our search engines however use  
recomputation, so they don't actually make a copy everytime, but  
sometimes use a copy that is higher up in the search tree and  
recompute the needed space from there.

The exact protocol is:

  * When you call Space::status, after computing a fixpoint of the  
propagators, the space calls the status method of the installed  
branchings to find the first branching that returns true. If there is  
none, the status is SS_SOLVED, otherwise it's SS_BRANCH.
  * When you call Space::description, the space asks the branching  
that returned true for a description and returns it
  * When you call commit, the space tries to find the branching that  
matches the description, and calls its commit method.

> I ask this question because I post a branching in the commit  
> function of
> another branching. Then I catch the following exception:
> terminate called after throwing an instance of
> 'Gecode::SpaceNoBranching'
>   what():  Space::commit: Attempt to commit with no branching

This means that in the commit step, the space didn't find a branching  
that matched the branching description. This could either mean that  
the branching description is bogus, or that your branching really  
hasn't been installed yet.

Are you using the standard, built-in search engines? If yes, please  
check if the problem still persists with c_d=1 and a_d=100000 as  
parameters passed to e.g. DFS (switching off recomputation). If the  
problem goes away using these options, there's either something wrong  
in our Space::commit logic, or in the way you create and use  
BranchingDescs.

Cheers,
	Guido

-- 
Guido Tack
Programming Systems Lab, Saarland University, Germany
http://www.ps.uni-sb.de/~tack



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ps.uni-sb.de/pipermail/users/attachments/20070528/eff63c93/attachment.htm>