[rules-users] some basic questions to grouping

psentosa psentosa at yahoo.com
Wed Aug 20 04:28:19 EDT 2008 

Edson, thanks a lot for your very enlightening explanation.
Wouldn't it be nice if the official DROOL documentation also include this
information? It would help people to create more effective rules, I think :)

Regards



Edson Tirelli-3 wrote:
> 
> 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
> 
> _______________________________________________
> 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-tp19048066p19064963.html
Sent from the drools - user mailing list archive at Nabble.com.

More information about the rules-users mailing list