Mark Proctor wrote:
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.
I need to change it and tell the working memory for a fast agenda group,
so I can run the fast agenda group's rules.
Afterwards I change it back, and the slow agenda group's rules shouldn't
need to start the rematching process?
Maybe what I really need would be something like:
workingMemory.update(factHandle, fact, agendaGroup)
Another solution would be to "take a snapshot of the pattern matches"
and then "revert back to it" - but that's crazy to implement.
A third solution is that I take a clone of the working memory, and do
the fast agenda group on that one, so it doesn't affect the working
memory of the slow agenda group.
What is it about agenda groups that you
think is slow?
With kind regards,
Geoffrey De Smet
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 <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>:
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
[email protected] <mailto:[email protected]>
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
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/rules-users
