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