Presumably all your RHS do is insert your Proven objects. If this is the case then my first question is do you actually need to put in an optimisation here? How much is the work of evaluating a few extra rule nodes compared to the work and memory that will be required to evaluate the shadow facts and prevent the rules from firing. If you do want to try suppress rules firing couldn't you have the following LHS? Piton(predicate == $sentence, rule="uniquerulename") or not Proven(predicate == $sentence) What I would recommend is lots of reading up about performance, testing, trying different combinations and generating the rete graph that drools produces to see whether you have added more or less complexity to the graph. Also make sure you order your conditions so that the ones which are most likely to stop processing are placed first. Thomas From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Tracey Lall Sent: 20 March 2010 20:55 To: rules-users(a)lists.jboss.org Subject: [rules-users] Mechanism to prevent redundant inferences Hi folks I am writing a logical inference engine in drools. Logical sentences (class Sentence) which are proven are indicated by the fact Proven( sentence = $sentence ) All Proven(sentence) facts are asserted using the drools logical mechanism (since logical backtracking is required). For efficiency purposes I want to be able to suppress firing any rules which assert proof of a logical sentence which has already been proven (there may be multiple inferences which prove the same sentence). If the non existence of a proof of a sentence (not exists Proven(sentence=$sentence) is included in the lhs conditions then that causes problems when the rule logically asserts Proven(sentence) since the insertion invalidates the lhs conditions and hence the rule causes its own retraction (the inserted fact handle return is null). As a way around this I created a class Piton() to record whether a particular rule has fired. The lhs conditions then become: (Proven( predicate == $sentence ) or Piton( fireName == $descriptor ) ) And then in the body of the rule the first thing it asserts is the fact: Piton( fireName == $descriptor ) Where $descriptor is a string built from the rulename + the set of facts which matched the lhs (ie a descriptor which is unique to the rule fire) With this approach when a rule asserts Proven(sentence) because it has also asserted Piton( fireName == descriptor ) ) the lhs of the rule still matches the the rule fire is not retracted. This approach works, but it is rather tedious to implement since the descriptor must be defined in such as way to make it unique (or as far as possible unique) to the particular rule activation. Since the drools variable is not accessible in the lhs of a rule (and hence the activation details are not accessible in the lhs), this means that the descriptor must be handcoded to consist of all matching facts for that lhs. Is this approach the only way to prevent multiple rule firings for the same proof, or is there a simpler way to achieve this? Any advice greatly appreciated! thanks Tracey ________________________________ ************************************************************************************** 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 ************************************************************************************** ________________________________ 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. An NDS Group Limited company. www.nds.com

Why do you need to handcode a name unique to a particular activation of the rule? Isn't the combination of (sentence, rulename) unique enough? What I'm a bit confused about is what you are trying to achieve, is the RHS the same for all rules (or at least all combinations that match the same sentence)? If they are different then are you sure you don't want them all to fire? If your rules share the same calculation logic then one approach you could look into is separating the selection logic from the calculation logic. Your existing rules would insert logically an object "CalculationRequired(sentence, calculationName)" with multiple rules inserting the same fact. Your calculations would be separate rules triggered by a LHS of the form s : sentence, exists(CalcuationRequired(calculationName = "SomeName", sentence = s)). Don't know if that helps or not, Thomas From: rules-users-bounces(a)lists.jboss.org [mailto:rules-users-bounces@lists.jboss.org] On Behalf Of Tracey Lall Sent: 24 March 2010 18:35 To: Rules Users List Subject: Re: [rules-users] Mechanism to prevent redundant inferences Thanks Thomas In the rhs I am doing some calculations and then inserting Proven objects. The calculations are significant so I would prefer to prevent the rule fires from occurring. My inclusion of Piton(predicate == $sentence, rule="uniquerulename") does work, but its quite a lot of work to handcode a name which is unique to the particular activation of the rule. thanks for your help! Tracey 2010/3/22 Swindells, Thomas <TSwindells@nds.com<mailto:TSwindells@nds.com>> Presumably all your RHS do is insert your Proven objects. If this is the case then my first question is do you actually need to put in an optimisation here? How much is the work of evaluating a few extra rule nodes compared to the work and memory that will be required to evaluate the shadow facts and prevent the rules from firing. If you do want to try suppress rules firing couldn't you have the following LHS? Piton(predicate == $sentence, rule="uniquerulename") or not Proven(predicate == $sentence) What I would recommend is lots of reading up about performance, testing, trying different combinations and generating the rete graph that drools produces to see whether you have added more or less complexity to the graph. Also make sure you order your conditions so that the ones which are most likely to stop processing are placed first. Thomas From: rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org> [mailto:rules-users-bounces@lists.jboss.org<mailto:rules-users-bounces@lists.jboss.org>] On Behalf Of Tracey Lall Sent: 20 March 2010 20:55 To: rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org> Subject: [rules-users] Mechanism to prevent redundant inferences Hi folks I am writing a logical inference engine in drools. Logical sentences (class Sentence) which are proven are indicated by the fact Proven( sentence = $sentence ) All Proven(sentence) facts are asserted using the drools logical mechanism (since logical backtracking is required). For efficiency purposes I want to be able to suppress firing any rules which assert proof of a logical sentence which has already been proven (there may be multiple inferences which prove the same sentence). If the non existence of a proof of a sentence (not exists Proven(sentence=$sentence) is included in the lhs conditions then that causes problems when the rule logically asserts Proven(sentence) since the insertion invalidates the lhs conditions and hence the rule causes its own retraction (the inserted fact handle return is null). As a way around this I created a class Piton() to record whether a particular rule has fired. The lhs conditions then become: (Proven( predicate == $sentence ) or Piton( fireName == $descriptor ) ) And then in the body of the rule the first thing it asserts is the fact: Piton( fireName == $descriptor ) Where $descriptor is a string built from the rulename + the set of facts which matched the lhs (ie a descriptor which is unique to the rule fire) With this approach when a rule asserts Proven(sentence) because it has also asserted Piton( fireName == descriptor ) ) the lhs of the rule still matches the the rule fire is not retracted. This approach works, but it is rather tedious to implement since the descriptor must be defined in such as way to make it unique (or as far as possible unique) to the particular rule activation. Since the drools variable is not accessible in the lhs of a rule (and hence the activation details are not accessible in the lhs), this means that the descriptor must be handcoded to consist of all matching facts for that lhs. Is this approach the only way to prevent multiple rule firings for the same proof, or is there a simpler way to achieve this? Any advice greatly appreciated! thanks Tracey ________________________________ ************************************************************************************** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com<mailto:postmaster@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 ************************************************************************************** ________________________________ This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmaster@nds.com<mailto:postmaster@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. An NDS Group Limited company. www.nds.com<http://www.nds.com> _______________________________________________ rules-users mailing list rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/rules-users ________________________________ ************************************************************************************** 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 ************************************************************************************** ________________________________ 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. An NDS Group Limited company. www.nds.com