Re: JESS: [EXTERNAL] Jess asserts fact that is not true
On 26/06/2012, Dwight Hare d.h...@paritycomputing.com wrote: I am trying to reason about the passage of time in my rules. I would like to write the following rule: (defrule Test ?r - (logical (CurrentTime)) (logical (Condition (time ?time:( (+ ?time 5) ?r.t = (assert (Condition-met)) ) Where CurrentTime is a fact that holds the current time, and I change the slot value t as time progresses. The rule fires if the time slot in the Condition plus 5 is greater than the current time (that is, is true within the last 5 time increments). But this syntax is not allowed because you cannot access a dotted variable (the ?r.t) here. Why not simply (defrule Test (logical (CurrentTime ?ct)) (logical (Condition (time ?time:( (+ ?time 5) ?ct = (assert (Condition-met)) ) which avoids all that global rigmarole? More below. My first alternative was to declare a defglobal called *time* and have that change value as time progresses. But there is no way to make the global a logical dependency of the asserted condition-met so it doesn't get retracted when the global changes in value sufficient to make the rule no longer be true. I came up with a workaround where in addition to the defglobal *time* I assert a Fact called CurrentTime that holds the same value in the t slot. Now my rule is: (defrule Test ?r - (logical (CurrentTime (t ?t:(= ?t ?*time* (logical (Condition (time ?time:( (+ ?time 5) ?*time* ; Note I use the global here instead of the dotted var but the value is the same = (assert (Condition-met (globtime ?*time*)(facttime ?r.t))) ) The fallacy is buried in the second pattern which compares the (unchanged) Condition with the value in the global *time*. You know that this has changed, but the Jess Engine doesn't. It works in the first pattern because you change the CurrentTime fact, and so this pattern is re-evaluated. Don't use globals in LHS patterns unless they are immutable. -W This says that if there is a CurrentTime fact whose slot t has the same value as the global *time* and there is a Condition whose time slot plus 5 is greater than that time, then assert the Condition-met. My java code sets the global to 4, asserts the fact (CurrentTime (t 4)), and then asserts the fact (Condition (time 0)). Since all the conditions are met the rules engine asserts the fact (MAIN::Condition-met (globtime 4) (facttime 4)). All is well though a bit clumsy. Now I want to move time forward where the Condition-met should no longer be true. I change the global to 10 and modify the CurrentTime fact and set the t slot to 10 too. Then I run the rules engine and it retracts the (MAIN::Condition-met (globtime 4) (facttime 4)) but then mysteriously asserts (MAIN::Condition-met (globtime 10) (facttime 10)). Since the Condition time of 0 plus 5 is not greater than 10, it should not have asserted this. Here is a dump of the facts in the rules engine at the end: 0: (MAIN::CurrentTime (t 10)) 1: (MAIN::Condition (time 0)) 3: (MAIN::Condition-met (globtime 10) (facttime 10)) I see no justification for the 3rd fact given the only rule I have. Is there a better way of accomplishing this? Dwight To unsubscribe, send the words 'unsubscribe jess-users y...@address.com' in the BODY of a message to majord...@sandia.gov, NOT to the list (use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
RE: JESS: [EXTERNAL] Jess asserts fact that is not true
Duh. I had early on gotten into the habit of assigning the LHS clause to a variable (as I did below in ?r - ...) and then accessing the slots using dotted vars that I had completely forgotten this alternative way of assigning a slot value to a var in a rule. It works correctly now without the global and it retracts the fact when I change the value representing the current time. Apologies for wasting everyone's time with this stupid question. Dwight -Original Message- From: owner-jess-us...@sandia.gov [mailto:owner-jess-us...@sandia.gov] On Behalf Of Wolfgang Laun Sent: Tuesday, June 26, 2012 9:59 PM To: jess-users@sandia.gov Subject: Re: JESS: [EXTERNAL] Jess asserts fact that is not true On 26/06/2012, Dwight Hare d.h...@paritycomputing.com wrote: I am trying to reason about the passage of time in my rules. I would like to write the following rule: (defrule Test ?r - (logical (CurrentTime)) (logical (Condition (time ?time:( (+ ?time 5) ?r.t = (assert (Condition-met)) ) Where CurrentTime is a fact that holds the current time, and I change the slot value t as time progresses. The rule fires if the time slot in the Condition plus 5 is greater than the current time (that is, is true within the last 5 time increments). But this syntax is not allowed because you cannot access a dotted variable (the ?r.t) here. Why not simply (defrule Test (logical (CurrentTime ?ct)) (logical (Condition (time ?time:( (+ ?time 5) ?ct = (assert (Condition-met)) ) which avoids all that global rigmarole? More below. My first alternative was to declare a defglobal called *time* and have that change value as time progresses. But there is no way to make the global a logical dependency of the asserted condition-met so it doesn't get retracted when the global changes in value sufficient to make the rule no longer be true. I came up with a workaround where in addition to the defglobal *time* I assert a Fact called CurrentTime that holds the same value in the t slot. Now my rule is: (defrule Test ?r - (logical (CurrentTime (t ?t:(= ?t ?*time* (logical (Condition (time ?time:( (+ ?time 5) ?*time* ; Note I use the global here instead of the dotted var but the value is the same = (assert (Condition-met (globtime ?*time*)(facttime ?r.t))) ) The fallacy is buried in the second pattern which compares the (unchanged) Condition with the value in the global *time*. You know that this has changed, but the Jess Engine doesn't. It works in the first pattern because you change the CurrentTime fact, and so this pattern is re-evaluated. Don't use globals in LHS patterns unless they are immutable. -W This says that if there is a CurrentTime fact whose slot t has the same value as the global *time* and there is a Condition whose time slot plus 5 is greater than that time, then assert the Condition-met. My java code sets the global to 4, asserts the fact (CurrentTime (t 4)), and then asserts the fact (Condition (time 0)). Since all the conditions are met the rules engine asserts the fact (MAIN::Condition-met (globtime 4) (facttime 4)). All is well though a bit clumsy. Now I want to move time forward where the Condition-met should no longer be true. I change the global to 10 and modify the CurrentTime fact and set the t slot to 10 too. Then I run the rules engine and it retracts the (MAIN::Condition-met (globtime 4) (facttime 4)) but then mysteriously asserts (MAIN::Condition-met (globtime 10) (facttime 10)). Since the Condition time of 0 plus 5 is not greater than 10, it should not have asserted this. Here is a dump of the facts in the rules engine at the end: 0: (MAIN::CurrentTime (t 10)) 1: (MAIN::Condition (time 0)) 3: (MAIN::Condition-met (globtime 10) (facttime 10)) I see no justification for the 3rd fact given the only rule I have. Is there a better way of accomplishing this? Dwight To unsubscribe, send the words 'unsubscribe jess-users y...@address.com' in the BODY of a message to majord...@sandia.gov, NOT to the list (use your own address!) List problems? Notify owner-jess-us...@sandia.gov. To unsubscribe, send the words 'unsubscribe jess-users y...@address.com' in the BODY of a message to majord...@sandia.gov, NOT to the list (use your own address!) List problems? Notify owner-jess-us...@sandia.gov.
JESS: [EXTERNAL] Jess asserts fact that is not true
I am trying to reason about the passage of time in my rules. I would like to write the following rule: (defrule Test ?r - (logical (CurrentTime)) (logical (Condition (time ?time:( (+ ?time 5) ?r.t = (assert (Condition-met)) ) Where CurrentTime is a fact that holds the current time, and I change the slot value t as time progresses. The rule fires if the time slot in the Condition plus 5 is greater than the current time (that is, is true within the last 5 time increments). But this syntax is not allowed because you cannot access a dotted variable (the ?r.t) here. My first alternative was to declare a defglobal called *time* and have that change value as time progresses. But there is no way to make the global a logical dependency of the asserted condition-met so it doesn't get retracted when the global changes in value sufficient to make the rule no longer be true. I came up with a workaround where in addition to the defglobal *time* I assert a Fact called CurrentTime that holds the same value in the t slot. Now my rule is: (defrule Test ?r - (logical (CurrentTime (t ?t:(= ?t ?*time* (logical (Condition (time ?time:( (+ ?time 5) ?*time* ; Note I use the global here instead of the dotted var but the value is the same = (assert (Condition-met (globtime ?*time*)(facttime ?r.t))) ) This says that if there is a CurrentTime fact whose slot t has the same value as the global *time* and there is a Condition whose time slot plus 5 is greater than that time, then assert the Condition-met. My java code sets the global to 4, asserts the fact (CurrentTime (t 4)), and then asserts the fact (Condition (time 0)). Since all the conditions are met the rules engine asserts the fact (MAIN::Condition-met (globtime 4) (facttime 4)). All is well though a bit clumsy. Now I want to move time forward where the Condition-met should no longer be true. I change the global to 10 and modify the CurrentTime fact and set the t slot to 10 too. Then I run the rules engine and it retracts the (MAIN::Condition-met (globtime 4) (facttime 4)) but then mysteriously asserts (MAIN::Condition-met (globtime 10) (facttime 10)). Since the Condition time of 0 plus 5 is not greater than 10, it should not have asserted this. Here is a dump of the facts in the rules engine at the end: 0: (MAIN::CurrentTime (t 10)) 1: (MAIN::Condition (time 0)) 3: (MAIN::Condition-met (globtime 10) (facttime 10)) I see no justification for the 3rd fact given the only rule I have. Is there a better way of accomplishing this? Dwight