Wolfgang wrote: "It seems that the object facts are retracted all right if some slot c.m is reduced, but this does not trigger the second rule."
**** Why not? This certainly is the case in Haley's eclipse-rule engine (Eclipse is a derivative of Nasa Clips), which may be different on some points but not on this one I believe. Any change in the conflict-set will create new activations, whether they are positive or negative. At least that's what I believe will happen and what I know will happen in Haley's rule engine. Correct me if I'm wrong. Martijn > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Wolfgang Laun > Sent: woensdag 20 februari 2008 15:41 > To: [email protected] > Subject: Re: JESS: Rules for detecting changes of a multislot > > Martijn Tromm wrote: > > >Lars, > > > >With activations and retractions I was thinking about something like > this: > > > >For every object in (c (m a b c)) assert a separate relation-fact > (object ?x) and keep a object-status template-fact for reference. Once > an object gets asserted it will be remembered by a object-status fact > with a status present/not-present. > > > > > >(defrule infer-object) > > (logical (c (m ? ?x ?))) > > => > > (assert (object ?x)) > >) > > > You'll have to use (logical (c (m ?$ ?x ?$))) or else it'll match only > lists with a length of three. > > > > >If an object gets removed from the list, the object-fact will > automatically be retracted. I'm not quite sure of the syntax though (it > has been a while). And I hope it works for templates with multi-slots. > > > >(defrule object-status-present-first-time > > (object ?x) > > (not (object-status (obj ?x) (status ?s))) > > => > > (assert (object-status (obj ?x) (status present))) > >) > >(defrule object-status-not-present > > ?os <- (object-status (obj ?x) (status p)) > > (not (object ?x)) > > => > > (modify ?os (status not_present)) > >) > >(defrule object-status-present-again > > (object ?x) > > ?os <- (object-status (obj ?x) (status not_present)) > > => > > (modify ?os (status present)) > >) > > > > > It seems that the object facts are retracted all right if some slot c.m > is reduced, but this does not trigger the second rule. > > Also, note that if you change a multislot that contains, say (m x y) by > (modify ?some-c-fact (m x)), the final (object x) won't be the same > object as the original (object x). Both (object x) and (object y) are > thrown away, and then a new (object x) is created. > > -WL > > >This way you only have to manipulate the c-template and a memory- > status will automatically be kept. The moment you react to the status- > changes depends on the salience of reaction-rules. (Similar to the rule > do-something-when-something-gets-removed-from-c) > >I don't think this is very inefficient. Furthermore you don't need > cleanup rules, just three rules for administration purposes. > > > >Martijn > > > > > > > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] [mailto:owner-jess- > [EMAIL PROTECTED] > >>On Behalf Of Ernest Friedman-Hill > >>Sent: woensdag 20 februari 2008 13:31 > >>To: jess-users > >>Subject: Re: JESS: Rules for detecting changes of a multislot > >> > >>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 owner-jess- > >>>>[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 owner-jess- > >>>[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 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 owner-jess- > [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 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] --------------------------------------------------------------------
