Re: [PRD] Default conflict resolution strategy (ISSUE-64) (Was; Re: [Fwd: Re: PRD Review])

(deftemplate person (slot age) )
(defrule rule1 (declare (no-loop TRUE)) (person (age ?a) ) => (assert 
(person (age (+ ?a 1) ) ) ) (printout t fire " " rule1) )
(assert (person (age 200) ) )
(run)

I made the above example to test our Jess. What do we do about clips? I 
guess no-loop can be simulated with objects acting as semaphores on the 
LHS pattern constraints.

Mark

Gary Hallmark wrote:
> Christian de Sainte Marie wrote:
>>
>> Gary Hallmark wrote:
>>>>
>>>> Mark Proctor wrote:
>>>>>
>>>>> Refaction in JRules is the same as jess/clips/drools no-loop. 
>>>
>>> I'd be surprised if it is exactly the same.   What do you expect 
>>> from the following ruleset:
>>>
>>> p(1)
>>> q(1)
>>> q(2)
>>> (* rule1[loop->false] *)
>>> Do(external(print("rule1 fired, ?x=" ?x))) :- q(?x)
>>> (* rule2[loop->false] *)
>>> Do(Retract(p(1)) p(1) external(print("rule2 fired, ?x=" ?x))) :- 
>>> And(p(1) q(?x))
>>
>> I guess you mean:
>> rule1: if q(?x) then print("rule1 fired, ?x=" ?x)
>> rule2: if p(1) and q(?x) then Retract(p(1)), Assert(p(1)), print 
>> ("rule2 fired, ?x=" ?x)
>>
>> Hey, Gary, this is not in the spec, you can write them rules in a way 
>> that makes sense :-)
> I think we'll need to speak somewhat formally here to be sure we 
> understand each other.
>>
>>> With Oracle/Jess, you get
>>> rule2 fired, ?x=2
>>> rule1 fired, ?x=2
>>> rule1 fired, ?x=1
>>
>> With JRules, you bind only objects, so, the example does not really 
>> work.
>>
>> But if you could bind primitive data types, (I have to check, but I 
>> think) 
> I think you'd better check.
>> that you would fire rule2 with ?x=1 as well. 
> Do you mean rule2 fires twice, once with ?x=1 and once with ?x=2?  
> That demonstrates a difference in semantics.  As I said, with Oracle 
> and Jess, rule2 fires once with ?x=2 (because ?x=2 is the more recent 
> binding)
>> And that is certainly what you would get with the semantics that was 
>> described in PRD.
> Please clarify whether you mean rule2 fires once or twice, and then 
> please "prove" it using the PRD semantics.  I don't see how PRD can 
> give the Oracle/Jess semantics without some substantial changes.  PRD 
> assumes that mergeInstances is not called between actions of the same 
> rule; yet in Oracle/Jess (and most engines, I think) the agenda is 
> modified by individual actions and this is why when the (actions of 
> the) first instance of rule2 is executed, the second instance is 
> removed.  But when the first instance of rule1 is executed, nothing 
> happens to the second instance of rule1 and so rule1 is executed twice.
>>
>>> The semantics of Oracle/Jess is that a rule's actions cannot 
>>> re-activate that rule.  Initially, because of the input data, rule1 
>>> and rule2 each have 2 activations.  When rule2 fires, the retraction 
>>> removes the other rule2 activation.  The assert action cannot 
>>> reactivate rule2 because of the no-loop property.
>>
>> I do not understand that. I mean, I do not understand the intended 
>> behaviour: do you mean that p(1) after rule2 has been fired is 
>> distinct from p(1) before, and that, somehow, the engine recognizes 
>> the difference? Does this have to do with the assertion being logical 
>> (and the engine tracing the origin of it)? I mean, as in a TMS: Jess 
>> has a TMS facility, right? I have to check how we handle refraction 
>> (or equivalent) wrt logical statements in JRules...
> No, it has to do with the fact that even though the initial and final 
> states of the sequence of actions Do(Retract(p(1)) p(1)) are the same 
> (assuming p(1) exists in the initial state), this sequence of actions 
> is different from Do().  And this difference is not accounted for in 
> the semantics.  This difference is needed to explain the Oracle/Jess 
> no-loop semantics.
>>
>>> We need to carefully specify these strategies to be sure we agree 
>>> what they are, and then we need to see what the intersection is, and 
>>> if it is  >= 1, give it an explicit name(s) (and probably not in the 
>>> metadata as my example does).
>>
>> Absolutely agree.
>>
>>
> BTW, Oracle/Jess does not support all-at-once rule firing, other than 
> by aggregation.  Nor do they support random firing. I think these are 
> rare features, and do not merit standardization. 
I'm ok with that. These are mostly hacks to get over the overhead of a 
single agenda, I think more research needs to be done here that more 
strongly supports parallelisation techniques for PR systems.

Received on Wednesday, 30 July 2008 00:25:04 UTC