It depends on whether you know a priori what objects can be added to the list if you can use a rule with a not-condition without extra facts (to be exact you need one: a fact with a list of all possible objects). Otherwise you need shadow-facts like I did in the previous example. Every piece of knowledge you want the rules to have, must be made explicit.
Martijn > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Alexander Pokahr > Sent: woensdag 20 februari 2008 14:52 > To: [email protected] > Subject: Re: Re: JESS: Rules for detecting changes of a multislot > > Dear all, > > I like the proposal of "reifying" the remove action > as a separate fact. I haven't thought about that. > > But I would rather go for option #2 if possible, given > that Jess already implements the kind of "time machine" > required for that. It is called "Rete network" and can > be activated by the magic "not condition" switch. ;-) > > Using the existing features of the Rete match algorithm seems > more clean to me, because I wouldn't have to introduce > new facts. But in the case at hand I'm not sure if there > is a suitable rule with a not condition, that can achieve > the desired effect. Any ideas on this would be very welcome. > > Cheers, > Alex > > > Ernest Friedman-Hill schrieb: > > <div class="moz-text-flowed" style="font-family: -moz-fixed">Lars, > > > > If you think about it, there are only two ways to write a rule to > > react to the absence of data: > > > > 1) Remember what the data was, so you can compare the present > > situation to the previous situation; > > 2) Use a time machine, travel back in time, find out what the data > > used to be, then come back to the present. > > > > Of these, only #1 is practical to implement in software. :) This > isn't > > a problem with Rete; it's a problem with the fabric of reality. > > Unfortunate, but it's something we've got to live with. Unless you > can > > come up with a way to build a time machine, you have to remember the > > past if you're going to act on it. > > > > But Martijn actually gave you two suggestions. The first one is my #1 > > above, which you've responded to as being inefficient. > > > > The second one is not to react to changes, but to *participate* in > the > > changes, as they're happening. You need to make the changes explicit. > > I don't think I'd do it quite the way that Martijn suggests, though. > > But the basic idea is the same: it's too late to react to the change > > after the change has been made; you have to react to the change > *while > > the change is being made.* For example, you could use explicit > command > > facts to remove items from the multislot, and one or more rules to > > process the commands. So instead of saying > > > > (defrule remove-something-from-c > > ?c <- (C (m ?a ?b ?c)) > > = > > (modify ?c (m ?a ?c))) > > > > You'd say something like > > > > (defrule want-to-remove-something-from-c > > ?c <- (C (m ?a ?b ?c)) > > = > > ;; Instead of modifying ?c, issue a command to do so > > (assert (remove ?c ?b))) > > > > (defrule actually-remove-things-from-c > > "Process commands to remove items from multislot m of C facts" > > (declare (no-loop TRUE)) > > ?c <- (C (m $?first ?x $?rest)) > > (remove ?c ?b) > > = > > (modify ?c (m $?first $?rest))) > > > > (defrule do-something-when-something-gets-removed-from-c > > "This is the rule you were asking about how to write" > > ?c <- (C (m $?first ?x $?last)) > > (remove ?c ?x) > > = > > (do whatever you want to do here)) > > > > (defrule clean-up-remove-commands > > "A low salience rule to clean up remove commands when you're done > > with them." > > (declare (salience -1)) > > ?r <- (remove ? ?) > > = > > (retract ?r)) > > > > > > > > > > On Feb 20, 2008, at 5:09 AM, Lars Braubach wrote: > > > >> Hi, > >> > >> thanks for your reply Martijn. The solution should work > >> but is also rather inefficient because all facts would have > >> be stored twice. Maybe some Rete expert could argue, if such > >> a rule could be expressed direcly in a rete network (not considering > >> the specification language). If this is possible it might indicate > >> that just the CLIPS/JESS language is insufficient for expressing > such > >> kind of behavior. > >> > >> Kind regards, > >> Lars > >> > >> Martijn Tromm schrieb: > >>> Hi, > >>> > >>> You must either keep the same data in another slot for reference > like: > >>> (C (m a b c) (m-old a b c d)) Now you can compare old and new and > >>> detect changes between. (actually you store the mutation this way) > >>> > >>> Or I think you have to store each object in a separate fact and > keep > >>> track of changes through activations (addition) or retractions and > >>> logical dependencies (removal). > >>> > >>> Regards, > >>> Martijn > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: [EMAIL PROTECTED] [mailto:owner-jess- > [EMAIL PROTECTED] > >>>> On Behalf Of Lars Braubach > >>>> Sent: dinsdag 19 februari 2008 10:34 > >>>> To: [email protected] > >>>> Subject: JESS: Rules for detecting changes of a multislot > >>>> > >>>> Hi, > >>>> > >>>> I am trying to design a rule that is able to detect > >>>> when a single fact of a multislot is added/removed. > >>>> Given that the contained multislot values are > >>>> backed with Java objects I would also like to > >>>> know which fact has been added/removed. > >>>> > >>>> (deftemplate C (multislot m)) > >>>> (deffacts facts > >>>> (C (m a b c)) > >>>> ) > >>>> > >>>> For the addition of values I could figure out > >>>> a rule that does what I want, but its unclear > >>>> to me how this could be achieved for the removal > >>>> of values. (The addition rule simply uses a pattern > >>>> (? ?fact ?) in order to generate bindings for > >>>> each element of the multislot.) > >>>> > >>>> Any ideas how this could be achieved? > >>>> > >>>> Kind regards, > >>>> Lars > >>>> > >>>> -- > >>>> Psssst! Schon vom neuen GMX MultiMessenger gehört? > >>>> Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger > >>>> > >>>> ------------------------------------------------------------------ > -- > >>>> 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 owner-jess- > >>>> [EMAIL PROTECTED] > >>>> ------------------------------------------------------------------ > -- > >>>> > >>>> > >>>> No virus found in this incoming message. > >>>> Checked by AVG Free Edition. > >>>> Version: 7.5.516 / Virus Database: 269.20.7/1286 - Release Date: > 18-2- > >>>> 2008 18:49 > >>>> > >>> > >>> No virus found in this outgoing message. > >>> Checked by AVG Free Edition. > >>> Version: 7.5.516 / Virus Database: 269.20.7/1286 - Release Date: > >>> 18-2-2008 18:49 > >>> > >>> > >>> ------------------------------------------------------------------- > - > >>> 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] > >> -------------------------------------------------------------------- > > > > --------------------------------------------------------- > > Ernest Friedman-Hill > > Informatics & Decision Sciences Phone: (925) 294-2154 > > Sandia National Labs FAX: (925) 294-2234 > > PO Box 969, MS 9012 [EMAIL PROTECTED] > > Livermore, CA 94550 http://www.jessrules.com > > > > -------------------------------------------------------------------- > > 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] > > -------------------------------------------------------------------- > > > > </div> > > -------------------------------------------------------------------- > 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 owner-jess- > [EMAIL PROTECTED] > -------------------------------------------------------------------- > > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.516 / Virus Database: 269.20.8/1288 - Release Date: 19-2- > 2008 20:47 > No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.20.8/1288 - Release Date: 19-2-2008 20:47 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
