Ø 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(a)lists.jboss.org [mailto:rules-users-bounces@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@morganstanley.com<mailto:Ben.Cotton@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@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 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@morganstanley.com<mailto:meitreyi.panchmia@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
ml/ch05.html#d0e3962 lists & as an operator. But it somehow
doesn't
work.
--
View this message in context:
021931.html Sent from the Drools: User forum mailing list archive at
_______________________________________________
rules-users mailing list
> rules-users@lists.jboss.org<mailto:rules-users@lists.jboss.org
_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org<mailto:rules-users@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@lists.jboss.org<mailto:rules-users@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.