Re: [rules-users] [SOLVED] Too many ACTIVATION "candidates"

One way of detecting cartesian products is to model the LHS as a graph, with object patterns being nodes, and conditions that compare two objects being an edge. If the LHS graph has unconnected subgraphs then it contains a cartesian product. You can make this more sophisticated by excluding classes that you know have few instances in working memory, like control objects. GreG On Dec 23, 2010, at 3:37, "Swindells, Thomas" <TSwindells(a)nds.com&gt; wrote: >>> I'd say that this rule should actually be written as 16 rules - one >>> for >>> each of the or'd together GoodsItems conditions, each of these rules >>> would >>> only depend on a single Fact and you won't get into this problem. >> >> True. This rule can be re-written as a series of 5 rules that do not >> exhibit the explosion of activation candidates. I have done so and >> everything worked fine. >> >>> >>> Who controls the custom interface? If you can control then the >>> simplest >>> solution is to prevent them doing or's of conditions (though perhaps >>> this >>> may not fly with your customers). Alternatively have the interface >>> output >>> an intermediate form which you can then control the compilation of. >> >> The custom interface, you may think of it as a simplified Guvnor, is >> under >> my total control as I've implemented it. >> The problem is, that the user can use it to write these kinds of rules. >> In theory, rule rewriting could be possible, but I'm not sure I can >> detect >> these kinds of dependencies for any kind of rule that may be written. > > No, I think they should be rewritten as a series of 16 rules (one for > each '||'. > You could remove the option from the user of being able to 'or' together > conditions and require each thing to be written as separate rules. This > should reduce the Cartesian products for the majority of cases (although > creative users could still possibly write statements like (fact1 != > "thiswillneverhappen" && fact2 != "thiswillneverhappen2"...)/ > >> It there is a way that these kinds of cartesian product of activation >> candidates can be estimated before hand (either by analyzing the rule >> or >> by some other means), it would be great. >> Any ideas are welcomed. > It depends on how accurate you want it. > Simplist option is to restrict the number of facts that a rule can match > against (if they can only match against 3 facts the Cartesian product > probably isn't too bad). > Slightly more complicated you can assume the worst case scenario that > every value of each fact type is included and multiple the count of each > included fact together, if it exceeds a configured limit you decide that > potentially the rule is too complicated. > Getting much more complicated is to perform a much more accurate > estimation of each fact based upon the constraints. You could either do > this in code (perhaps a db query or some other way to apply the > constraint). > Another way to do this would be to decompose the rules so that you > accumulate the result of each fact constraint first, check whether too > many facts have been included and then use a from for each accumulation > at the end (or something like that anyway). > > Thomas > > > ************************************************************************************** > This message is confidential and intended only for the addressee. If you > have received this message in error, please immediately notify the > postmaster(a)nds.com and delete it from your system as well as any copies. > The content of e-mails as well as traffic data may be monitored by NDS > for employment and security purposes. To protect the environment please > do not print this e-mail unless necessary. > > NDS Limited. Registered Office: One London Road, Staines, Middlesex, > TW18 4EX, United Kingdom. A company registered in England and Wales. > Registered no. 3080780. VAT no. GB 603 8808 40-00 > ************************************************************************************** > > _______________________________________________ > rules-users mailing list > rules-users(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users