Hi Marco,
The term 'pseudo time tags' is rather confusing to me, since neither
CLIPS nor Jess does anything that could be described using such a
term. The behaviour you describe is not exactly correct,
either. Thinking back, I remember first figuring the behaviour out and
finally realizing how it falls very naturally out of the Rete
algorithm; I could attempt to explain it here. Note that what I'm
about to say holds for the entire OPS5 family of systems, Jess and
CLIPS included.
1) All (not X) CEs are treated as (Y AND (NOT X)). If the (not) CE is
the second or later CE on the LHS of the rule, then the immediately
previous CE is used as Y. If the (not) CE is the first CE, then a
pattern for (initial-fact) is inserted on the rule LHS. You can use
'ppdefrule' to investigate this.
2) Recall that Rete tests things whenever a fact relevant to a given test
is either asserted or retracted, and that it remembers past results of
tests as long as they are valid. In other words, if you have a rule
like
(defrule foo-1
(A)
(B)
=>)
then foo-1 is activated as soon as both an (A) and a (B) fact
exist. If either (B) or (A) are retracted before foo-1 fires, foo-1 is
deactivated. This is as it should be. Rete "knows" to deactivate foo-1
in this case only because it remembers that (A AND B) was once true,
and when, for example, (B) is retracted, a "(A AND B) is no longer
true" message gets sent to foo-1.
3) This description is enough to explain the real behaviour of (not)
CEs. Reference the following rule:
(defrule foo-2
(A ?X)
(not (B ?X))
=>)
Now assume that (A 1) is asserted. The (A AND (NOT B)) test succeeds,
so foo-2 becomes activated. Now supose that before foo-2 fires, (B 1)
is asserted. (A AND (NOT B)), which was true, is now false, so an "(A
AND (NOT B)) is no longer true" message is sent to foo-2, which is
thus deactivated. Now suppose (B 1) is retracted again. An "(A AND (NOT
B)) is true" message goes to foo-2, which is activated. And so on. If
(A 2) is asserted, foo-2 is activated twice, once for X=1 and once for
X=2.
That's it. It's much simpler than I think you were imagining.
Given this description, you can probably modify your rules to prevent
the multiple firings simply by not retracting facts which suppress
(not)s until the other antecedents are also retracted.
OR you can wait till we get the bugs out of 5.0, which supports
backwards chaining as a language feature.
I think Marco Colombetti wrote:
>
> Hi. I'm new to this list, so I don't know if pseudo time tags for negated
> patterns have already been discussed - if so, I apologize.
>
> I never quite understood why CLIPS rule activation associates "pseudo time
> tags" to negated patters (I understand that Jess has the same mechanism).
> Probably pseudo time tags are useful with by some conflict resolution
> strategies (like LEX and MEA) in order to be sensitive also to negated
> conditions.
>
> However, it seems to me that the use of pseudo time tags has at least a
> major drawback. Let me give an example.
>
> Suppose we have a goal, (goal A), which can be achieved by two alternative
> actions, (action A 1) and (action A 2). In turn, (action A 1) has
> precondition B, and (action A 2) has precondition C. I want to implement
> the following "Prolog-like" backtracking search starting from (goal A):
>
> (goal A)
> try (action A 1)
> subgoal (goal B)
> ...
> fail: retract (goal B)
> fail: retract (action A 1)
> try (action A 2)
> subgoal (goal C)
> ...
>
> With an OPS5-like language, I would define the following rules:
>
> (defrule r1
> (goal A)
> (not (action A ?)) ; negative condition used to "inhibit" parallel search
> =>
> (assert (action A 1) (goal B))
>
> (defrule r2
> (goal A)
> (not (action A ?)) ; negative condition used to "inhibit" parallel search
> =>
> (assert (action A 2) (goal C))
>
> (defrule ... ; more rules including those dealing with failure
>
> This very simple programming style relies on the fact that refractoriness
> is NOT sensitive to negated conditions: in this way, rule r1 cannot be
> activated again after the failure of (action A 1). With CLIPS-style pseudo
> tags, on the contrary, after the failure of (action A 1) the interpreter
> will try the SAME action over and over again. Too bad.
>
> Is there an easy way to remove pseudo time tags from Jess? Or maybe to
> implement an optional "weak refractoriness" mechanism which is not
> sensitive to pseudo time tags?
>
> Sorry for the long message.
>
>
>
>
>
>
> Marco Colombetti
> Associate Professor of Knowledge Engineering and Expert Systems
>
> Artificial Intelligence and Robotics Project
> Dipartimento di Elettronica e Informazione
> Politecnico di Milano
> Piazza Leonardo da Vinci, 32
> 20133 Milano, Italy
>
> Email: [EMAIL PROTECTED] or [EMAIL PROTECTED]
> URL: http://www.elet.polimi.it/people/colombet/
> Voice: (+39) 02 2399 3686 (*)
> Fax: (+39) 02 2399 3411 (*)
>
> (*) WARNING: After the country code (+39), use the full area
> code (02), including the zero!
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]'
> in the BODY of a message to [EMAIL PROTECTED], NOT to the
> list. 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 9214 [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. List problems? Notify [EMAIL PROTECTED]
---------------------------------------------------------------------
