From: Gary Hallmark <gary.hallmark@oracle.com>

Date: Mon, 27 Oct 2008 22:26:51 -0700

Message-ID: <4906A29B.7010602@oracle.com>

To: Christian de Sainte Marie <csma@ilog.fr>

CC: RIF WG <public-rif-wg@w3.org>

Date: Mon, 27 Oct 2008 22:26:51 -0700

Message-ID: <4906A29B.7010602@oracle.com>

To: Christian de Sainte Marie <csma@ilog.fr>

CC: RIF WG <public-rif-wg@w3.org>

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 GMT

*
This archive was generated by hypermail 2.2.0+W3C-0.50
: Tuesday, 2 June 2009 18:33:57 GMT
*