Re: [eclipse-clp-users] need help on general problem solving approach

From: Kish Shen <kisshen_at_...5...>
Date: Fri, 02 Oct 2009 18:55:12 +0100
Oliver Scheickl wrote:

> Thanks to your help I can now start and interact with ECLiPSe from within
> Eclipse. As I am new to ECLiPSe and not really advanced in CLP in gerneral I
> want to ask you to comment on my general problem solving approach.
> I need to solve a kind of special scheduling problem. Actually, it is about
> distribution of time budgets across a system under certain conditions and
> rules to be met. I have a system model and some time budget information
> coming from Eclipse. In my understanding all this information is my
> knowledge base or my facts for problem solving. The rules that have to be
> considered during problem solving can directly be programmed in Prolog.
> I am asking myself now, how do I feed the facts to ECLiPSe, which are
> dynamically coming from Eclipse? My plan is to generate a Prolog file,
> representing all the facts, at runtime. I then call the .compile() method
> ans ask ECLiPSe to compile both the facts and the rules file. Then i call
> rpc() and ask ECLiPSe to find a solution by executing a predefined goal.
> Does this make sense? I could not yet find a similar example where I can
> learn from. The Embedding and Interfacing Manual provides examples using
> queues. But I dont think it makes sense to queue dozens of facts to ECLiPSe.
> Also it cannot really make sense to generate a huge String that is handed
> over using ECLiPSe`s .rpc() method.

Hi Oliver,

If I understood you correctly, you plan to write your general ECLiPSe 
program directly, and then pass the problem specific data via another 
ECLiPSe program that you generated from Java.

It is almost always a bad idea to try to generate an ECLiPSe program 
from Java, even if these are simple facts. The main problem is that you 
need to generate the correct syntax, and the differences between ECLiPSe 
and Java, even for such basic data type like strings, is going to be a 
source of error. The EXDR format provided by the interface is designed 
to avoid this problem.

If your data is sufficiently simple (simple enough to be converted to 
ECLiPSe facts), you are probably much better off to pass this data 
directly to ECLiPSe, and in your ECLiPSe program, convert this data to 
the form you need (e.g. constraints).

If you I/O model is as simple as you say, i.e. you have all the data you 
need when you run the query, and you are only interested in the result 
from the query, then you can pass the data via arguments of your RPC 
goal. [The data queues is designed for more complex interaction between 
your Java and ECLiPSe code]

 From what you described, I do think that using the OutOfProcess ECLiPSe 
engine is better than the embedded ECLiPSe, as Joachim suggested.


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.
Received on Fri Oct 02 2009 - 17:58:30 CEST

This archive was generated by hypermail 2.3.0 : Sat Aug 24 2019 - 06:15:04 CEST