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

Hi again,

Ok I think I follow Kish's advice not to generate the code, although  
in other projects this approach seems to work.

My facts data is quite simple I guess. However, it may be a lot of it.  
Doesn't passing the data via arguments of the rpc goal also mean to  
generate a huge Java string? I think I will again study the examples  
in the manual :-)

Thank you again,
	Oliver.

On Oct 2, 2009, at 7:55 PM, Kish Shen wrote:

> 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.
>
> 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.