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

[rouvas at di.uoa.gr]

Greg,

thank you for your advise.
That helped me tackle the problem.

-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" <TSwindells at 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
>> postmaster at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>