[gecode-users] ND constructs in scripts

[Filip Konvička]

Hi,
>> To be more specific, from
>> what I understand, such thing as "choice" could be done by cutting the
>> script at the points of nondeterministic statements, putting the
>> deterministic parts' bodies in the appropriate functions of some
>> branchings... (posting a new branching should be done in commit(),
>> right?). Is this correct?
>>     
>
> I'm not sure we use the same terminology here ;-)  A branching is
> something that is "installed" in a space, like a propagator, and which
> will be queried after propagation has finished to a) determine how many
> branches the space has and b) commit the space to one of these branches.
>   

Yes, I think I understand what a branching is in Gecode. The 
non-determinism I was interested in was a "choice"-like construct. I 
assumed that I could achieve that by posting a cascade of branchings. I 
thought I could install a new branching inside the preceding branching's 
commit function - so during batch recomputation, when only "b)" would 
occur, I would get all the branchings I need in a specific search tree node.

Also I don't think that those ND constructs are essential  - I grew used 
to them using Mozart, and I'm just curious about how to change my 
thinking when I switch to Gecode.

> Just as with propagators, you can write your own Gecode branchings by
> inheriting from the Branching class and implementing the necessary
> interface.  As all branches will be explored during search, this is a way
> of implementing non-determinism.
>   

I looked at some of the examples and I don't remember seeing one that 
would use more than one branching. That's why I'm asking these questions.

>> So my question for now is - do you have a suggestion on how
>> non-deterministic constructs could be done in scripts, if this can be
>> done at all?
>>     
>
> It really depends on what kind of non-determinism you want to implement. 
> We use branchings only for search in the context of finite domain
> constraint problems.  So if the non-determinism you have in mind is used
> to split a constraint problem into two or more simpler problems, this is
> the way to go.  I'm however not sure the abstractions we provide are the
> best choice for other kinds of non-determinism.
>   

Agreed, I didn't think much about other constructs. I'm happy that you 
generally agree that my thinking is correct in this specific case.

Guido, thanks for your answers, they helped!

As for the library itself, I very much like the design, the language 
used and the focus on efficiency. I know that your're probably working 
hard on getting version 2 out soon, nevertheless I hope that you publish 
some brief tutorial for newbies like me sometime soon :-)

Cheers,
Filip