Ouch! Right! What a way to start the New Year! In all of my previous emails please replace "recursion" with "refraction" - recursion is the self-addressing behavior of an algorithm. By way of explanation, I had been reading on the recursive principles of Rete that same day. I could blame it all on having a "senior moment" except that this has been happening since I was 13 years old, or somewhere near the beginning of puberty. :-)
Thanks for the clarification. SDG jco Paul Haley wrote: > FYI, the term "refraction" is traditional for the act of removing an > activation of a rule from the conflict set upon its execution. > > Paul Haley > President & CEO > The Haley Enterprise, Inc. > http://www.haley.com > (412) 741-6420 > Solutions that do what they're told. > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, January 05, 2003 12:57 PM > > To: [EMAIL PROTECTED] > > Subject: Re: JESS: Proposed feature > > > > > > I think James C. Owen wrote: > > > Ernest: > > > > > > Let me see if I can understand what we're actually saying here: As > > > written below, since ?fact is being modified in the RHS of the rule > > > then the rule will be placed on the agenda as available to be fired > > > again, even though the recursion principle would otherwise have > > > removed the rule from consideration.. This is basically the > > > data-driven concept of almost all Rete-type rulebased > > systems and some > > > that are not Rete-based. In fact, the rule will be removed > > (via the > > > recursion principle) from the agenda and never be replaced > > if the rule > > > fires and the data are NOT changed. Recursion is the first rule of > > > conflict resolution of both LEX and MEA and is used by, well, > > > everybody who builds a rulebased system of any kind of > > merit. (Jess, > > > JRules, OPSJ, JEOPS, Advisor, Expert, ART, etc., etc.) > > > > That's right. The current behavior in all cases is that a > > rule won't fire on a given set of unchanged facts more than once. > > > > > > > > So. Now. Are we asking that this should be changed so that if the > > > rules are slot-driven rather than data-driven,? Meaning > > that the rule > > > will be removed if the rule, regardless of data, fires? If so, it > > > can't work because then only one case would match. i.e., > > we would be > > > asking the question, "Is there ANY case" and when the case > > is answered > > > true then the engine stops. > > > > No, not quite. The proposal is for a new, special class of > > rules that will fire no more than once for a given set of > > facts, regardless of whether their slot data changes. > > Currently, modifying any slot in a fact on a rule's RHS will > > make the LHS match again. Under this proposal, this wouldn't > > happen for this special class of rules. > > > > In classical expert systems, facts were just tuples, without > > their own independent existence. In Jess, a fact is a lot > > more like an Object, and it persists over time. Note that in > > OPS-derived systems, where each fact has a numeric id, that > > id traditionally changed when a fact was modified. In Jess, > > the id -doesn't- change, highlighting the Object-ness of a fact. > > > > In a way, there are two different ways to think about Jess > > rules. You can be matching a fact with particular slot data, > > or you can be matching a particular fact object. The latter > > class of rules can sensibly be expected to match a given fact > > (or set of facts) only once; that's the class of rules for > > which the "one-shot" idea is useful. > > > > > > --------------------------------------------------------- > > Ernest Friedman-Hill > > Distributed Systems Research Phone: (925) 294-2154 > > Sandia National Labs FAX: (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] > > -------------------------------------------------------------------- > > > > > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- -- SDG jco --------------------------------- James C. Owen Senior KE Knowledgebased Systems Corporation 6314 Kelly Circle Garland, TX 75044 972.530.2895 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
