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" <[email protected]> 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 > [email protected] 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users _______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
