I think [EMAIL PROTECTED] wrote:
>
>
> Ernest:
>
> Thanks for your reply. Your work around for the double rule firing worked, i.e.,
> (not (seen ?s ?i ?o) & (assert (seen ?s ?i ?o)).
> I did some reading abou the rete algorithm and still don't understand why
> asserting or modifying the source attribute makes the rule fire. The rule is
> only doing a test on the id attribute.
>
> I have prototyped other rule engines (OPSJ and Gensym's G2) and have found
> differences in rule execution. The other rule engines only fire rules when the
> attributes in question are asserted or modified. For example if I have an object
> OBJ1 with attributes ATTR1 and ATTR2. If I have a rule that satisfies a
> condition on ATTR1, changing ATTR2 does not make the rule fire.
Well, you've named two systems that apparently behave the way you
expect, but there are at least two (Jess and CLIPS) that behave the
way Jess does. Witness:
CLIPS> (watch rules)
CLIPS> (deftemplate t (slot s1) (slot s2))
CLIPS> (deffacts facts (t (s1 1) (s2 2)))
CLIPS> (defrule r (t (s1 ?x)) => )
CLIPS> (reset)
CLIPS> (run)
FIRE 1 r: f-1
CLIPS> (modify 1 (s2 3))
<Fact-2>
CLIPS> (run)
FIRE 1 r: f-2
CLIPS>
>
> Q1. Is it JESS or the others not implementing a true RETE/CLIPS implementation
> of their respective rule engines?
There is no such thing as "a true RETE/CLIPS implementation." There is
only how individual systems behave. This is how Jess behaves. That
said, the other behaviour is interesting and potentially useful, and
I've begun to wonder how to implement it as an option in a compatible
way.
>
> Q2. In the examples showed below, I was executing the rules using the
> "run-until-halt" approach". I also tried putting the rete execute command in my
> objects set methods so that I ensure that every time I modify an object
> attribute, I run the rete execute command. Although not a very desirable way of
> executing the rules from a programming point of view (requires modifying managed
> objects), are there any performance tradeoffs between the continuous rete
> execution and the manual execution of the rete engine every time a change is
> made?
>
Well, obviously there's a certain amount of overhead due to entering
and exiting the run() loop, but nothing significant.
> My main concern with the run-until-halt approach is that it does not guarantee
> that a satisfied rule will fire every time the corresponding object attributes
> change very fast.
If every property change is individually significant, then yes, you'd
need to have the running thread and the property-change thread proceed
in lock-step, or be one and the same -- there's no way around that.
---------------------------------------------------------
Ernest Friedman-Hill
Distributed Systems Research Phone: (925) 294-2154
Sandia National Labs FAX: (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]
---------------------------------------------------------------------
