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.
Q1. Is it JESS or the others not implementing a true RETE/CLIPS implementation
of their respective rule engines?
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?
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.
[EMAIL PROTECTED] (friedman_hill ernest j) on 04/26/2001 10:41:16 AM
To: Vicken Kasparian/SAR/Global@Global
cc: [EMAIL PROTECTED]
Subject: Re: JESS: Rule Firing
First, as to why the delay makes a difference: Jess shouldn't
care. The propertyChange method that gets invoked when the bean fires
a PropertyChangeEvent is synchronized, so calls to it should be
executed in order, without being dropped, even if properties arebeing
changed rapidly from multiple threads. My only guess is that perhaps
the ct_device Bean coalesces PropertyChangeEvents. I've never done
this, but you could imagine a Bean that sets a timer whenever a
property is changed, and combines successive change events if a second
one occurs within some short time interval. This would be efficient
and convenient in some cases. Anyway, a PropertyChangeEvent can have
"null" for the property name, in which case Jess scans all the
properties to learn which ones have changed, and makes all the
modifications to the shadow fact simultaneously. So if in your first
case, the events were not being coalesced by the Bean, and in the
second they were, this is precisely how I would expect Jess to behave.
Now, as to the double firings when you only want one: Beans are really
just like any other facts. Each property is a slot. If, in the
rule below, ct_device was a regular unordered fact, then modifying
either the source or the id would cause the rule to fire, and it's no
different for Beans.
There are several ways to achieve the effect you want; one simple one
looks something like this:
(defrule rule-4
(device (id ?i) (source ?s) (OBJECT ?o))
(not (seen ?s ?i ?o))
(test (neq ?i -1))
=>
(printout t "(test.clp rule-4) Source= " ?s ", Id= " ?i crlf)
(assert (seen ?s ?i ?o)))
Again, no different than how normal facts behave.
I think [EMAIL PROTECTED] wrote:
>
>
>
> I have a Java object ct_device. ct_object has a Source and Id properties. I
want
> a rule to fire when I upgrade the objects Id property.
>
> The following is my rule:
> (defclass device ct_device)
> (defrule rule-4
> (device (id ?i) (source ?s))
> (test (neq ?i -1))
> =>
> (printout t "(test.clp rule-4) Source= " ?s ", Id= " ?i crlf)
>
> The following is my Java Code where I set values for Id and Source. Note that
I
> have a one second delay between the two sets.
> ct_device[] d= new ct_device[n];
> for (int i= 1; i <= n-1; i++){
> d[i].setId(i);
> try { Thread.sleep(1000); } catch (InterruptedException ie) {
break;
> }
> d[i].setSource("Device" + i);
> }
>
> The above rule fires twice for each object. Once when I set the Id value, and
> once when setting the Source property value.
> Below is a sample output.
> SetId: 1
> (test.clp rule-4) Source= default, Id= 1
> SetSource: Device1
> (test.clp rule-4) Source= Device1, Id= 1
> SetId: 2
> (test.clp rule-4) Source= default, Id= 2
> SetSource: Device2
> (test.clp rule-4) Source= Device2, Id= 2
>
> Now, when I remove the one second wait between the two set property values,
> i.e.,
> ct_device[] d= new ct_device[n];
> for (int i= 1; i <= n-1; i++){
> d[i].setId(i);
> d[i].setSource("Device" + i);
> }the rule only fires once for the combined sets. Below is a sample of
> the output.
>
> SetId: 1
> SetSource: Device1
> (test.clp rule-4) Source= Device1, Id= 1
> SetId: 2
> SetSource: Device2
> (test.clp rule-4) Source= Device2, Id= 2
> SetId: 3
> SetSource: Device3
>
> Can any one explain the observed behavior.
> In case 1, why is the rule firing when I do a set on the Source property? It
> seems that the rule is firing when I do a set on any of the ct_device object's
> property as long as Id neq -1 !!
> If the output from case 1 is a normal behavior, then, why is it that in case 2
> when both Id and Source properties are set with no delays between them, I only
> get one firing of the rule?
>
> By the way, I am using Jess 60a5 with JDK1.3
>
> Thanks in advance,
>
> Regards,
> ___________________________
> Vicken Kasparian
> A C T E R N A
> Voice: 941.756.6000 x3550
> mailto: [EMAIL PROTECTED]
> http://www.acterna.com/
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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]
> ---------------------------------------------------------------------
>
---------------------------------------------------------
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]
---------------------------------------------------------------------
