Re: JESS: Defrule ordering woes

2003-08-26 Thread ejfried
Basically, the problem is that salience doesn't mean much in a
multithreaded system. A rule may have very low salience, but if it is
activated before other rules of higher salience are activated, then it
may be fired (on the run thread, different from the thread where the
rule was activated) before those other rules have a change to displace
it from the top of the agenda.

In this case, your low-salience delete-timer-events rule is firing as
fast as the new facts appear, before the quarter-minute and minute
rules have a chance to fire. delete-timer-facts matches every
temporal-event fact as soon as it appears, and furthermore, the
patterns are identical to those of the rule show-seconds, so both of
those are being activated together, and salience makes show-seconds
fire first. But the other two rules have slightly different patterns,
so they're activated at a slightly different time (the order here is
arbitrary and, as you've seen, depends on the order in which the rules
are defined.)

One more definite solution, rather than yours which depends on
undefined behavior, is to modify delete-timer-facts so that it allows
a few timer facts to stay around before deleting them -- i.e.,
something like 

(defrule delete-timer-events Delete any old temporal-event facts
(declare (salience -100))
?t - (temporal-event (ctm ?ctm))
(not (temporal-event (ctm ?ctm2:( (- ?ctm 1) ?ctm2
=
;;(printout t Retracting  ?t crlf)
(retract ?t))

Now, the underlying Jess behavior that causes this is something we've
talked about on the list before.  Basically, what Jess does now is
allow rules to initiate firing on one thread during pattern matching
occurring on another thread; if a single fact activates three rules,
then the first activation can fire before the second rule is even
placed on the agenda. This has very good liveness characteristics, but
leads to inversions like what Mitch is seeing here.

An alternative is for the agenda to be locked during pattern-matching,
so that the run-until-halt thread would not be able to pop an activation
from the agenda until after all the activations from a single
assertion event were present. This would make Mitch's problem go away,
but with a potential performance loss in densely multithreaded
operation.

Anyone want to comment?


I think Mitch Christensen wrote:
[Charset iso-8859-1 unsupported, filtering to ASCII...]
 Hey,
 
 I'm having trouble understanding why reordering 'defrule' statements in a
 Jess script changes how the program runs.
 
 Specifically, I've created a UserFunction timer that asserts a
 'temporal-event' fact every second (source attached).  Then I have a simple
 Jess script (also attached) that loads and executes the UserFunction, and
 then defines 3 debugging rules.  These rules do a printout at each second,
 quarter-minute and minute (there is also a rule to retract old facts).
 
 My problem is that the seconds rule always fires, while quarter-minute and
 minute rules are sporadic (sometimes they fire sometimes not).  If I simply
 re-order the rules, putting the minute rule first, the quarter-minute rule
 next and the second rule last, things seem to work fine.
 
 Now, if I understood why, I'd be in pretty good shape. ;)
 
 Any suggestions?
 
 -Mitch
 
 P.S. 'ctm' is for CurrentTimeMillis.  It's the only way I could find to keep
 rules from firing more than once, i.e. only fire if this fact has the
 lowest ctm in working memory and to fire in the proper order should
 multiple temporal-event facts be asserted between (runs).
 

[Attachment, skipping...]

[Attachment, skipping...]



-
Ernest Friedman-Hill  
Distributed Systems ResearchPhone: (925) 294-2154
Sandia National LabsFAX:   (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://herzberg.ca.sandia.gov


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]




Re: JESS: Strange behavior when using Jess modules

2003-08-26 Thread Felix H. Bachmann



Hi,
a few days ago I posted a question concerning the use of modules and so far I did not get 
any answer. Is there really no one who could help me to figure out what is wrong with 
the following example?


Felix


Here an interesting issue. (I hope)

Assume the rules are structured into 3 modules (MAIN, A, and B) which contain 
statements to assert ordered facts as shown in this example:

;
; c:/jess/test/A.clp
;
(defmodule A)

(defrule forA
(MAIN::initial-fact)
=
(assert (testfact A in A))
(assert (testfact B in A)))
;
; c:/jess/test/B.clp
;
(defmodule B)

(defrule forB
(initial-fact)
(MAIN::testfact B in MAIN) ;  This causes the trouble
=
(assert (testfact A in B))
(assert (testfact B in B)))
;
; c:/jess/test/MAIN.clp
;

(batch c:/jess/test/A.clp)
(batch c:/jess/test/B.clp)
(reset)
(set-current-module MAIN)
(assert (testfact A in MAIN))
(assert (testfact B in MAIN))
(focus A B)

Module B contains a rule that matches a fact from module MAIN (see the mark). After 
loading MAIN.clp and running this little program jess displays the following facts:
-Result with the marked statement
Jess (facts *)
f-0 (MAIN::initial-fact)
f-1 (MAIN::testfact A in MAIN)
f-2 (MAIN::testfact B in MAIN)
f-3 (A::testfact A in A)
f-4 (A::testfact B in A)
f-5 (MAIN::testfact A in B)
f-6 (MAIN::testfact B in B)
For a total of 7 facts.
Jess

f-5 and f-6 should not be facts in module MAIN but in module B. After removing that 
marked pattern from the rule ForB, facts are created as expected:

-Result without the marked statement
Jess (facts *)
f-0 (MAIN::initial-fact)
f-1 (MAIN::testfact A in MAIN)
f-2 (MAIN::testfact B in MAIN)
f-3 (A::testfact A in A)
f-4 (A::testfact B in A)
f-5 (B::testfact A in B)
f-6 (B::testfact B in B)
For a total of 7 facts.
Jess

Can anybody tell me what I am doing wrong here?

Felix
Felix Bachmann
Carnegie Mellon 
Voice: +1 (412) 268 6194
Software Engineering Institute 
FAX: +1 (412) 268 5758
Pittsburgh, PA 15213







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]




Re: JESS: Strange behavior when using Jess modules

2003-08-26 Thread ejfried
I think Felix H. Bachmann wrote:
 A few days ago I posted a question concerning the use of modules and
 so far I did not get  any answer. Is there really no one who could
 help me to figure out what is wrong with the following
 example?

Probably because many people didn't bother to read it the first
time. A pet peeve of mine: as you can see below, your message is
pretty much incomprehensible for those of us who use normal plaintext
MUAs. If you're going to send HTML mail to a mailing list (or frankly,
to anyone) you should either make sure ahead of time they're
interested in receiving it, or check the send as both HTML and
plaintext box in your MUA.

But this time, I fired up Mozilla to read it, and so I can explain
what you're seeing. There's nothing wrong at all; you may not
understand the rules Jess uses for module lookup. They're explained in
section 2.10.2 of the manual, or page 125 of JIA.

Specifically, as applied to your example: when parsing a rule like this:

(defrule A::forA
  (MAIN::initial-fact)
  =
  (assert (testfact A in A))
  (assert (testfact B in A)))

Jess has to decide what module testfact is in. The procedure is
really simple: Jess looks in module A, and if the template is not there,
Jess looks in MAIN. If it's not there, then it gets created in the
current module. In your program, this is A, and there's no
MAIN::testfact, so A::testfact is created and used on the rule's RHS.

Now, when Jess parses this rule:

(defrule B::forB
  (initial-fact)
  (MAIN::testfact B in MAIN)
  =
  (assert (testfact A in B))
  (assert (testfact B in B)))

when Jess sees the MAIN::testfact pattern, this implied deftemplate is
created in MAIN. Now on the RHS, Jess follows the same search
procedure as when parsing the rule A::forA, but now the deftemplate
MAIN::testfact is found, so it is used, and no new testfact template
is created in the current module.

[ Original message below. ]

I think Felix H. Bachmann wrote:
 ?xml  version=1.0 ?html
 head
 title/title
 /head
 body
 div align=leftfont face=Times New Romanspan 
 style=font-size:10ptHi,/span/font/div
 div align=leftfont face=Times New Romanspan style=font-size:10pta few 
 days ago I posted a question concerning the use of modules and so far I did not get 
 any answer.#160; Is there really no one who could help me to figure out what is 
 wrong with 
 the following example?/span/font/div
 div align=leftbr/
 /div
 div align=leftfont face=Times New Romanspan 
 style=font-size:10ptFelix/span/font/div
 div align=leftbr/
 /div
 div align=leftfont face=Times New Romanspan style=font-size:10ptHere an 
 interesting issue. (I hope)/span/font/div
 div align=leftbr/
 font face=Times New Romanspan style=font-size:10ptAssume the rules are 
 structured into 3 modules (MAIN, A, and B) which contain 
 statements to assert ordered facts as shown in this example:/span/font/div
 div align=leftbr/
 font face=Courier Newspan style=font-size:10pt;/span/font/div
 div align=leftfont face=Courier Newspan style=font-size:10pt; 
 c:/jess/test/A.clp/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt;/span/font/div
 div align=leftfont face=Courier Newspan style=font-size:10pt(defmodule 
 A)/span/font/div
 div align=leftbr/
 font face=Courier Newspan style=font-size:10pt(defrule 
 forA/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt(MAIN::initial-fact)/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt=gt;/span/font/div
 div align=leftfont face=Courier Newspan style=font-size:10pt(assert 
 (testfact A in A))/span/font/div
 div align=leftfont face=Courier Newspan style=font-size:10pt(assert 
 (testfact B in A)))/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt;/span/font/div
 div align=leftfont face=Courier Newspan style=font-size:10pt; 
 c:/jess/test/B.clp/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt;/span/font/div
 div align=leftfont face=Courier Newspan style=font-size:10pt(defmodule 
 B)/span/font/div
 div align=leftbr/
 font face=Courier Newspan style=font-size:10pt(defrule 
 forB/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt(initial-fact)/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt(MAIN::testfact B in MAIN) ; lt; This causes the 
 trouble/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt=gt;/span/font/div
 div align=leftfont face=Courier Newspan style=font-size:10pt(assert 
 (testfact A in B))/span/font/div
 div align=leftfont face=Courier Newspan style=font-size:10pt(assert 
 (testfact B in B)))/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt;/span/font/div
 div align=leftfont face=Courier Newspan style=font-size:10pt; 
 c:/jess/test/MAIN.clp/span/font/div
 div align=leftfont face=Courier Newspan 
 style=font-size:10pt;/span/font/div
 div align=leftbr/
 font face=Courier Newspan style=font-size:10pt(batch 

RE: JESS: Subrules

2003-08-26 Thread James Owen
I'm thinking that this isn't declarative programming but more of a
procedural approach to problem solving.  In declarative programming,
theoretically anyway, each rule should be incrementally independent as
much as possible.  By putting the rules in a situation like that shown
below usually shows that the solution is not declarative but procedural.
If ruleA is true then check ruleB means that ruleB is dependent on
ruleA.  Rather the data of ruleB might have some data that is modified
by ruleA, then that would be declarative.

Maybe what you really want here is rule sets where a rule set is
activated only during the firing of certain rules.  Yes, I know:  That
isn't much different in practice but the thinking behind it is
significantly different.

SDG
jco
 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Judson, Ross
Sent: Tuesday, August 26, 2003 10:10 AM
To: [EMAIL PROTECTED]
Subject: JESS: Subrules


From the wish-list department: I'd sure like it if, in the action
portion of a rule definition, I could define new rules.  Sort of like
this:

(defrule i-am-a-rule
  (condition 1)
  (condition 2)
=
  (defrule subrule-1
(condition)
   =
(action))

  (action)
)


or

(defrule subrule-2 extends i-am-a-rule
  (condition)
=
  (action))


When you're dealing with a lot of rules, this kind of thing can really
help set up more complex nested if-then-if-then type stuff.

In addition, it would be cool (don't you love hearing that ;)  if you
could do this, instead of using salience:

(defrule rule-3
  (declare (overrides i-am-a-rule))
  (condition)
=
  (action))

The effect of that would be that for any given set of facts, if both
rule-3 and i-am-a-rule are activated, rule-3 fires, eliminating the
activation of i-am-a-rule.  

For a general and somewhat more specific rule that can match on the same
set of facts, there is no way to avoid using salience to perform the
discrimination, unless you break the matching up and use signaling
facts.  This is somewhat undesirable.  

RJ


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]



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]




Re: JESS: Subrules

2003-08-26 Thread ejfried
I think Judson, Ross wrote:
 From the wish-list department: I'd sure like it if, in the action
 portion of a rule definition, I could define new rules.  Sort of like
 this:
 
 (defrule i-am-a-rule
   (condition 1)
   (condition 2)
 =
   (defrule subrule-1
 (condition)
=
 (action))
 
   (action)
 )
 

You can achieve a quite similar effect using modules, optionally
including the auto-focus declaration.

(defmodule A)
(defrule A::i-am-a-rule
  (declare (auto-focus TRUE))
  (condition 1)
  (condition 2)
  =
  (action))

(defrule A::subrule-1
  (condition 3)
  =
   (action))

The rule subrule-1 won't fire unless the rule i-am-a-rule is satsfied
and grabs the module focus for module A. When any rules in A that
apply are through firing, focus returns to the previous module (or you
can use return to return earlier.) Module A is thus very much like a
complex, multi-rule daemon that runs whenever a set of conditions
are met.  I use a technique like this in JIA for the user-input module
in the Tax-forms Advisor in Part 3, and the Hardware Diagnostic
Assistant in Part 4.

 
 In addition, it would be cool (don't you love hearing that ;)  if you
 could do this, instead of using salience:
 
 (defrule rule-3
   (declare (overrides i-am-a-rule))
   (condition)
 =
   (action))
 

Interesting. This could certainly solve some common difficulties, and
you're right that it's less messy than the traditional alternatives.

Thanks for writing. You're usually a source of very good ideas!

-
Ernest Friedman-Hill  
Distributed Systems ResearchPhone: (925) 294-2154
Sandia National LabsFAX:   (925) 294-2234
PO Box 969, MS 9012 [EMAIL PROTECTED]
Livermore, CA 94550 http://herzberg.ca.sandia.gov



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]