[rules-users] Non short circuit ANDing

Jeremy Ary jeremy.ary at gmail.com
Wed Jan 30 16:00:30 EST 2013 

Have had this in the back of my mind most of the day...the more I think on
it, the more I suspect that you could abuse extends on the multiple
conditions, automatically rename each rule "part" (being a single-condition
rule derived from the original) to some derivation of the original rule
name, and need the consequence only in the fully-extended rule, thereby
giving the same effect, but with rule "parts" that would reflect failure at
the individual condition level. I've been mucking with a migraine since
lunch, so it's possible that I'm off with my thought process, but I might
run with this on the weekend if it passes group litmus...any thoughts?

rule "foo is bar"
when
   TypeA (  )
   TypeB (  )
then
   log.info("foo indeed bar'd");
end

translate to:

rule "foo is bar_1"
when
   TypeA (  )
then
end

rule "foo is bar_2" extends "foo is bar_1"
when
   TypeB (  )
then
   log.info("foo indeed bar'd");
end

or, to better reflect the agenda rule name of the original rule set:

rule "foo is bar_1"
when
   TypeA (  )
then
end

rule "foo is bar_2" extends "foo is bar_1"
when
   TypeB (  )
then
end

rule "foo is bar" extends "foo is bar_2"
when
then
   log.info("foo indeed bar'd");
end


On Wed, Jan 30, 2013 at 12:48 PM, Cotton, Ben
<Ben.Cotton at morganstanley.com>wrote:

>   **Ø  **It's usually worth going back to basics and challenging the
> 'users' to define exactly what they're looking for ****
>
> ** **
>
> It is challenging!   And we greatly appreciate that this forum is a place
> for us to express our challenges and learn of all the best ways that we can
> find remedy.****
>
> ** **
>
> The main thing our very-newbie team of Drools end-users want to share with
> the Drools providers is that based on *our understanding* of this
> specific reality =****
>
> ** **
>
> **Ø  **If you need to know all the reasons why a rule doesn't fire you'll
> have to evaluate all relevant conditions individually and keep track of the
> positives.****
>
> ** **
>
> We feel that we *may* be enduring a “burden” of having to physically
> re-factor and keystroke lots of .DRL code to get what we want (i.e. account
> for the answer “why do rules fail to fire?”) within that reality.****
>
> ** **
>
> Our newbie (naïve?) suggestion to “enrich .DRL (with add’l code that
> evaluates all relevant conditions individually and keep track of the
> positives) via a tool” was just our “Thinking out loud”.  Thanks for the
> recommendation to consider working memory listeners – doing our homework on
> this right now.****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] *On Behalf Of *Stephen Masters
> *Sent:* Wednesday, January 30, 2013 1:28 PM
>
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Non short circuit ANDing****
>
>  ** **
>
> The requirement does seem to come up from business users who don't
> understand what's going on inside a rules engine. For instance, if I create
> a trade request for account 15, then should I be logging that the "Account
> 188 is permitted to trade USD" rule (and 100 other similar rules) didn't
> fire and that it was because the request wasn't for account 188? Once the
> knowledge base reaches any kind of realistic size, this kind of auditing
> becomes meaningless. ****
>
> ** **
>
> To be honest, I rather thought that this was the role of working memory
> event listeners. Just create a listener to the facts your rule is
> interested in and you can log the values of the properties your rule looks
> at over time, and you can log which rules fired. If a rule does't fire,
> then you can see the state of all the facts in the working memory at that
> time.****
>
> ** **
>
> It's usually worth going back to basics and challenging the 'users' to
> define exactly what they're looking for in an audit, and work out the most
> appropriate way to achieve that.****
>
> ** **
>
> ** **
>
> ** **
>
> On 30 Jan 2013, at 15:22, "Cotton, Ben" <Ben.Cotton at morganstanley.com>
> wrote:****
>
>
>
> ****
>
> ** **
>
> Ø I can't think of a way to accomplish this without severely impacting
> performance as I think you'd essentially end up evaluating all of your
> rules with a secondary algorithm****
>
>  ****
>
> Agreed.  Such a “when do rules fail to fire?” accounting capability
> should not be a burden to the Drools runtime.    But what about a .DRL
> “enrichment “ tool that generates explicit accounting .DRL code?  Leaving
> the run-time unburdened, but liberating the .DRL author from all the
> key-stroke labor?****
>
>  ****
>
> Ø However, I only claim to know that I know very little, so grain of salt*
> ***
>
>  ****
>
> I don’t even claim to know very little!  (But do claim to be excited to
> “do the work” necessary to learn).****
>
>  ****
>
>  ****
>
>  ****
>
> *From:* rules-users-bounces at lists.jboss.org [mailto:rules-
> users-bounces at lists.jboss.org] *On Behalf Of *Jeremy Ary
> *Sent:* Wednesday, January 30, 2013 9:57 AM
> *To:* Rules Users List
> *Subject:* Re: [rules-users] Non short circuit ANDing****
>
>  ****
>
> This request turns up a lot. If you dig deeper into the Rete algorithm and
> examine how it works, you'll find that the node relations and redundancy
> elimination greatly abstracts away from what we think of as the LHS of a
> rule. In the node network, it's no longer a set of conditions grouped
> together for each rule that are checked for true/false collectively. I
> can't think of a way to accomplish this without severely impacting
> performance as I think you'd essentially end up evaluating all of your
> rules with a secondary algorithm. However, I only claim to know that I know
> very little, so grain of salt.****
>
>  ****
>
> On Wed, Jan 30, 2013 at 8:35 AM, Cotton, Ben <Ben.Cotton at morganstanley.com>
> wrote:****
>
> > you'll have to evaluate all relevant conditions individually and keep
> track of the positives****
>
>  ****
>
> Would it be reasonable to suggest that the Drools team provide the user
> community with some tool, API, or other framework construct that might
> assist us when we are faced with this exact task?****
>
>  ****
>
> I mean, yes, what you suggest here works (and it works perfectly).  But,
> for such an important and common user concern, we currently face a lot of
> "Drools .DRL keystroke labor" to get us completely where we need to be wrt
> to coding this tactic completely.****
>
>  ****
>
> Does your Intellifest white paper (today is the day?  HOORAY!)  comment at
> all on strategies to achieve this pattern in .DRL code?  It would be way
> cool if the framework itself liberated us with a “just add water and out
> comes the .DRL code you want” capability.  Such a capability would deliver
> to users a full answer wrt to our “when do rules fail to fire?” accounting
> needs.****
>
>  ****
>
> Admittedly, I don’t know of a best way to proceed wrt to potentially
> providing that capability.  But I do know it would be nice.****
>
>  ****
>
> As always, thank you very much for this forum’s superb support.****
>
>  ****
>
> -----Original Message-----
> From: rules-users-bounces at lists.jboss.org [mailto:
> rules-users-bounces at lists.jboss.org] On Behalf Of Wolfgang Laun
> Sent: Tuesday, January 29, 2013 2:07 PM
> To: Rules Users List
> Subject: Re: [rules-users] Non short circuit ANDing****
>
>  ****
>
> [Groundhog Day]****
>
>  ****
>
> If you need to know all the reasons why a rule doesn't fire you'll have to
> evaluate all relevant conditions individually and keep track of the
> positives. (See a very recent thread on this list.)****
>
>  ****
>
> -W****
>
>  ****
>
>  ****
>
> On 29/01/2013, mp <meitreyi.panchmia at morganstanley.com> wrote:****
>
> > I need to record the results of each of the conditions as a side****
>
> > effect in a list. But in case condition1 is false, condition2 would****
>
> > not be evaluated.****
>
> > This would prevent me from knowing whether or not condition2 was****
>
> > true/false.****
>
> > ****
>
> > 5.8.3.3.12. Operator precedence at****
>
> > http://docs.jboss.org/drools/release/5.2.0.Final/drools-expert-docs/ht**
> **
>
> > ml/ch05.html#d0e3962 lists & as an operator. But it somehow doesn't****
>
> > work.****
>
> > ****
>
> > ****
>
> > ****
>
> > --****
>
> > View this message in context:****
>
> > http://drools.46999.n3.nabble.com/Non-short-circuit-ANDing-tp4021928p4**
> **
>
> > 021931.html Sent from the Drools: User forum mailing list archive at****
>
> > Nabble.com.****
>
> > _______________________________________________****
>
> > rules-users mailing list****
>
> > rules-users at lists.jboss.org****
>
> > https://lists.jboss.org/mailman/listinfo/rules-users****
>
> > ****
>
> _______________________________________________****
>
> rules-users mailing list****
>
> rules-users at lists.jboss.org****
>
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
>  ****
>  ------------------------------
>
>
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the
> opinions or views contained herein are not intended to be, and do not
> constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall
> Street Reform and Consumer Protection Act. If you have received this
> communication in error, please destroy all electronic and paper copies and
> notify the sender immediately. Mistransmission is not intended to waive
> confidentiality or privilege. Morgan Stanley reserves the right, to the
> extent permitted under applicable law, to monitor electronic
> communications. This message is subject to terms available at the following
> link: http://www.morganstanley.com/disclaimers If you cannot access these
> links, please notify us by reply message and we will send the contents to
> you. By messaging with Morgan Stanley you consent to the foregoing.****
>
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
>  ****
>
> ** **
>  ------------------------------
>
>
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the
> opinions or views contained herein are not intended to be, and do not
> constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall
> Street Reform and Consumer Protection Act. If you have received this
> communication in error, please destroy all electronic and paper copies and
> notify the sender immediately. Mistransmission is not intended to waive
> confidentiality or privilege. Morgan Stanley reserves the right, to the
> extent permitted under applicable law, to monitor electronic
> communications. This message is subject to terms available at the following
> link: http://www.morganstanley.com/disclaimers If you cannot access these
> links, please notify us by reply message and we will send the contents to
> you. By messaging with Morgan Stanley you consent to the foregoing.****
>
> ** **
>
> ** **
>
> ** **
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users****
>
> ** **
>
>
> ------------------------------
>
> NOTICE: Morgan Stanley is not acting as a municipal advisor and the
> opinions or views contained herein are not intended to be, and do not
> constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall
> Street Reform and Consumer Protection Act. If you have received this
> communication in error, please destroy all electronic and paper copies and
> notify the sender immediately. Mistransmission is not intended to waive
> confidentiality or privilege. Morgan Stanley reserves the right, to the
> extent permitted under applicable law, to monitor electronic
> communications. This message is subject to terms available at the following
> link: http://www.morganstanley.com/disclaimers If you cannot access these
> links, please notify us by reply message and we will send the contents to
> you. By messaging with Morgan Stanley you consent to the foregoing.
>
>
> _______________________________________________
> 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/20130130/2493fe54/attachment-0001.html

More information about the rules-users mailing list