[gecode-users] Interfacing GeCode to ECLiPSe

[Guido Tack]

Kish Shen wrote:

> I am not sure what are the trade-offs between the two APIs Guido
> outlined -- is it simply that using reflection will be less flexible?

In a way, it's more flexible.  All constraints and variable types  
available in Gecode will be automatically available through the  
interface.  When constraints or variable types are added to Gecode,  
they are available without changing the interface code (and maybe even  
without recompiling the interface).

> I am not very familiar with interface generators like SWIG, although I
> did take a look at it briefly several years ago, and my impression was
> that it mainly serve to map the data structures between C/C++ and the
> target language. In ECLiPSe's interface to MP solvers such as CPLEX,  
> we
> needed to do quite a lot of extra coding in C, in addition to the data
> transformation between C and ECLiPSe, and I suspect we might require
> such extra coding for the interface to GeCode as well. In  
> particular, I
> don't expect a direct mapping from ECLiPSe to the GeCode methods at  
> the
> ECLiPSe level.

Yes, that's how they work.  For our Java interface (which is generated  
by swig), we had to write quite some glue code, too.

> I expect that at the ECLiPSe level, we will use syntax that looks a  
> lot
> like the existing syntacx for the native solvers. I expect that at a
> minimum, we would need to be able to add both constraints and  
> variables
> dynamically.

Sure, that shouldn't be a problem.  Gecode is quite dynamic anyway, it  
would be an artificial restriction to make this static.

> In the backbox search approach, I think we will also need
> to be able to be able to `backtrack' into the search to obtain further
> solutions after the initially one.

The other interfaces usually solve this by providing an object that  
represents the search, and which has a "next" method that you can call  
as often as there are solutions.  I guess you could provide a similar  
interface in Eclipse.

> In the case where the search is done
> by ECLiPSe, my initial thought is that we need to do only the
> propagation in GeCode, but do the search in ECLiPSe. This would mean
> that we need someway of `undoing' the effects of a propagation step,
> without directly using the search/branching facilities of GeCode.

Right.  But Gecode does not provide a mechanism for undoing these  
effects. You can only keep a copy of a space and then redo the effects  
instead.  But this can be hidden behind some layer of abstraction.

> Do you
> expect that I can use Reflection API for both the black-box and the
> ECLiPSe search approach?

Yes.  As reflection will only be used to set up the initial space, it  
should work with both approaches.

Cheers,
	Guido