Ah.  Should have paid more attention to the details.

This has been a tremendous help and my rules make much more sense and don't
have that really ugly feel to them.

Thanks!


On 9/7/07 10:32 AM, "Ernest Friedman-Hill" <[EMAIL PROTECTED]> wrote:

> 
> On Sep 7, 2007, at 1:01 PM, Hal Hildebrand wrote:
> 
>> I guess I'm more than a little confused as to the "(templates $? ?t
>> $?)"
>> syntax.
> 
> Remember that the first time a variable is used, it matches
> whatever's there, and subsequent uses of that same variable match
> only whatever the first usage matched. The order of patterns can be
> very important for this reason!
> 
> The above slot pattern matches "anything, followed by something (call
> it "?t"), followed by anything else." In other words, this rule will
> match each individual item in the list, one match for each item.
> 
>> I would have expected that I could have rewritten the rule Wolfgang
>> provided to:
>> 
>> (defrule makeTransforms
>>     ?s <- (source (id ?id) (templates $? ?template $?))
> 
> So far, so good...
> 
>>     (not (transform (source ?id)))
> 
> This pattern says "If there are no 'transform' facts with the given
> id," The first time this rule fires, there *will* be such a fact, so
> it won't fire anymore, right? You need to write "If the fact this
> rule will create doesn't exist yet" which would look like
> 
>      (not (transform (source ?id) (template ?template)))
> 
> 
>> 
>> Worse however, regardless of whether I use the original
>> makeTransform rule
>> that Wolfgang proposed or the rewrite I did above, if I combine the
>> makeTransforms and your removeTransforms, I end up in a system
>> which goes
>> into an endless loop from simply asserting one source.  Here's the
>> full
>> test:
> ...
>> (defrule removeTransforms
>>     ?t <- (transform (source ?id) (template ?t))
>>     (not (source (id ?id)(templates $? ?t $?)))
>>     =>
>>     (retract ?t)
>>     )
>> 
>> 
> 
> My bad. I made a mistake in the above: I used ?t as the name of both
> the variable bound to the transform fact, as well as the variable
> bound to the template slot. The second pattern never matches, as
> there's no "templates" slot that contains 'transform' fact references!
> 
> The correct rule would be more like
> 
> (defrule removeTransforms
>      ?t <- (transform (source ?id) (template ?template))
>      (not (source (id ?id)(templates $? ?template $?)))
>      =>
>      (retract ?t)
>      )
> 
> 
>> On 9/7/07 9:11 AM, "Ernest Friedman-Hill" <[EMAIL PROTECTED]> wrote:
>> 
>>> Same idea:
>>> 
>>> (defrule removeTransforms
>>>      ?t <- (transform (source ?id) (template ?t))
>>>      (not (source (id ?id)(templates $? ?t $?))
>>> =>
>>>      (retract ?t))
>>> 
>>> 
>>> On Sep 7, 2007, at 11:57 AM, Hal Hildebrand wrote:
>>> 
>>>> Doh!  That does work well and I'll certainly replace my cheesy
>>>> solution with
>>>> this, but one of the issues I'm dealing with is that the set of
>>>> templates
>>>> can change and I would like to ensure that as changes to the list of
>>>> templates occur, the corresponding transforms are asserted or
>>>> retracted.
>>>> Sorry, this is an additional constraint I would like to satisfy
>>>> that I
>>>> should have noted.
>>>> 
>>>> 
>>>> On 9/7/07 8:28 AM, "Wolfgang Laun" <[EMAIL PROTECTED]>
>>>> wrote:
>>>> 
>>>>> Assuming that the absence of any "transform" fact with a "source"
>>>>> slot
>>>>> equal to the "id" slot of a new "source" fact is the criterion for
>>>>> creating the "transform" facts:
>>>>> 
>>>>> (defrule makeTransforms
>>>>>     ?s <- (source (id ?id)(templates $?templates))
>>>>>     (not (transform (source ?id)))
>>>>> =>
>>>>>     (foreach ?temp $?templates
>>>>>         (assert (transform (source ?id) (template ?temp))))
>>>>> )
>>>>> 
>>>>> kr
>>>>> Wolfgang
>>>>> 
>>>>> Hal Hildebrand wrote:
>>>>> 
>>>>>> I have a system where I need to ensure that for every member of a
>>>>>> list,
>>>>>> there is a fact which contains that member.  For example, here's
>>>>>> my domain:
>>>>>> 
>>>>>> 
>>>>>> (deftemplate source (slot id) (multislot templates))
>>>>>> (deftemplate transform (slot source) (slot template))
>>>>>> 
>>>>>> 
>>>>>> What I would like is to write some rules that ensure that for
>>>>>> ever member of
>>>>>> the templates slot of a "source", I have a corresponding
>>>>>> transform.  If I
>>>>>> assert:
>>>>>> 
>>>>>> (assert source (id 1) (templates (create$ a b c)))
>>>>>> 
>>>>>> I would like to see three facts asserted in response:
>>>>>> 
>>>>>> (assert transform (source 1) (template a))
>>>>>> (assert transform (source 1) (template b))
>>>>>> (assert transform (source 1) (template c))
>>>>>> 
>>>>>> 
>>>>>> I have accomplished this by creating an intermediary fact and
>>>>>> some rules
>>>>>> which essentially cycle through the list of templates in the
>>>>>> source,
>>>>>> asserting a transform for each.  However, this just feels wrong.
>>>>>> It seems
>>>>>> like I should be able to express this without the intermediary
>>>>>> facts.
>>>>>> 
>>>>>> Perhaps this is where backward chaining would be useful?  Or
>>>>>> perhaps I can
>>>>>> use the new "accumulate" CE?  Or, have I already found the
>>>>>> solution using an
>>>>>> intermediary fact to cycle through the list of templates?
>>>>>> 
>>>>>> Any help/suggestions would be appreciated.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------
>>>>>> --
>>>>>> 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]
>>>>> -------------------------------------------------------------------
>>>>> -
>>>>> 
>>>> 
>>>> 
>>>> --------------------------------------------------------------------
>>>> 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
>>> Advanced Software Research          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]
>>> --------------------------------------------------------------------
>>> 
>> 
>> 
>> --------------------------------------------------------------------
>> 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
> Advanced Software Research          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]
> --------------------------------------------------------------------
> 


--------------------------------------------------------------------
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]
--------------------------------------------------------------------

Reply via email to