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))
)
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))
)
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:[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 [EMAIL PROTECTED]
--------------------------------------------------------------------
