Thanks a lot Greg. This is definitevely something I must look into. -Stathis
Greg Barton wrote: > 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" <tswinde...@nds.com> 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 >> postmas...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > _______________________________________________ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
