I can reproduce your observation, and I -think- I can explain
it. Remember that the need-X facts are generated by the actual Rete
network join nodes.
(defrule PERSONALITY_PROBLEMS::r001
(declare (auto-focus TRUE))
(explicit (PERSONALITY_PROBLEMS::personality_problems (troubling ?v1)))
(test (or (eq ?v1 yes)(eq ?v1 nil)))
* (PERSONALITY_PROBLEMS::personality_problems (troubling yes))
Think about the join node the has the pattern starred above as its
right input. Now, when the (personality_problems (troubling yes)) fact
is being processed, note that it matches both the left and right
inputs of this join node. First the left input will see it, then the
right input. When the left input sees it, there isn't yet any fact in
the right memory which matches, and there's no need-X fact that
describes the missing fact (because you retracted the need-X fact!) so
a new need-X is generated. Then, later, still during the modify call,
the fact reaches the rigth input. But by then, it's too late, the
need-X fact has already been generated. So I think this explains
your observation.
Now, I'm not sure what this rule is trying to do -- why are there five
separate personality_problems patterns? Are they all intended to match
separate facts, or the same one, or some combination?
I think Waldek Jaronski wrote:
> Hello everyone,
>
> Despite many hard attempts I still can't figure out why precisely a new
> need-xxx fact is asserted...
> Consider the following case:
>
> There is a template
> (deftemplate PERSONALITY_PROBLEMS::personality_problems
> (slot troubling)
> (slot perceiving)
> (slot personality_problems)
> )
> which is backward chaining reactive. There is always only one (def)fact with
> this template.
>
> Now, there is a number of rules which update the slot personality_problems
> based on the values of two other slots, eg., if troubling is yes and
> perceiving is yes, then personality_problems should be yes
> (defrule PERSONALITY_PROBLEMS::r001
> (declare (auto-focus TRUE))
> (explicit (PERSONALITY_PROBLEMS::personality_problems (troubling ?v1)))
> (test (or (eq ?v1 yes)(eq ?v1 nil)))
> (PERSONALITY_PROBLEMS::personality_problems (troubling yes))
> (explicit (PERSONALITY_PROBLEMS::personality_problems (perceiving ?v2)))
> (test (or (eq ?v2 yes)(eq ?v2 nil)))
> (PERSONALITY_PROBLEMS::personality_problems (perceiving yes))
>
> ?factid <- (explicit (PERSONALITY_PROBLEMS::personality_problems
> (personality_problems nil)))
> =>
> (modify ?factid (personality_problems yes))
> )
>
> At the beginning all slots are equal nil. The rule r001 contributes
> therefore at startup to assertion of fact
> (PERSONALITY_PROBLEMS::need-personality_problems (troubling yes) (perceiving
> nil) (personality_problems nil))
>
> There is also a rule which should retract this need- fact when the value of
> troubling is becomes known:
> (defrule PERSONALITY_PROBLEMS::need_1_troubling_answered
> (declare (auto-focus TRUE))
> (PERSONALITY_PROBLEMS::answered troubling)
> ?fff <- (PERSONALITY_PROBLEMS::need-personality_problems (troubling ~nil))
> =>
> (retract ?fff))
>
> When the value of troubling is known, first I assert fact
> (PERSONALITY_PROBLEMS::answered troubling), which activates and executes
> this rule, so that ?fff is retracted. Then I modify slot troubling in the
> fact (PERSONALITY_PROBLEMS::personality_problems) with (modify ...) command
> to the value yes. This causes, following the rule r001, assertion of
> (PERSONALITY_PROBLEMS::need-personality_problems (troubling nil) (perceiving
> yes) (personality_problems nil)) which I am very happy about, but also
> (PERSONALITY_PROBLEMS::need-personality_problems (troubling yes) (perceiving
> nil) (personality_problems nil)) again.
>
> I do not understand why this latter fact is again asserted while the pattern
> (PERSONALITY_PROBLEMS::personality_problems (troubling yes)) should already
> exist since I have just modified the slot troubling.
>
> Could someone please explain it to me ?
> Thanks in advance,
> Waldek
>
> --------------------------------------------------------------------
> 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]
--------------------------------------------------------------------