[gecode-users] Interfacing GeCode to ECLiPSe
Christian Schulte
cschulte at kth.se
Tue Jan 27 19:33:01 CET 2009
Hi Kish,
Creating as many choicepoints (or considering anything as a choicepoint) is
fine. No problems.
Then, all the stuff can be done with Gecode's API. So, when I talk about
shipping it with Gecode it will be one module that comes with Gecode as an
example interface. There is definitely no need for hacking inside Gecode's
guts for doing this.
Then the only thing that worries me is "Eclipse semantics requires that
constraints are immediately propagated". That you can of course do as well
(however it is a real performance killer. I luckily forgot about this major
flaw in CLP ;-) )
As it comes to licensing. MIT is as liberal as is gets, so no problem:
according to your license and the MIT license you can include all of Gecode
into Eclipse. The only thing interesting is that we keep and maintain one
part that's Gecode specific and you keep and maintain the Eclipse specific
part. That will require a little bit of bargaining ;-)
Christian
--
Christian Schulte, www.it.kth.se/~cschulte/
-----Original Message-----
From: Kish Shen [mailto:kisshen at cisco.com]
Sent: Tuesday, January 27, 2009 5:11 PM
To: Christian Schulte
Cc: 'Guido Tack'; users at gecode.org
Subject: Re: [gecode-users] Interfacing GeCode to ECLiPSe
Hi Christian and Guido,
Thanks for your replies!
Christian Schulte wrote:
> Hi Kish,
>
> As it comes to the search interface: I have been discussing with other
> LP-minded people and from these discussions I do recall the following
design
> outline:
>
> Search:
> (1) Eclipse tells Gecode to create a choicepoint
> (2) Eclipse tells Gecode to backtrack until the next choicepoint (or some
> choicepoint if you want it to be
> more powerful than that)
>
> Interfacing:
> (3) Eclipse tells Gecode about variable modifications
> (4) Eclipse tells Gecode to create new variables and propagators
> (5) Eclipse instructs Gecode to do propagation and queries Gecode about
> changes to variable domains
>
> Then, a starting point for implementing backtracking would be to just use
> cloning to make it work (that should be really use but inefficient). Then,
> in a second step one could use a hybrid of recomputation and cloning (just
> replay what has been done by (3) and (4) and redo propagation). For a
> realistic interface Gecode must use recomputation.
After Guido's last post, I remember some of our (you, Joachim Schimpf
and I) discussion about this during CP a couple of years ago.
My thinking is that for ECLiPSe (and I suspect for other Prolog-like
languages), it is difficult to be explicit about the creation of a
choicepoint, so potentially any changes ECLiPSe tells GeCode about
(poinys 3,4) are possible choicepoints.
After reading Guido's e-mail (but before seeing yours), I was thinking
of maintaining a chronological list of the `events' that are sent to
GeCode, with a counter incremented for each event. I think this
corresponds to the `choicepoint' you mentioned. So ECLiPSe can tell
GeCode to `backtrack' (or more properly recreate) the GeCode state when
counter = N.
Can this be done with GeCode with the existing API, without the ECLiPSe
side maintaining the list of events?
3) and 4) are needed for the backbox interface, because to keep close
ECLiPSe's native finite domain solvers' semantics, propagation happens
when a constraint is posted.
So if I use the Reflection interface, I need to be able to incrementally
add variables and propagators.
>
> I think this kind of interface would be quite useful also for other
> languages/systems based on backtracking. Provided that:
> - you come up with a naïve implementation that is not Eclipse specific
> (say, there will be one part that is Gecode specific and then a separate
> part that is Eclipse specific, and the Gecode part can be used without
> Eclipse)
> - you put the Gecode-specific part under the MIT license
>
From our perspective, we'd like the ECLiPSe interface to be as general
as possible, i.e. ideally we can plug in another constraint solver
engine other than GeCode with ease.
I think your points 1) and 2) are not solver specific, and indeed can be
used by
other backtracking languages. I guess this will be the `ECLiPSe
specific' part,
as well as the actual 'events' themselves -- ideally I'd like the events
to be non-GeCode specific.
Then there is the part of getting GeCode to recreate the state at a
choicepoint/counter. This is probably specific to GeCode (or at least a
recomputation system). As I asked earlier, can you do this with the
GeCode APU, and if not, should the code for this be put into GeCode,
rather than be on the `ECLiPSe side'?
ECLiPSe is now under a "Cisco style" Mozilla license (I am not a lawyer,
but I believe Cisco style means that Cisco was substituted for Mozilla
in the license, i.e. Cisco has the right to change the licensing terms
etc.). I guess the question of license will only kick in if some of the
GeCode specific code needs to be kept on the ECLiPSe side (i.e.
distributed as part of ECLiPSe). I don't know if the MIT license is
compatible with Mozilla license (i.e. can you have a distribution with
code that has both licenses). I do recall the lawyers telling me that
the Mozilla license is not compatible with GPL, and we had to remove
some GPL licensed code from the ECLiPSe distribution.
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.
More information about the gecode-users
mailing list