[rules-users] some basic questions to grouping

Tue Aug 19 13:30:21 EDT 2008

1. Rete network is built at rulebase "compile" time, i.e., when you add
packages to the Rulebase:

ruleBase.addPackageFromDrl( ... ); // and similar API calls

   At assert time, the facts are propagated and when you call
fireAllRules(), active rules are fired.

2. These are part of the internal optimization algorithms. Let me try to
simplify things, but talking about 2 optimizations we have:

* node sharing: every time you have the same condition (even among different
rules), the engine will try to share them, so that you have it executed only
once. Writing conditions in the same order helps to achieve this. So, for
the first example, when you have the Gender constraints, it will share the
Gender.FEMALE constraints among the 1000 rules and will execute it only
once. The Gender.MALE constraint is also executed once, and then you have 2
executions in total.

* alpha hashing: this is a bit more complicate, but when you have mutually
exclusive constraints on the same field, you know that only one of them is
correct. So, if you have 100 different constraints like this:

Person( countryOfBirth == Country.CANADA...
Person( countryOfBirth == Country.BRAZIL...

You know that only one of them will be true. The engine detects that and
instead of evaluating every constraint, where 99 of them will fail, it will
hash all the constraints.
Then, when a fact is asserted (lets say contryOfBirth is BRAZIL), instead of
going through all the constraints, it applies the hash function on the
attribute value (BRAZIL) and knows where the constraint is. So it will only
evaluate that constraint and forget about the others, since they will fail
anyway.

Having said that, the first example (gender) is also mutually exclusive, but
there are only 2 possible values. What happens is that there is a cost to
calculate the hash value on the alpha hashing optimization and the cost does
not pay off if you have only 2 possible values. In fact, after doing some
research we found that the ideal cardinality to activate the alpha hashing
optimization is 3, but that is a parameter you can configure using
RuleBaseConfiguration (either by API or by a system property). So, by
default, that optimization only kicks in when you have 3 or more possible
values (like the country of birth) and not with 2 or less (like gender).

3. Sorry, I don't see your attachement. But anyway, rule-flow, agenda-groups
and etc are used to control rule "firing" order, not rule evaluation. Rete
will evaluate your rules eagerly, even if your group is not active. In your
case, with mutually exclusive constraints in your patterns, you should not
worry about that. Let the engine optimize the matching for you. If you find
performance problems, then come back and we can see if there is any
sub-optimal rules in your rule set. Until then, don't worry with it.

[]s
Edson

2008/8/19 psentosa <psentosa at yahoo.com>

>
> Jakob, Edson, thanks a lot for your replies especially on agenda vs
> activation-group :)
>
> But please allow me to ask some further questions:
> 1. The LHS of the rules is evaluated at "assert time".
> When is actually the RETE network built? On assertion, will a fact then be
> propagated over the network?
>
> 2. The example with Gender and countryOfBirth:
>    For the gender example, you said the condition will be executed only
> twice. So I assumed it's because there are 2 possibilities of gender. But
> the example with countryOfBirth with 100 possibilities, why only once?
>
> 3. Back to my problem I described before:
>   Before I read your reply (Edson's), I try to follow the suggestion from
> Jakob, namely using the ruleflow-group. So I came up with a the
> ruleflow-graph I attached (please have a look if you don't mind)
> http://www.nabble.com/file/p19053522/regulation-check.rfm
> regulation-check.rfm<http://www.nabble.com/file/p19053522/regulation-check.rfmregulation-check.rfm>. I try to describe the following hierarchy:
> There are certain rules only for young people; if they are older, than it
> will be checked, whether he/she is a male/female. Another group of rules is
> only valid for females, the rest of the rules are valid for both male and
> female. does the graph correspond correctly to the problem I describe? Is
> it
> better to use such grouping or like you said, just write my patterns and
> constraints as much as possible (without the grouping)?
> Again thanks in advance!
>
> Regards
>
>
>
>
> Edson Tirelli-3 wrote:
> >
> > 1. when you are saying "rules fire", does this mean: matching/checking
> the
> > LHS of rule, or executing the RHS of rule
> >
> > Means execute the RHS. The LHS of the rules is evaluated at "assert
> time".
> > Take a look at the docs for more info on that.
> >
> > 2. I plan to use the grouping features of drools, but still not sure..
> >
> > First a quick explanation:
> > * agenda-groups allow you to control in what order rules are **fired**,
> > because only rules from the active agenda-group are allowed to fire.
> > * activation-groups allow you to create mutually exclusive rules, because
> > when a rule in an activation-group **fires**, it cancel all other
> > activations in the same group.
> >
> > None of it is what you want. In fact, you should not worry about the
> cases
> > you described. Just write your patterns and constraints in the same order
> > as
> > much as possible, and also always write more constraining patterns
>  before
> > the more general patterns and let the engine do its magic.
> >
> > If you have 1 rule where gender is Gender.MALE, and 1000 rules where it
> is
> > Gender.FEMALE and you assert a male (or female, dos not matter) Person,
> > the
> > engine will execute the condition only twice, because it shares the
> > Gender.FEMALE constraint among all the rules, assuming you write the
> > constraints in the same order. An even more interesting situation is:
> > pretend you have some kind of discriminating attribute for person, like
> > countryOfBirth, and you have 100 rules for each country that you have to
> > handle (lets say 100). So, you have 100 x 100 = 10000 rules:
> >
> > Rule x1 when Person( countryOfBirth == Country.CANADA...
> > ...
> > Rule x500 when Person( countryOfBirth == Country.BRAZIL...
> > ...
> >
> > Guess how many times that condition will be executed for a Person whose
> > country is CANADA (or any other country, does not matter)? Only **once**,
> > because of an optimization called alpha hashing.
> >
> > Now range conditions are not hashed, but they still have node sharing, so
> > as
> > long as you write them in the same order, they are still optimized. The
> > only
> > problem you will have is if you start using accumulate and collect, that
> > are
> > really expensive in terms of performance. In cases like that, you will
> > need
> > a manual optimization, but it is still doable.
> >
> >    Hope it helps.
> >
> >          Edson
> >
> >
> > 2008/8/19 psentosa <psentosa at yahoo.com>
> >
> >>
> >> Hi,
> >>
> >> I'm having some difficulty to understand the concept of grouping, but
> >> maybe
> >> it's only because of my understanding of the terms, so please apologize
> >> for
> >> the silly question
> >> 1. when you are saying "rules fire", does this mean: matching/checking
> >> the
> >> LHS of rule, or executing the RHS of rule
> >>
> >> 2. I plan to use the grouping features of drools, but still not sure
> >> whether(and how) to use the agenda or activation group (or even the
> >> rule-flow). My problem domain is actually quite simple:
> >> - rules are applied based on e.g age of a person. Now, there are some
> >> rules
> >> for 17-year-or older, and some for 30-year-old person, if I'm to use the
> >> agenda group, I'd define the following:
> >>
> >> rule1
> >> agenda-group "17 years-old or older"
> >> when
> >>     p:Person (Age > 17)
> >> ....
> >>
> >> rule2
> >> agenda-group "17 years-old or older"
> >> when
> >>     p:Person (Age > 17)
> >> .....
> >>
> >> rule3
> >> agenda-group "30 years-old or older"
> >> when
> >>     p:Person (Age > 30)
> >> ......
> >>
> >> rule4
> >> agenda-group "30 years-old or older"
> >> when
> >>     p:Person (Age > 30)
> >> ......
> >>
> >> If I assert a person into the WM to check his/her age, I want that only
> >> the
> >> rules in 30-years-old agenda are CHECKED (and eventually executed when
> >> the
> >> other constraints are fulfilled), bcs they are surely older than 17 as
> >> well.
> >> And this is not only for comparing ages. Another example, some rules are
> >> only for Gender.MALE, and some only for Gender.FEMALE. So if a person is
> >> asserted, only the rules with corresponding gender will be checked and
> no
> >> need of checking/matching the other group
> >> The main purpose is just to skip checking unrelevant rules (imagine if
> >> there
> >> is only 1 rule for MALE and 1000 rules for FEMALE with 1000 times WHEN
> >> person (gender == FEMALE) checking for an asserted male-object).
> >> How can I do this effectively? Or will ALL rules checked and only the
> >> order
> >> of checking (and eventually exection of their RHS) is defined by the
> >> grouping?
> >>
> >> I hope I've described my problem clearly and I'll try to explain this
> >> again
> >> in case of difficulty :)
> >> Thanks in advance
> >>
> >> Regards
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/some-basic-questions-to-grouping-tp19048066p19048066.html
> >> Sent from the drools - user mailing list archive at Nabble.com.
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >>
> >
> >
> >
> > --
> > Edson Tirelli
> > JBoss Drools Core Development
> > JBoss, a division of Red Hat @ www.jboss.com
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/some-basic-questions-to-grouping-tp19048066p19053522.html
> Sent from the drools - user mailing list archive at Nabble.com.
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>

-- 
Edson Tirelli
JBoss Drools Core Development
JBoss, a division of Red Hat @ www.jboss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080819/a91f39b8/attachment.html 