Re: [PRD] PICK specification

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": apply refraction with or w/o repetition, then select the instances with the highest priority, then select the instances most/least recently in the agenda; whereas I proposed to define the elements (refraction, recency, priority etc) separately, and a simple way to combine them (as a sequence).

Changhai also prefers a limited number of profiles to the more flexible, but more burdensome specification I proposed initially.

If the other PRD people are of the same opinion, that would probably make our job easier. So, *Mark*, *Paul*, *Adrian*, etc, what do you think? This could be an easy resolution to discuss in Orlanda.

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
>    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).

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. 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?

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 :-)

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

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.

Cheers,

Christian

Received on Tuesday, 28 October 2008 04:31:15 UTC