Can I fire a partial set of rules? Say I have 3 rules: fastRuleA, fastRuleB, slowRuleC. What's the best way to only fire the group of fastRule1 and fastRule2? AgendaFilter looks like a good way of doing this, but: If between 2 rule fires, I change a fact, but change it back to it's original state, will the rule be not refire, just like if I hadn't changed it temporary? for example fact1 is used in slowRuleC: fireAllRules(); // fires slowRuleC fact1.a++; fact1.a--; fireAllRules(); // does not fire slowRuleC? Does still apply if I fire other rules meanwhile? fireAllRules(); // fires slowRuleC fact1.a++; fireAllRules(notSlowRuleCAgendaFilter); // slowRuleC is ignored // if I did not filter it out it would have fired of course fact1.a--; fireAllRules(); // does not fire slowRuleC? or does it? // a hasn't is the same since the last time slowRuleC was fired -- With kind regards, Geoffrey De Smet _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

latest ruleflow stuff has 'and', 'or' and 'xor' type logic to chose your branch points on a split - would that work for you? Mark Edson Tirelli wrote: > Geoffrey, > > Look at agenda-groups and rule-flows. > > []s > Edson > > > 2007/6/15, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com > <mailto:ge0ffrey.spam@gmail.com>>: > > Can I fire a partial set of rules? > Say I have 3 rules: fastRuleA, fastRuleB, slowRuleC. > What's the best way to only fire the group of fastRule1 and fastRule2? > AgendaFilter looks like a good way of doing this, but: > > If between 2 rule fires, I change a fact, but change it back to it's > original state, will the rule be not refire, just like if I hadn't > changed it temporary? for example fact1 is used in slowRuleC: > fireAllRules(); // fires slowRuleC > fact1.a++; > fact1.a--; > fireAllRules(); // does not fire slowRuleC? > > Does still apply if I fire other rules meanwhile? > fireAllRules(); // fires slowRuleC > fact1.a++; > fireAllRules(notSlowRuleCAgendaFilter); // slowRuleC is ignored > // if I did not filter it out it would have fired of course > fact1.a--; > fireAllRules(); // does not fire slowRuleC? or does it? > // a hasn't is the same since the last time slowRuleC was fired > > -- > With kind regards, > Geoffrey De Smet > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > -- > Edson Tirelli > Software Engineer - JBoss Rules Core Developer > Office: +55 11 3529-6000 > Mobile: +55 11 9287-5646 > JBoss, a division of Red Hat @ www.jboss.com <http://www.jboss.com> > ------------------------------------------------------------------------ > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ------------------------------------------------------------------------ _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users

geoffrey, If you change the field you don't have to let the engine know there was a change, its potentially dangerous, but as long as you are sure the actual "integrity" of the engine is not broken, then its fine. i.e. you can chage a field value and then change it back again, without telling the working memory it happened.

What is it about agenda groups that you think is slow?

Mark Geoffrey De Smet wrote: > [Sorry for reposting, didn't notice the original mail did come through > after all.] > > Agenda groups would probably work, but I am worried about the affects > on performance. > Take this pseudo code, using forward chaining: > > fireRules(fastAndSlowRulesAgenda); > for (Fact fact : factList) { // factList is very large > fact.number++; > fireRules(fastRulesAgenda); > // do some stuff(but don't change any facts) > fact.number--; > } > // at this point all the facts are identical as before the loop > aSingleFact.number++; > fireRules(fastAndSlowRulesAgenda); > > The main question is if drools will notice that nothing has changed > for the slowRules (except for aSingleFact.number) and won't spend time > on those (except for those that apply to aSingleFact.number). > > > (For the bigger picture, I have 2 distinct ways of possible improving > the localsearch algorithm and one of them is to use drools not just to > evaluate solutions but also generate moves and I wonder if this is > feasible.) > > With kind regards, > Geoffrey De Smet > > > Mark Proctor wrote: >> latest ruleflow stuff has 'and', 'or' and 'xor' type logic to chose >> your branch points on a split - would that work for you? >> >> Mark >> Edson Tirelli wrote: >>> Geoffrey, >>> >>> Look at agenda-groups and rule-flows. >>> >>> []s >>> Edson >>> >>> >>> 2007/6/15, Geoffrey De Smet <ge0ffrey.spam(a)gmail.com >>> <mailto:ge0ffrey.spam@gmail.com>>: >>> >>> Can I fire a partial set of rules? >>> Say I have 3 rules: fastRuleA, fastRuleB, slowRuleC. >>> What's the best way to only fire the group of fastRule1 and >>> fastRule2? >>> AgendaFilter looks like a good way of doing this, but: >>> >>> If between 2 rule fires, I change a fact, but change it back to >>> it's >>> original state, will the rule be not refire, just like if I hadn't >>> changed it temporary? for example fact1 is used in slowRuleC: >>> fireAllRules(); // fires slowRuleC >>> fact1.a++; >>> fact1.a--; >>> fireAllRules(); // does not fire slowRuleC? >>> >>> Does still apply if I fire other rules meanwhile? >>> fireAllRules(); // fires slowRuleC >>> fact1.a++; >>> fireAllRules(notSlowRuleCAgendaFilter); // slowRuleC is ignored >>> // if I did not filter it out it would have fired of course >>> fact1.a--; >>> fireAllRules(); // does not fire slowRuleC? or does it? >>> // a hasn't is the same since the last time slowRuleC was fired >>> >>> -- >>> With kind regards, >>> Geoffrey De Smet >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org> >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >>> >>> >>> >>> -- >>> Edson Tirelli >>> Software Engineer - JBoss Rules Core Developer >>> Office: +55 11 3529-6000 >>> Mobile: +55 11 9287-5646 >>> JBoss, a division of Red Hat @ www.jboss.com <http://www.jboss.com> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> rules-users mailing list >>> rules-users(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> rules-users mailing list >> rules-users(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users