[rules-users] Mechanism to prevent redundant inferences

[Tracey Lall]

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>

>  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] *On Behalf Of *Tracey Lall
> *Sent:* 20 March 2010 20:55
> *To:* 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 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
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100324/7e0eeb72/attachment.html