Re: [PRD] PICK specification

Christian de Sainte Marie wrote:
> Gary,
>
> From your proposed spec for PICK, I understand that you prefer to 
> define the conflict resolution strategies at a larger grain than what 
> I proposed: assuming that your proposal for "repeatable" accounts for 
> "refraction" (but... see below), your proposal would specify one 
> parametrable, call it "forward chaining profile": 
actually, I would prefer 0 parameters unless somebody has a PR engine 
that doesn't do forward chaining (and we care enough to include that)

>
> However, regarding the repeat/no-repeat part properly said, I think 
> that there is a problem with the specification (or I do not understand 
> your proposal correctly, which is entirely possible).
>
> Gary Hallmark wrote:
>>
>> 1. one of the following is true:
>>    a. repeatable(rule(ri)) is true and age is the greatest i such 
>> that ri is in prior(c, i) and ri is in prior(c, i-1) and ... and ri 
>> is in prior(c, 0) and ri != picked(prior(c, i)) and ri != 
>> picked(prior(c, i-1)) and ... and ri != picked(prior(c, 1)), or
key conjunct:  and ri != picked(prior(c, 1)),
>>    b. repeatable(rule(ri)) is false and age is the greatest i such 
>> that ri is in prior(c, i) and ri is in prior(c, i-1) and ... and ri 
>> is in prior(c, 0) and rule(ri) != rule(picked(prior(c, i))) and 
>> rule(ri) != rule(picked(prior(c, i-1))) and ... and rule(ri) != 
>> rule(picked(prior(c, 1))), and
>
> As I read it, this says that, in any configuration, all the fireable 
> instances are in the agenda, and that the "age" of a particular 
> instance is the number of consecutive configurations in a row in which 
> it has been fireable since it has been last fired (if repeatable), or 
> since it or any other instance of the same rule has been fired (not 
> repeatable).
yes
>
> But, then, a rule that was just fired in c-1 and that is again 
> fireable in c will be in the agenda with age 0, whether repeatable or not.
not according to the "key conjunct" above.  Because ri = picked(prior(c, 
1)), the entire conjunction is false and there is no such i.  Therefore, 
your rule will not be in the Agenda in configuration c.
> For instance, if there is only one rule
> R1: if P(?x) then print(?x)
>
> and 2 facts: P(A) and P(B)
>
> If R is repeatable and your strategy is most recent first, you will have:
> A A A A A A .... or B B B B B ... depending on which is fired first
> and if you have least recent first, you will have:
> A B A B A... or B A B A B ... depending on which is fired first
>
> And if R is not repeatable, you will have a random sequence of A and B 
> printed.
>
> I am pretty sure that this is not what you intended: did I get 
> something wrong, or is, indeed, the proposed specification flawed?
>
> In a subsequent email, you say that the behaviour for repeatable rules 
> is the same as ILOG's refraction. That would be, as in the 
> specification that I proposed back before the FPWD, that a rule 
> instance that has been fired is *not* in the agenda if it has been 
> fireable ever since (that is, if its age is the number of 
> configurations that were traversed since it has been fired). Is that 
> what you meant?
yes, it is what I meant, and it is what I think I said :-)
>
> Btw, the specification I proposed back before FPWD correctly accounts 
> for ILOG's version of refraction: the example that you provided as 
> proof that it did not work is, really, about what Changhai calls 
> "repeatability" (and I wonder if we may not eventually find out that 
> it is the same repeatability as yours :-)
yes, I hope there is only 1 kind of repeatability (essentially, you just 
consider the rule part of the rule instance and ignore the variable 
bindings)
>
> The example was:
>
> RuleIncreaseLowSalary:
> If ?employe(hasSalary->?x) and ?x < 1000 then increase salary by 10%
>
> and there is one fact: John(hasSalary->100)
>
> According to the version of refraction that I proposed (under the 
> misnommer "no-repeat"), the rule would fire again and again until 
> John's salary has been increased to more than 1000 (since ?x binds to 
> a new value in each new configuration). This is obviously not the 
> intended behaviour.
But we agree it is the behavior you get if you specify repeatable=true, yes?
>
> But consider the similar rule:
>
> RuleAccelerateTo200:
> If ?car(speed->?x and ?x < 200 then increase ?x by 10%
>
> and there is one fact: MyRacingCar(speed->100)
>
> In that case, the intended behaviour is, indeed, that the speed of 
> MyRacingCar is increased until it passes 200!
>
> The difference is not in refraction, which has no role here since ?x 
> binds to different values in each configuration, in both cases, but 
> whether or not the rule is repeatable: in the case of John's salary, 
> the rule is meant to be non repeatable; in the case of MyRacingCar, it 
> is meant to be repeatable.
yes
>
> Notice that in the example of R1, above, refraction would make the 
> printed result be
> A B or B A depending on which fires first, and repeatability has no 
> role (since refraction does the trick).
>
> We wil ldiscuss this in Orlando.
Bon voyage!  Dare I say I think we are converging here...

Received on Tuesday, 28 October 2008 05:27:53 UTC