[rules-users] Mechanism to prevent redundant inferences

[Swindells, Thomas]

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 at lists.jboss.org [mailto:rules-users-bounces at 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 at nds.com<mailto:TSwindells at 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 at lists.jboss.org<mailto:rules-users-bounces at lists.jboss.org> [mailto:rules-users-bounces at lists.jboss.org<mailto:rules-users-bounces at lists.jboss.org>] On Behalf Of Tracey Lall
Sent: 20 March 2010 20:55
To: rules-users at lists.jboss.org<mailto:rules-users at 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 at nds.com<mailto: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
**************************************************************************************
________________________________
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<mailto: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.

An NDS Group Limited company. www.nds.com<http://www.nds.com>

_______________________________________________
rules-users mailing list
rules-users at lists.jboss.org<mailto:rules-users at 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 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
**************************************************************************************

________________________________
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.

An NDS Group Limited company. www.nds.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100325/fa8e0ef8/attachment.html