[gecode-users] Interfacing GeCode to ECLiPSe

[Kish Shen]

Guido Tack wrote:
> Hi Kish.
> 
> Kish Shen wrote:
>> We have been thinking about developing an interface to GeCode for the
>> Constraint Logic Programming language ECLiPSe for a while now, and
>> finally I can devote some time and resource to this.
>>
>> The idea is to provide an alternative FD solver for ECLiPSe, in addition
>> to the existing native FD solver(s) already available.
>>
>> I have been looking at the available documentation, which seems to be
>> mostly documentation for the procedures. I am wondering if there are
>> more documentations available, especially for the purpose of interfacing
>> to other languages.
> 
> No, there's (currently) no such documentation.  Most of the interfaces 
> to Gecode use some kind of interface generator, like swig for the Java 
> interface, which basically takes the C++ header files and generates the 
> interfacing code.
> 
> However, interfacing is not so much different from programming models 
> directly in C++.  You have to provide ways to construct a space and 
> variables, and the post functions for constraints and branchings.
> 
> Alternatively, you can use the reflection API for interfacing (as done 
> in gecode/serialization/javascript.{hh,cpp} and 
> examples/javascript.cpp), which has the advantage that the necessary 
> interface is much smaller.
> 
>> What I would like to do is to provide both a black-box search, i.e.
>> with the constraints posted by ECLiPSe to GeCode, and then the GeCode
>> search invoked. Secondly, I would like to do the search in ECLiPSe, with
>> GeCode doing the propagation. Do you think these are sensible approaches?
> 
> Yes, that's should be doable.  In particular the black-box approach 
> should work easily.  The interaction with the ECLiPSe search should also 
> be doable, but requires a little more engineering, I guess.
> 
> Cheers,
>     Guido
> 
Hi Guido, Mauricio and Raffaele,

Thanks for your replies!

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?

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.

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. 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. 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. Do you 
expect that I can use Reflection API for both the black-box and the 
ECLiPSe search approach?

I have taken a brief look at the GeList wrapper that Mauricio posted 
about. I think this is not done using an interface generator, and does 
not use the Reflection mechanism. Am I correct?

If I understood Raffaele correctly, his interface generates a GeCode 
script (i.e a C++ program) from the model given in MiniZinc/SICStus,
and this C++ program is then run independently from the host language. I 
don't think this is the approach I am thinking of doing -- Instead we 
want GeCode to be run as part of an ECLiPSe execution.

Thanks and cheers,

Kish

-- 
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.