Re: Re: JESS: JESS vs. Prolog

2000-06-22 Thread Thomas . Barnekow


Hi!

Jess already offers single inheritence capabilities, e.g.,

(deftemplate being (slot name))
(deftemplate mortal extends being)
(deftemplate immmortal extends being)
(deftemplate monster extends mortal)
(deftemplate human extends mortal)
(deftemplate god extends immortal)

I've already had situations where multiple inheritence would have been very
useful. Imagine, for example, a set of Java interfaces (e.g., Publisher,
Subscriber, StateReader, StateWriter), each defining, among others, getter
and setter operations for Bean properties. When defining (defclass)es for
Java classes implementing more than one of these interfaces it would be
nice to be able to mirror the inheritance/implementation hierarchy. In that
case rules could be written to handle the aspects modeled by the interfaces
one by one.

Would it be very complex to add multiple inheritance to Jess?

Thomas



Dipl.-Inform. Thomas Barnekow
Fraunhofer IAO, Competence Center Software Technology
   
 mail:   Nobelstraße 12, D-70569 Stuttgart,
 Germany   
   
 phone:  +49 (0) 711 / 970 - 2346  
   
 fax:+49 (0) 711 / 970 - 2300  
   
 mobile: +49 (0) 172 / 7126018 
   
 email:  [EMAIL PROTECTED]
   
 web:http://www.swt.iao.fhg.de 
   




-
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
-




Re: Re: JESS: JESS vs. Prolog

2000-06-22 Thread ejfried

I think [EMAIL PROTECTED] wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
 
 Hi!
 
 Jess already offers single inheritence capabilities [.]
 I've already had situations where multiple inheritence would have been very
 useful. Imagine, for example, a set of Java interfaces (e.g., Publisher,
 Subscriber, StateReader, StateWriter), each defining, among others, getter
 and setter operations for Bean properties. When defining (defclass)es for
 Java classes implementing more than one of these interfaces it would be
 nice to be able to mirror the inheritance/implementation hierarchy. In that
 case rules could be written to handle the aspects modeled by the interfaces
 one by one.
 
 Would it be very complex to add multiple inheritance to Jess?
 
 Thomas


It would not be terribly complex, but I believe it would entail a
noticeable performance hit. Right now slot names are turned into
absolute slot indexes when rules are compiled. Then to evaluate a
Rete-network test, a node just needs to fetch the Value within a Fact
at a specific numeric offset. This only works with single
inheritance. Child classes just extend the range of offsets, but the
inherited slots are at the same offsets as they are in the parent
class.

Now, to do multiple inheritance, you've got to do something like what
C++ does, which involves more some runtime lookup. Each fact would
need to contain pointers to one or more "vtables," one for each
inherited interface. The vtable entries would match offsets within a
base type to offsets within a child type. With some careful
programming, I think you could avoid doing any runtime slot-name
lookup; but still the pointer-chasing and record-keeping overhead
would both have a noticeable impact.

So although the usefulness of this seems apparent even to me,
implementing it is not a high priority. It would strongly violate the
"only pay for what you use" philosophy I've tried to adhere to in
designing Jess.


-
Ernest Friedman-Hill  
Distributed Systems ResearchPhone: (925) 294-2154
Sandia National LabsFAX:   (925) 294-2234
Org. 8920, MS 9012  [EMAIL PROTECTED]
PO Box 969  http://herzberg.ca.sandia.gov
Livermore, CA 94550
-
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
-




JESS: JESS vs. Prolog

2000-06-22 Thread Sebastian Varges

Hi Chuck,

let me just point out a few differences and commonalities between
Prolog and Jess:

1) Search strategies: Although Prolog uses backtracking (which forgets
intermediate results) and backward chaining, you can implement
meta-interpreters in Prolog easily. This means that your program can
work in a data-driven forward-chaining way and memorize intermediate
computations just like Jess does. However, I suspect that asserting
and retracting facts in Jess is more efficient than in many Prologs.

2) The Rete algorithm makes a real difference when you have a large
number of rules, possibly with similar LHSs. Prolog cannot offer
anything similar (although one could implement a Rete algorithm in
Prolog, again as a meta-interpreter). So the lack of an efficient rule
(clause) mechanism is clearly a disadvantage of Prolog.

3) On the other hand, there is the definition of term 'matching': in
Prolog the unification operation is used to match queries against
clauses, whereas Jess requires exact matching of KB facts (or fact
slots) and rule LHSs.  Unification is quite a powerful operation which
allows one to check the compatibility of highly structured
representations but it has its computational price. With unification
you can keep the number of rules small by stating rather general
clauses (rules). At the beginning I found it quite irritating that I
couldn't straightforwardly express recursive structures in Jess and
match them on rule LHSs.

4) And, last not least, there is of course the integration of Jess and
Java which was the initial motivation for me to use Jess.

As has been said before, it depends on the application which language
is more suitable.

-- Sebastian

*  *
* Sebastian Varges

* Language Technology Group  ICCS
* Division of Informatics
* University of Edinburgh
* 2 Buccleuch Place
* Edinburgh
* EH8 9LW 
* Scotland, UK

* email: [EMAIL PROTECTED]
* http://www.cogsci.ed.ac.uk/~varges/
* phone: (0044/0)-131-6504453
*  * 





-
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
-




RE: JESS: JESS vs. Prolog

2000-06-21 Thread Agustin Gonzalez

Hi Chuck,
You bring very good points to the table. The need to assert new facts comes
about because the matching algorithm, RETE, needs the new facts, as you
point out, to figure out if new rules need to fire.

But in a way the comparison is not fair. Because you can get the same effect
as in prolog (display) just by printing "mortal ?x" (again the syntax is not
correct) in the head of the defrule.

However, if you need to use the mortal(?x) fact in other rules you need to
assert
it. Similar thing in prolog. If it needed mortal(x) because it's used in
another rule it would need to create a "temporary" fact to be able to fire
the rule.

I guess what bothers you, and that's a very good point, is that in RETE
intensional facts (i.e. those that only appear in heads of rules)
remain after they are asserted and not removed from the RETE net.

 --
Agustin Gonzalez
Staff Software Engineer
LiveMedia, Inc.
(512) 248-9839


 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
 Behalf Of [EMAIL PROTECTED]
 Sent: Wednesday, June 21, 2000 9:50 AM
 To: [EMAIL PROTECTED]
 Subject: JESS: JESS vs. Prolog




 Please forgive me if this is a misguided missive.  I am trying to
 understand how
 to use a rule based system, and as such I am sure I am operating
 under many
 misunderstandings and misconceptions.  I am trying to clear them
 up, and I would
 appreciate any corrections to my thoughts below.

 I have played around a bit with Prolog.  As a basic example, I
 understand if I
 have these facts and rules:

  human(Socrates)
  mortal(X) :- human(X)

 Then, I can ask the Prolog engine is Socrates mortal by stating
 "mortal(Socrates)" at the engine prompt, and it will respond with
 "yes".  I can
 also ask it for all the known mortals with the statement
 "mortal(X)", and it
 will respond with "Socrates".

 I was then thinking how I would do this using Jess.  I believe I
 would use the
 deffact of

  (deffact myfacts (human Socrates))

 and the defrule of

  (defrule universal-truth  ((human ?x) = (assert (mortal ?x

 To find all the mortals, I can define a defquery

   (defquery all-mortals  (mortals ?x))

 (Sorry, the syntax may be a bit off.  I'm not too worried about
 that.  I don't
 necessarily need responses correcting that.  That's easy to fix
 and understand.
 It's the concepts that I'm trying to address.)

 Then, do a (reset) and a (run).

 Then execute the defquery with the statement

  (bind ?e (run-query all-mortal))

 and use an iteration of ?e to get all the results.  (The Jess
 Language manual
 has an example.)

 I believe this is the only way to get a similiar functionality to
 the Prolog
 query "mortal(X)".

 If that is true, what troubles me about it is the defrule.  It
 basically adds
 new facts to the set of facts.  What this means to me is if I
 have a set of 100
 "human" facts, after I do the (reset), I now have an additional
 100 "mortal"
 facts, doubling the number of facts.  And if I have some other rule about
 humans, it would also add another 100 facts.

 This may be considered a feature (because when the new facts are
 asserted, it
 may cause other rules to fire), or it may be just a result of the
 implementation.  But, also, In some ways (from one particular
 angle of view),
 these asserted facts can be considered "pollution"
 1.  They take up space.
 2.  They take up time to generate.
 3.  If I remove a human fact, the corresponding mortal fact
 remains.  I have to
 specifically perform extra steps to get rid of it.

 In the Prolog implementation, issues 3 is not an issue.  There
 can be a minor
 argument about whether Prolog has issues 1 and 2, but definitely,
 Prolog will
 not multiply the number of facts by the number of rules like Jess does.

 So is there a way to express relationships between facts (ie if X
 is human, then
 X is also mortal) without having the relationship specifically
 stated as a fact
 for each candidate of the relationship (ie "(human Socrates)", "(mortal
 Socrates)", "(human Chuck)", "(mortal Chuck)", etc.)?

 Chuck Sterbis
 Senior Programmer/Analyst
  Denniston  Denniston, Inc.











 -
 To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
 in the BODY of a message to [EMAIL PROTECTED], NOT to the
 list (use your own address!) List problems? Notify
 [EMAIL PROTECTED]
 -




-
To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
in the BODY of a message to [EMAIL PROTECTED], NOT to the
list (use your own address!) List problems? Notify [EMAIL PROTECTED]
-




FW: JESS: JESS vs. Prolog

2000-06-21 Thread Agustin Gonzalez

A correction:
An intensional fact are those facts that appear in heads of rules (but they
may
also appear in bodies).

 -Original Message-
 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
 Behalf Of Agustin Gonzalez
 Sent: Wednesday, June 21, 2000 10:39 AM
 To: [EMAIL PROTECTED]
 Subject: RE: JESS: JESS vs. Prolog


 Hi Chuck,
 You bring very good points to the table. The need to assert new
 facts comes
 about because the matching algorithm, RETE, needs the new facts, as you
 point out, to figure out if new rules need to fire.

 But in a way the comparison is not fair. Because you can get the
 same effect
 as in prolog (display) just by printing "mortal ?x" (again the
 syntax is not
 correct) in the head of the defrule.

 However, if you need to use the mortal(?x) fact in other rules you need to
 assert
 it. Similar thing in prolog. If it needed mortal(x) because it's used in
 another rule it would need to create a "temporary" fact to be able to fire
 the rule.

 I guess what bothers you, and that's a very good point, is that in RETE
 intensional facts (i.e. those that only appear in heads of rules)
 remain after they are asserted and not removed from the RETE net.

  --
 Agustin Gonzalez
 Staff Software Engineer
 LiveMedia, Inc.
 (512) 248-9839


  -Original Message-
  From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
  Behalf Of [EMAIL PROTECTED]
  Sent: Wednesday, June 21, 2000 9:50 AM
  To: [EMAIL PROTECTED]
  Subject: JESS: JESS vs. Prolog
 
 
 
 
  Please forgive me if this is a misguided missive.  I am trying to
  understand how
  to use a rule based system, and as such I am sure I am operating
  under many
  misunderstandings and misconceptions.  I am trying to clear them
  up, and I would
  appreciate any corrections to my thoughts below.
 
  I have played around a bit with Prolog.  As a basic example, I
  understand if I
  have these facts and rules:
 
   human(Socrates)
   mortal(X) :- human(X)
 
  Then, I can ask the Prolog engine is Socrates mortal by stating
  "mortal(Socrates)" at the engine prompt, and it will respond with
  "yes".  I can
  also ask it for all the known mortals with the statement
  "mortal(X)", and it
  will respond with "Socrates".
 
  I was then thinking how I would do this using Jess.  I believe I
  would use the
  deffact of
 
   (deffact myfacts (human Socrates))
 
  and the defrule of
 
   (defrule universal-truth  ((human ?x) = (assert (mortal ?x
 
  To find all the mortals, I can define a defquery
 
(defquery all-mortals  (mortals ?x))
 
  (Sorry, the syntax may be a bit off.  I'm not too worried about
  that.  I don't
  necessarily need responses correcting that.  That's easy to fix
  and understand.
  It's the concepts that I'm trying to address.)
 
  Then, do a (reset) and a (run).
 
  Then execute the defquery with the statement
 
   (bind ?e (run-query all-mortal))
 
  and use an iteration of ?e to get all the results.  (The Jess
  Language manual
  has an example.)
 
  I believe this is the only way to get a similiar functionality to
  the Prolog
  query "mortal(X)".
 
  If that is true, what troubles me about it is the defrule.  It
  basically adds
  new facts to the set of facts.  What this means to me is if I
  have a set of 100
  "human" facts, after I do the (reset), I now have an additional
  100 "mortal"
  facts, doubling the number of facts.  And if I have some other
 rule about
  humans, it would also add another 100 facts.
 
  This may be considered a feature (because when the new facts are
  asserted, it
  may cause other rules to fire), or it may be just a result of the
  implementation.  But, also, In some ways (from one particular
  angle of view),
  these asserted facts can be considered "pollution"
  1.  They take up space.
  2.  They take up time to generate.
  3.  If I remove a human fact, the corresponding mortal fact
  remains.  I have to
  specifically perform extra steps to get rid of it.
 
  In the Prolog implementation, issues 3 is not an issue.  There
  can be a minor
  argument about whether Prolog has issues 1 and 2, but definitely,
  Prolog will
  not multiply the number of facts by the number of rules like Jess does.
 
  So is there a way to express relationships between facts (ie if X
  is human, then
  X is also mortal) without having the relationship specifically
  stated as a fact
  for each candidate of the relationship (ie "(human Socrates)", "(mortal
  Socrates)", "(human Chuck)", "(mortal Chuck)", etc.)?
 
  Chuck Sterbis
  Senior Programmer/Analyst
   Denniston  Denniston, Inc.
 
 
 
 
 
 
 
 
 
 
 
  -
  To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PRO

Re: JESS: JESS vs. Prolog

2000-06-21 Thread ejfried

Hi Chuck,

As in all pursuits, you should choose the right tool for the
right job. Prolog and a Rete-based system like Jess are very
different.  The central concept in Prolog is backwards chaining: given
the rules human(Socrates) and mortal(X) :- human(X), you might be
interested in knowing mortal(Socrates). Prolog uses the rules to find
it by looking for human(Socrates). Note that if you "forget" this and
ask for it again, Prolog has to compute it again.

The central concept in Jess, though, is forwards chaining. Here, you
have (human Socrates) and (defrule mortal (human ?X) = (assert
(mortal ?X))). You don't want to know (mortal Socrates), but rather
you want to know what happens given that (human Socrates) is
known. (mortal Socrates) is a result. After the rule has fired,
(mortal Socrates) is known, and the rule "mortal" never has to assert
this fact again.

One more difference is that Prolog is really meant to be used from the
console; i.e., you're actually supposed to sit down and type
"mortal(Socrates)." In Jess, only developers do this; the command line
is not intended for end-users. Prolog is really about answering queries,
while Jess is about acting in response to inputs.

Jess is different than some Rete-based systems in that it includes
both a kind of backwards chaining (see manual section 2.8.1.9) and a
construct called a "defquery" which you've already discovered. Both of
these help Jess a better fit for Prolog applications, but they don't
make Jess into a Prolog-like system. Prolog is optimized, in a sense,
for space, at the cost of speed. Jess (and its Rete algorithm) is
optimized for speed at the cost of space. The Rete algorithm is all
about computing things -once- so they never need to be
recomputed. Prolog approach is more interested in exploring large
numbers of possibilities once, while Rete is aimed at exploring
medium-sized number of possibilities repeatedly.

Regarding ways to express relationships: Jess offers a rich set of
possiblities. Here's one in which the mortality is encoded directly
into the facts, so it never needs to be computed at all:

(deftemplate being (slot name))
(deftemplate mortal extends being)
(deftemplate immmortal extends being)
(deftemplate monster extends mortal)
(deftemplate human extends mortal)
(deftemplate god extends immortal)

(defrule list-all-humanoids
  ;; fire for all beings, gods, monsters, and humans
  (being (name ?n))
  =
  (printout  ?n " is a being " crlf))

(defrule list-all-mortals
  ;; fires only for mortal things  
  (mortal (name ?n))
  =
  (printout  ?n " is mortal " crlf))

Here's another that's closer in spirit to the Prolog example.

(deftemplate thing (slot type) (slot name))

(deffacts things
  (thing (type human) (name Socrates))
  (thing (type mineral) (name Slate))
  (thing (type vegetable) (name Carrot))
  (thing (type dog) (name Rover))
  (thing (type human) (name Bob)))

(deffacts mortality
  (mortal human)
  (mortal dog))

(defrule list-all-mortals
  ;; fires for dogs and humans
  (mortal ?type)
  (thing (type ?type) (name ?n))   
  =
  (printout t ?n " is mortal." crlf))  

So there's one fact that expresses that humans are mortal, and one for
each human known. No "extra" facts are generated. Nevertheless, the
mortality of Socrates is remembered and may be used to optimize some
later computation.

Hope this helps.

I think [EMAIL PROTECTED] wrote:
 
 
 Please forgive me if this is a misguided missive.  I am trying to understand how
 to use a rule based system, and as such I am sure I am operating under many
 misunderstandings and misconceptions.  I am trying to clear them up, and I would
 appreciate any corrections to my thoughts below.
 
 I have played around a bit with Prolog.  As a basic example, I understand if I
 have these facts and rules:
 
  human(Socrates)
  mortal(X) :- human(X)
 
 Then, I can ask the Prolog engine is Socrates mortal by stating
 "mortal(Socrates)" at the engine prompt, and it will respond with "yes".  I can
 also ask it for all the known mortals with the statement "mortal(X)", and it
 will respond with "Socrates".
 
 I was then thinking how I would do this using Jess.  I believe I would use the
 deffact of
 
  (deffact myfacts (human Socrates))
 
 and the defrule of
 
  (defrule universal-truth  ((human ?x) = (assert (mortal ?x
 
 To find all the mortals, I can define a defquery
 
   (defquery all-mortals  (mortals ?x))
 
 (Sorry, the syntax may be a bit off.  I'm not too worried about that.  I don't
 necessarily need responses correcting that.  That's easy to fix and understand.
 It's the concepts that I'm trying to address.)
 
 Then, do a (reset) and a (run).
 
 Then execute the defquery with the statement
 
  (bind ?e (run-query all-mortal))
 
 and use an iteration of ?e to get all the results.  (The Jess Language manual
 has an example.)
 
 I believe this is the only way to get a similiar functionality to the Prolog
 query "mortal(X)".
 
 If that is