[ajs2@tempest.icparc.ic.ac.uk: Re: AW: Getting results form ECLiPSe with java]

From: Andrew John Sadler <ajs2_at_icparc.ic.ac.uk>
Date: Fri 06 Dec 2002 01:58:11 PM GMT
Message-Id: <E18KIzb-0000Hu-00@tempest.icparc.ic.ac.uk>
Sorry for the duplicate mail Cornelius, I forgot tot CC: eclipse-users.

------- Start of forwarded message -------
Date: 6 Dec 2002 13:42:26 +0000
From: Andrew John Sadler <ajs2@tempest.icparc.ic.ac.uk>
To: cornelius.hagen@wiai.uni-bamberg.de
In-reply-to: <000001c29d1b$77bfede0$c3020d8d@LEIHNOTEBOOK43>
	(cornelius.hagen@wiai.uni-bamberg.de)
Subject: Re: AW: [eclipse-users] Getting results form ECLiPSe with java

> Envelope-to: ajs2@icparc.ic.ac.uk
> Delivery-date: Fri, 6 Dec 2002 11:38:10 +0000
> From: "Cornelius Hagen" <cornelius.hagen@wiai.uni-bamberg.de>
> Date: Fri, 6 Dec 2002 12:34:41 +0100
> Content-Type: text/plain;
> 	charset="iso-8859-1"
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
> 
> Dear Andrew,
> 
> Thank you for replying so promptly. Maybe I am a little dull-witted, but
> I am not shure if I got your mail right:
> 
> I actually used the queues in my sample code. To find the mistake,
> should I look at my java-code again or shoud I modify the
> constraint-modeling, i.e. the file to be compiled or the argument for
> the rpc-function?
> 

Hello Cornelius,

It seems I misunderstood your email.  If you have the same queues as
setup in the map coloring demo then you should perform a read on the
'continue' queue once a solution has been found. eg...

diffElements( X, Y, Z, A ) :-
  X ::[r,g], Y::[g,b], Z::[r,b], A::[r,b,g,l], X##Y, Y##Z, X##Z, 
  labeling([X,Y,Z,A]).
  % ask external side if another solution is required
  read_exdr(continue, Continue),
  Continue == no, !. /* otherwise fail back and get next solution */
diffElements( _X, _Y, _Z, _A ).

On the Java side you should have a listener attached to the 'continue'
queue which will be triggered when the ECLiPSe side performs the read.
Essentialy telling you that a solution has been found, writing the
atom 'yes' (or infact anything apart from the atom 'no') will then
cause your diffElements/4 predicate (which is still "running" as a
result of your rpc()) to try another labeling.

Note, that inorder to actualy recieve the values of your problem
variables (X,Y,Z,A is assume) you will need to explicitly send them to
Java by writing them onto another queue. eg...

diffElements( X, Y, Z, A ) :-
  X ::[r,g], Y::[g,b], Z::[r,b], A::[r,b,g,l], X##Y, Y##Z, X##Z, 
  labeling([X,Y,Z,A]).
  % send the variable's values over to Java on a queue called 'solution'
  write_exdr(solution,[X,Y,Z,A]),
  % ask external side if another solution is required
  read_exdr(continue, Continue),
  Continue == no, !. /* otherwise fail back and get next solution */
diffElements( _X, _Y, _Z, _A ).

Note that this will require you to have set up a queue called
'solution' as a FromEclipseQueue, in much the same way that
'update_map' queue is setup in the map coloring example.

Then you can read off the values for each solution as it is found, and
write a 'yes' atom onto the 'continue' queue if you want another.

So to conclude and actualy answer your question. Your constraint model
is fine, but you need to add some explicit control and communication
calls to get the desired results.

Let me know if that works for you, or if I can explain any bits.

Andrew

PS.  It's just occured to me that I should perhaps point out that the
goal you are calling on the ECLiPSe side via your rpc() will only
return the last solution in its argument variables, when the rpc
finally terminates (ie when you send 'no' down the 'continue' queue,
which will cause the diffElements/4 goal to fail without leaving
choice points (because of the (!) cut), this will then return the
final values).

> Many thanks
> 
> Cornelius
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Andrew John Sadler [mailto:ajs2@icparc.ic.ac.uk] 
> Gesendet: Freitag, 6. Dezember 2002 12:16
> An: cornelius.hagen@wiai.uni-bamberg.de
> Cc: eclipse-users@icparc.ic.ac.uk
> Betreff: Re: [eclipse-users] Getting results form ECLiPSe with java
> 
> 
> > Hello,
> >  
> > I am just doing my first steps with ECLiPSe and its Java-API.
> >  
> > I want to solve csps with many solutions and get one by one (do not 
> > want to use find_all...). The mapcolour-Example does exactly this. So 
> > I stripped down the java code to fit it to a simple sample problem.
> >  
> >  I used a file with the following content:
> >  
> > :- lib(fd).
> >  
> > diffElements( X, Y, Z, A ) :-
> > X ::[r,g], Y::[g,b], Z::[r,b], A::[r,b,g,l], X##Y, Y##Z, X##Z, 
> > labeling([X,Y,Z,A]).
> >  
> > and passed as argument to the method "rpc" the term "diffElements( X, 
> > Y, Z, A )" as String.
> >  
> > I get the first solution, but that's it. The program never uses one of
> 
> > the Queues (I set breakpoints there. In the original sample they were 
> > hit.).
> 
> Ah. No Queues. That'll be your problem then :)
> 
> In the Embedding and Interfacing manual (page 63, section 7.4.3) the
> behaviour of the rpc() call is discussed.  In particular it states that
> non-deterministic goals (ones with potentialy more than one
> solution) will only succeed once only.  Any choice points which remain
> after the first solution is found are ignored.  Hence the behaviour you
> are seeing.
> 
> The map coloring example shows how you can set about obtaining more than
> one result from non-deterministic rpcs.  ie. by using those pesky Queues
> :)
> 
> --snip--
> > Now my question:
> > * Did I pass a wrong argument an incorrect file to compile?
> 
> no.
> 
> > * Is there more detailed information about the Java interface than in 
> > the "Embedding and Interfacing Manual" and the 
> > javadoc\JavaEclipseInterface-HTML-documentation?
> 
> No, but see above comments (page 63, section 7.4.3 "More details about
> rpc goal execution")
> 
> >  
> > Many thanks in advance
> >  
> > Cornelius Hagen
> > 
> 
> Hope that helps
> 
> Andrew Sadler
> 
> 
------- End of forwarded message -------
Received on Fri Dec 06 13:58:47 2002

This archive was generated by hypermail 2.1.8 : Wed 16 Nov 2005 06:07:19 PM GMT GMT