[gecode-users] Cloning problems

[Filip Konvička]

Hi,

first, thanks for the thorough explanation!

> Before I start with rambling about cloning, a tip:
> Gecode supports unary branchings (with a single alternatiuve only). So you
> could have a unary branching and don't have to have a mock-up empty branch.
> The search engines even optimize that case. If you are looking for an
> example, check the assign function in gecode/int.hh for assigning variables.
>   

We know about this (and use it for our own "assignment" branchings), but 
I don't see how this applies to our case? Clearly if the first 
alternative fails and we need to go on without that commit, we need 
another branch...? I'm sure we could do it all just manually without any 
branching or search engine, but this allowed us to test it with the DFS 
engine and compare to ours.

> In VarImp<VIC>::enter, the --idx[0] makes room for an additional entry. Then
> you keep moving actors to a free entry and by this create a new free entry
> for the propagation condition i. When the loop is done, you know that there
> is a free entry for propagation condition pc and that's where the propagator
> is entered.
>   

I see - seems like I misinterpreted the loop statement... too many *s 
and &s for one day, I guess :-)

> Let me come up with some idea where the trouble could be:
>  - you forget to update a variable or view at some place. Either in your
> branching, propagator, or model.
>    Then you can see an invalid pointer in the dependency array.
>    You might want to change the default constructor of VarBase in
> gecode/kernel/var.icc and the default constructor
>    of VarViewBase in gecode/kernel/view.icc so that they set varimp to NULL
> (actually, I just did that yesterday in the trunk as well). Then you will be
> sure that when you forget to update, you'll see a NULL pointer.
>   

Well, I checked that once again now (we've done that at least ten times 
in the last week :-)). I re-checked how the propagators 
subscribe/update/cancel, it is consistent with the IntVar propagators 
(BTW, in ReLinBin<Val,A,B,pc,Ctrl> in int-bin.hpp, you subscribe with 
PC_INT_VAL and cancel with PC_BOOL_VAL). The branching does not need any 
views or anything (it talks to the space directly via a static_cast).

>  - you commit a heinous crime in that you change the dependencies of a
> variable with cancel/subscribe during 
>    cloning. That is illegal and will for sure break everything. Note that
> creating a propagator during
>    cloning will commit that crime, too.
>   

We're not trying to do anything illegal :-) Even if we did that, I'm 
sure that the other testcases would fail too. But it's just those few :-)

> Hope that helps. Please do not hesitate to ask some more
>   

Yes it does, big thanks for the overview! We'll let you know (soon, I 
hope...)

Have a nice weekend,
Filip