JESS: No-loop issue

[Aaron Novstrup]

Hi Dr. Friedman-Hill,

I ran into a bug in my rulebase today that I traced back to the use of
the no-loop declaration (test case below).  This has bit other users in
the past (see urls below), and I think it should be regarded as a bug.

In my example, two separate facts (f-2 and f-3) activate a no-loop
rule.  When the rule fires for f-3, it modifies (retracts and reasserts)
another fact, causing the activation associated with f-2 to be removed.  
However, when the fact is reasserted, 'no-loop' prevents the engine from
restoring the activation for f-2.

This behavior seems inconsistent with the definition of the no-loop
declaration.  The RHS of a 'no-loop' rule must not *cause* the immediate
reactivation of the same rule, but it should not inhibit an activation
that was already present when the rule fired.

Thanks,
~~Aaron Novstrup

http://www.mail-archive.com/jess-users@.../msg08025.html
http://www.mail-archive.com/jess-users@.../msg09870.html

; JESS test case
(deftemplate box
   (multislot items))

(deffunction put-in-box (?box ?item)
   (bind ?items (fact-slot-value ?box items))
   (modify ?box (items (union$ ?items (create$ ?item))))
   )

(defrule box-packer-rule
   (declare (no-loop TRUE))
   (moving ?item)
   ?b <- (box)
   =>
   (put-in-box ?b ?item)
   )

(watch all)
(reset)

(assert (box))
(assert (moving elvis-bobble-head-collection))
(assert (moving jimi-hendrix-autographed-guitar))
(run)

; execution trace
Jess, the Rule Engine for the Java Platform
Copyright (C) 2008 Sandia Corporation
Jess Version 7.1p2 11/5/2008

 ==> Focus MAIN
 ==> f-0 (MAIN::initial-fact)
 ==> f-1 (MAIN::box (items ))
 ==> f-2 (MAIN::moving elvis-bobble-head-collection)
==> Activation: MAIN::box-packer-rule :  f-2, f-1
 ==> f-3 (MAIN::moving jimi-hendrix-autographed-guitar)
==> Activation: MAIN::box-packer-rule :  f-3, f-1
FIRE 1 MAIN::box-packer-rule f-3, f-1
<== Activation: MAIN::box-packer-rule :  f-2, f-1
 <=> f-1 (MAIN::box (items jimi-hendrix-autographed-guitar))
 <== Focus MAIN


begin:vcard
fn:Aaron Novstrup
n:Novstrup;Aaron
org:Stottler Henke Associates Inc.
adr;dom:;;1107 NE 45th St;Seattle;WA;98105
email;internet:anovstrup@...
title:AI Software Engineer
tel;work:206.545.2941
tel;cell:805.701.9786
x-mozilla-html:FALSE
url:www.stottlerhenke.com
version:2.1
end:vcard

[Ernest Friedman-Hill]

Indeed, I did agree at one point that this should be fixed.  
Unfortunately I didn't come up with a algorithm that would work this  
way *efficiently.* I will give it another look.


On May 21, 2009, at 9:14 PM, Aaron Novstrup wrote:

> Hi Dr. Friedman-Hill,
>
> I ran into a bug in my rulebase today that I traced back to the use of
> the no-loop declaration (test case below).  This has bit other users  
> in
> the past (see urls below), and I think it should be regarded as a bug.
>
> In my example, two separate facts (f-2 and f-3) activate a no-loop
> rule.  When the rule fires for f-3, it modifies (retracts and  
> reasserts)
> another fact, causing the activation associated with f-2 to be  
> removed.
> However, when the fact is reasserted, 'no-loop' prevents the engine  
> from
> restoring the activation for f-2.
>
> This behavior seems inconsistent with the definition of the no-loop
> declaration.  The RHS of a 'no-loop' rule must not *cause* the  
> immediate
> reactivation of the same rule, but it should not inhibit an activation
> that was already present when the rule fired.
>
> Thanks,
> ~~Aaron Novstrup
>
> http://www.mail-archive.com/jess-users@.../msg08025.html
> http://www.mail-archive.com/jess-users@.../msg09870.html
>
> ; JESS test case
> (deftemplate box
>   (multislot items))
>
> (deffunction put-in-box (?box ?item)
>   (bind ?items (fact-slot-value ?box items))
>   (modify ?box (items (union$ ?items (create$ ?item))))
>   )
>
> (defrule box-packer-rule
>   (declare (no-loop TRUE))
>   (moving ?item)
>   ?b <- (box)
>   =>
>   (put-in-box ?b ?item)
>   )
>
> (watch all)
> (reset)
>
> (assert (box))
> (assert (moving elvis-bobble-head-collection))
> (assert (moving jimi-hendrix-autographed-guitar))
> (run)
>
> ; execution trace
> Jess, the Rule Engine for the Java Platform
> Copyright (C) 2008 Sandia Corporation
> Jess Version 7.1p2 11/5/2008
>
> ==> Focus MAIN
> ==> f-0 (MAIN::initial-fact)
> ==> f-1 (MAIN::box (items ))
> ==> f-2 (MAIN::moving elvis-bobble-head-collection)
> ==> Activation: MAIN::box-packer-rule :  f-2, f-1
> ==> f-3 (MAIN::moving jimi-hendrix-autographed-guitar)
> ==> Activation: MAIN::box-packer-rule :  f-3, f-1
> FIRE 1 MAIN::box-packer-rule f-3, f-1
> <== Activation: MAIN::box-packer-rule :  f-2, f-1
> <=> f-1 (MAIN::box (items jimi-hendrix-autographed-guitar))
> <== Focus MAIN
>
> <anovstrup.vcf>

---------------------------------------------------------
Ernest Friedman-Hill
Informatics & Decision Sciences, Sandia National Laboratories
PO Box 969, MS 9012, 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@....
--------------------------------------------------------------------

[Peter Lin]

This is just my bias opinion, but the bigger issue is this. Rule
programming is logic programming. Therefore you need to think in those
terms.  What you need to do is check if the item is already in the box
before firing the rule. That can be done with either TESTCE.

The rule you have tells the rule engine to fire when ever there's an
item and box. The function is always modifying the box after it adds
the item to the multislot. the engine is doing exactly what you told
it to do. Instead, what you should do is "add the item to the box if
it isn't already in it"

hope that helps

peter

On Thu, May 21, 2009 at 9:14 PM, Aaron Novstrup
<anovstrup@...> wrote:

> Hi Dr. Friedman-Hill,
>
> I ran into a bug in my rulebase today that I traced back to the use of the
> no-loop declaration (test case below).  This has bit other users in the past
> (see urls below), and I think it should be regarded as a bug.
> In my example, two separate facts (f-2 and f-3) activate a no-loop rule.
>  When the rule fires for f-3, it modifies (retracts and reasserts) another
> fact, causing the activation associated with f-2 to be removed.  However,
> when the fact is reasserted, 'no-loop' prevents the engine from restoring
> the activation for f-2.
>
> This behavior seems inconsistent with the definition of the no-loop
> declaration.  The RHS of a 'no-loop' rule must not *cause* the immediate
> reactivation of the same rule, but it should not inhibit an activation that
> was already present when the rule fired.
>
> Thanks,
> ~~Aaron Novstrup
>
> http://www.mail-archive.com/jess-users@.../msg08025.html
> http://www.mail-archive.com/jess-users@.../msg09870.html
>
> ; JESS test case
> (deftemplate box
>  (multislot items))
>
> (deffunction put-in-box (?box ?item)
>  (bind ?items (fact-slot-value ?box items))
>  (modify ?box (items (union$ ?items (create$ ?item))))
>  )
>
> (defrule box-packer-rule
>  (declare (no-loop TRUE))
>  (moving ?item)
>  ?b <- (box)
>  =>
>  (put-in-box ?b ?item)
>  )
>
> (watch all)
> (reset)
>
> (assert (box))
> (assert (moving elvis-bobble-head-collection))
> (assert (moving jimi-hendrix-autographed-guitar))
> (run)
>
> ; execution trace
> Jess, the Rule Engine for the Java Platform
> Copyright (C) 2008 Sandia Corporation
> Jess Version 7.1p2 11/5/2008
>
> ==> Focus MAIN
> ==> f-0 (MAIN::initial-fact)
> ==> f-1 (MAIN::box (items ))
> ==> f-2 (MAIN::moving elvis-bobble-head-collection)
> ==> Activation: MAIN::box-packer-rule :  f-2, f-1
> ==> f-3 (MAIN::moving jimi-hendrix-autographed-guitar)
> ==> Activation: MAIN::box-packer-rule :  f-3, f-1
> FIRE 1 MAIN::box-packer-rule f-3, f-1
> <== Activation: MAIN::box-packer-rule :  f-2, f-1
> <=> f-1 (MAIN::box (items jimi-hendrix-autographed-guitar))
> <== Focus MAIN
>
>

--------------------------------------------------------------------
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@....
--------------------------------------------------------------------