Re: [rules-users] Mechanism to prevent redundant inferences

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