[gecode-users] Interfacing GeCode to ECLiPSe
tack at ps.uni-sb.de
Mon Jan 26 19:26:46 CET 2009
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,
> 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
> 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
> 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
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.
More information about the gecode-users