You might omit the (create$) calls just for passing arguments to check() as they create unnecessary overhead. -W
On Thu, Apr 30, 2009 at 1:00 PM, bohlken < [email protected]> wrote: > Hello, > > thank you for your answer. > I think I now found out the "right" solution. > The temporal constraint net itself must be an element of the working memory > with all its values in two multislots ($?tMins and $?tMaxs). > Now the result value of the test function is not anymore time-varying. > By the way the time points are part of some other facts, which I did > not give in this example, they do not stand alone. > > Thanks again > Wilfried > > > > (defrule myRule > ... > > (TimePoint (name ?tp1) (tMin ?tMin1) (tMax ?tMax1)) > (TimePoint (name ?tp2) (tMin ?tMin2) (tMax ?tMax2)) > > (TemporalConstraintNet (tMins $?tMins) (tMaxs $?tMaxs) (OBJECT tcn-obj) > > ;; check temporal constraints > (test (call ?tcn-obj check > $?tMins > $?tMaxs > (create$ ?tMin1 ?tMin2) > (create$ ?tMax1 ?tMax2))) > > > > > > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] Im > Auftrag von LAUN, Wolfgang > Gesendet: Dienstag, 28. April 2009 13:28 > An: [email protected] > Betreff: AW: JESS: Problem with test function > > I still don't like it, mainly because the three TimePoint patterns may also > match > the same fact (thrice, for any existing TimePoint fact), or for any > combination > of two facts (one twice, one once). To restrict this to a single binding > you'd > have to add constraints ensuring one specific association, e.g.: > ?tp1 <- (TimePoint) > ?tp2 <- (TimePoint {time > ?tp1.time }) > ?tp3 <- (TimePoint {time > ?tp2.time }) > > Considering the original problem, it might be preferable to separate the > issues: > - rule activation/deactivation > - rule firing > > You have identified the conditions for activation/deactivation; use them in > one rule to assert/retract a guard fact for the other rule that's supposed > to > do the actual reasoning. This other rule combines its specific Guard > (made specific by a slot value) with the patterns required for reasoning. > > You may use salience for ensuring that the (de)activation calculation is > done prior to the actual reasoning. > > -W > > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]]im > Auftrag von bohlken > Gesendet: Montag, 27. April 2009 11:35 > An: [email protected] > Betreff: AW: JESS: Problem with test function > > > Hello, > > Thank you for your answer. I have worked out a solution, that seems to > work. > > > The TimePoints are part of a temporal constraint net. I have defined a > counter (TCNCounter) as a shadow fact, that is incremented every time > the constraint net (and the time points) has been updated by another > rule, the value of the counter is an argument of the test function > (so the test function check is called every time the constraint net has > been updated): > > > (defrule myRule2 > (TimePoint (name ?name1)(OBJECT ?tp1-obj)) > (TimePoint (name ?name2)(OBJECT ?tp2-obj)) > (TimePoint (name ?name3)(OBJECT ?tp3-obj)) > (TCNCounter (val ?tcn-val)) > (test (call ?*myTest* check > "myRule2" > (create$ ?tp1-obj ?tp2-obj ?tp3-obj) > ?tcn-val)) > > > The counter is an element of *myTest*: > > public class myTest > { > ... > private TCNCounter tcnCounter; > ... > > > public boolean check(String ruleName, TimePoint[] timePoints, > int counterVal) > { > > if (counterVal != tcnCounter.getVal()) > { > // call with old values > > return true; > } > > ... > } > } > > If the value of the counter in the check function call is not the same as > the tcnCounter of myTest, then this is a call with old values and it > returns > true, so an activated rule is then deactivated. The TCNCounter value > changes, the check function is called again (now the values are the same) > and the check function returns true or false, and the rule is activated > again or not. > > Do you think this is a solution to my problem? > > Thank you very much. > Wilfried > > > > > > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] Im > Auftrag von Ernest Friedman-Hill > Gesendet: Freitag, 24. April 2009 17:17 > An: jess-users > Betreff: Re: JESS: Problem with test function > > The short answer: yes, this is how it works. Your function will be > called both to check for new matches, and to confirm old ones, and > Jess may or may not memoize the results so that your function may not > be called when you think it might. You can't use a method whose return > value varies over time this way, or your system will quickly become > inconsistent, for the same reasons that a Java Comparator with a time- > varying return value could not be used to sort an array. > > On Apr 24, 2009, at 7:16 AM, bohlken wrote: > > > Hello all, > > > > I have defined a rule with the shadow facts TimePoint like this: > > > > > > (defrule myRule1 > > > > (TimePoint (name ?name1)(OBJECT ?tp1-obj)) > > (TimePoint (name ?name2)(OBJECT ?tp2-obj)) > > (test (call ?*myTest* check ?tp1-obj ?tp2-obj)) > > => > > ...) > > > > *myTest* is a JAVA Object with a check function. > > Now, lets say the rule will be activated (the result of check is > > true). > > > > In my application it can happen, that the result of the check function > > becomes false, independend(!) of the facts in the rule. > > > > Now, if a fact changes, the following happens: > > > > - the check function is called with the OLD values - before the fact > > has > > changed(!) -, if the result is true, then the rule is deactivated, > > the fact > > is changed, the check function is called again, and if true, the > > rule is > > activated again > > > > - if the check function with the OLD values is false, then the rule > > will NOT > > be deactivated. The fact is changed, the check function is called > > again. It > > can again be false and the rule will NOT be deactivated. > > > > Is this a bug or a feature? > > > > Thanks, > > Wilfried > > > > > > > > > > Wilfried Bohlken > > Arbeitsbereich Kognitive Systeme > > FB Informatik > > Universitaet Hamburg > > Vogt-Koelln-Str. 30 > > 22527 Hamburg > > Germany > > Tel.: +49-40-42883-2577 > > > > > > > > > > -------------------------------------------------------------------- > > 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 > Informatics & Decision Sciences Phone: (925) 294-2154 > Sandia National Labs > PO Box 969, MS 9012 [email protected] > Livermore, CA 94550 http://www.jessrules.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]
