JESS: Problem with test function

[bohlken]

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.: [phone]




--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------

[Ernest Friedman-Hill]

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.: [phone]
>
>
>
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users  
> you@...'
> in the BODY of a message to majordomo@..., NOT to the list
> (use your own address!) List problems? Notify owner-jess-users@...
> .
> --------------------------------------------------------------------

---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences          Phone: [phone]
Sandia National Labs
PO Box 969, MS 9012                            ejfried@...
Livermore, CA 94550                             http://www.jessrules.com





--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------

[bohlken]

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: owner-jess-users@... [mailto:owner-jess-users@...] 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.: [phone]
>
>
>
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users  
> you@...'
> in the BODY of a message to majordomo@..., NOT to the list
> (use your own address!) List problems? Notify owner-jess-users@...
> .
> --------------------------------------------------------------------

---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences          Phone: [phone]
Sandia National Labs
PO Box 969, MS 9012                            ejfried@...
Livermore, CA 94550                             http://www.jessrules.com





--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------



--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------

[LAUN, Wolfgang]

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: owner-jess-users@... [mailto:owner-jess-users@...]Im
Auftrag von bohlken
Gesendet: Montag, 27. April 2009 11:35
An: jess-users@...
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: owner-jess-users@... [mailto:owner-jess-users@...] 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.: [phone]
>
>
>
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users  
> you@...'
> in the BODY of a message to majordomo@..., NOT to the list
> (use your own address!) List problems? Notify owner-jess-users@...
> .
> --------------------------------------------------------------------

---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences          Phone: [phone]
Sandia National Labs
PO Box 969, MS 9012                            ejfried@...
Livermore, CA 94550                             http://www.jessrules.com





--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------



--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------



--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------

[bohlken]

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: owner-jess-users@... [mailto:owner-jess-users@...] Im
Auftrag von LAUN, Wolfgang
Gesendet: Dienstag, 28. April 2009 13:28
An: jess-users@...
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: owner-jess-users@... [mailto:owner-jess-users@...]Im
Auftrag von bohlken
Gesendet: Montag, 27. April 2009 11:35
An: jess-users@...
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: owner-jess-users@... [mailto:owner-jess-users@...] 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.: [phone]
>
>
>
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users  
> you@...'
> in the BODY of a message to majordomo@..., NOT to the list
> (use your own address!) List problems? Notify owner-jess-users@...
> .
> --------------------------------------------------------------------

---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences          Phone: [phone]
Sandia National Labs
PO Box 969, MS 9012                            ejfried@...
Livermore, CA 94550                             http://www.jessrules.com





--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------



--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------



--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------



--------------------------------------------------------------------
To unsubscribe, send the words 'unsubscribe jess-users you@...'
in the BODY of a message to majordomo@..., NOT to the list
(use your own address!) List problems? Notify owner-jess-users@....
--------------------------------------------------------------------

[Wolfgang Laun-2]

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 <
wilfried.bohlken@...> 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: owner-jess-users@... [mailto:owner-jess-users@...] Im
> Auftrag von LAUN, Wolfgang
> Gesendet: Dienstag, 28. April 2009 13:28
> An: jess-users@...
> 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: owner-jess-users@... [mailto:owner-jess-users@...]Im
> Auftrag von bohlken
> Gesendet: Montag, 27. April 2009 11:35
> An: jess-users@...
> 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: owner-jess-users@... [mailto:owner-jess-users@...] 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.: [phone]
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > To unsubscribe, send the words 'unsubscribe jess-users
> > you@...'
> > in the BODY of a message to majordomo@..., NOT to the list
> > (use your own address!) List problems? Notify
> owner-jess-users@...
> > .
> > --------------------------------------------------------------------
>
> ---------------------------------------------------------
> Ernest Friedman-Hill
> Informatics & Decision Sciences          Phone: [phone]
> Sandia National Labs
> PO Box 969, MS 9012                            ejfried@...
> Livermore, CA 94550                             http://www.jessrules.com
>
>
>
>
>
> --------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users you@...'
> in the BODY of a message to majordomo@..., NOT to the list
> (use your own address!) List problems? Notify owner-jess-users@...