Re: [lisa] Re: lisa bug: matching on retracted facts

"David E. Young" <[email protected]> Thu, 7 Jul 2005 19:05:41 -0400
Newsgroups gmane.lisp.lisa.general
Message-ID <001f01c58348$65ede2a0$6401a8c0@tinian>
You don't happen to allow duplicate facts in your system, do you? I'm not
sure if that's relevent; just want to rule that out...

dey

----- Original Message ----- 
From: "Andy Sloane" <[email protected]>
To: <[email protected]>
Sent: Thursday, July 07, 2005 5:21 PM
Subject: [lisa] [Lisa-users] Re: lisa bug: matching on retracted facts


> Hi,
>
> I have a much simpler test case which more clearly demonstrates what's
> going on, and a workaround:
>
> -------- [lisp code] --------
>
> (in-package :lisa-user)
>
> (clear)
>
> (deftemplate control-fact ())
>
> (deftemplate multiple-facts ()
>    (slot instancename))
>
> (defrule broken-rule ()
>    ;; NOTE: swapping the order of these two patterns fixes the problem
>    (control-fact)
>    (multiple-facts (instancename ?name))
>    =>
>    (format t "This rule shouldnt fire (instance name=~a)~%" ?name))
>
> (defrule startup ()
>    =>
>    (assert (multiple-facts (instancename first))) ; broken-rule doesn't
> fire on the first instance
>    (assert (multiple-facts (instancename second))) ; but it does fire on
> each subsequent one.
>    (assert (multiple-facts (instancename third)))
>    (assert (multiple-facts (instancename fourth)))
>    (retract (assert (control-fact))))
>
> (watch :all)
> (reset)
> (run)
>
> -------- [output] --------
>
> ==> F-0 (INITIAL-FACT)
> ==> Activation: STARTUP : (F-0)
> FIRE 1: STARTUP (F-0)
> ==> F-1 (MULTIPLE-FACTS (INSTANCENAME FIRST))
> ==> F-2 (MULTIPLE-FACTS (INSTANCENAME SECOND))
> ==> F-3 (MULTIPLE-FACTS (INSTANCENAME THIRD))
> ==> F-4 (MULTIPLE-FACTS (INSTANCENAME FOURTH))
> ==> F-5 (CONTROL-FACT)
> ==> Activation: BROKEN-RULE : (F-5 F-1)
> ==> Activation: BROKEN-RULE : (F-5 F-2)
> ==> Activation: BROKEN-RULE : (F-5 F-3)
> ==> Activation: BROKEN-RULE : (F-5 F-4)
> <== F-5 (CONTROL-FACT)
>    0: (LISA::REMOVE-FACT-FROM-NETWORK #<RETE-NETWORK {9EE0A99}>
>                           #<FACT F-5, CONTROL-FACT, CF is 0.000>)
> <== Activation: BROKEN-RULE : (F-5 F-1)
>    0: LISA::REMOVE-FACT-FROM-NETWORK returned NIL
> FIRE 2: BROKEN-RULE (F-5 F-2)
> This rule shouldnt fire (instance name=SECOND)
> FIRE 3: BROKEN-RULE (F-5 F-3)
> This rule shouldnt fire (instance name=THIRD)
> FIRE 4: BROKEN-RULE (F-5 F-4)
> This rule shouldnt fire (instance name=FOURTH)
>
> ----------------
>
> (I have (trace lisa::remove-fact-from-network) enabled there).
>
> I suspect that the remove-fact token isn't being pushed down all the way
> through the network, but I have no idea why.  I'm currently trying to
> figure out how that code works.
>
> However!  If you swap the order of the two patterns in broken-rule, it
> retracts all potential activations as expected.
>
> -Andy
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by the 'Do More With Dual!' webinar
happening
> July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
> core and dual graphics technology at this free one hour event hosted by
HP,
> AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar
> _______________________________________________
> Lisa-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/lisa-users
>
>




-------------------------------------------------------
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual
core and dual graphics technology at this free one hour event hosted by HP,
AMD, and NVIDIA.  To register visit http://www.hp.com/go/dualwebinar