RE: [drools-interest] Re: All conditions are tested even if a prior condition is false
Steven Warren <steve <at> myvest.com>
2004-03-10 22:48:58 GMT
Hi!
Well, let me talk to both emails at the same time as the questions
overlap.
I agree with your first point Florent, that is that a "NOT" and also a
"NOT NOT" (in other words "EXISTS") feature in drools needs to be built.
That is already covered in a different JIRA, so my JIRA just assumes it
will be done :)
Having the other JIRA satisfied, It can (as you agree I think) be built
at a semantic level.
On your second point, I disagree. I don't think I said anything about
the order in which the conditions are evaluated (although you do make an
excellent point on that, Bob, I believe, is pondering the particular use
cases as we speak :) ). I only asserted about whether prior listed
conditions are matched. Let me give an example which I hope will clear
up John's question as well:
Let's say you write the following rules (I'm making up the syntax):
<rule name="Get the apple">
<parameter identifier="monkey">
<java:class>Monkey</java:class>
</parameter>
<java:condition>monkey.isOnTable()</java:condition>
<java:condition>monkey.hasPole()</java:condition>
<java:consequence>
System.out.println("Monkey hits the apple with the pole");
</java:consequence>
</rule>
<rule name="Get the pole">
<parameter identifier="monkey">
<java:class>Monkey</java:class>
</parameter>
<parameter identifier="goal">
<java:class>java.lang.String</java:class>
</parameter>
<java:condition>goal.equals("GETPOLE")</java:condition>
<java:condition>!monkey.hasPole()</java:condition>
<java:consequence>
System.out.println("Monkey get's the pole");
retractObject(goal);
</java:consequence>
</rule>
Now I could write all the rules that resolve into the monkey needing the
pole and invoking the getpole rule, or if I had the "else" feature I
could write the rules like this:
<rule name="Hit the apple">
<parameter identifier="monkey">
<java:class>Monkey</java:class>
</parameter>
<parameter identifier="pole">
<java:class>Pole</java:class>
</parameter>
<java:condition>monkey.isOnTable()</java:condition>
<java:condition else="Need pole">pole.isOnTable()</java:condition>
<java:consequence>
System.out.println("Monkey hits the apple with the pole");
</java:consequence>
</java:consequence else="Need pole">
assertObject("GETPOLE");
</java:consequence>
</rule>
<rule name="Get the pole">
<parameter identifier="monkey">
<java:class>Monkey</java:class>
</parameter>
<parameter identifier="goal">
<java:class>java.lang.String</java:class>
</parameter>
<java:condition>goal.equals("GETPOLE")</java:condition>
<java:consequence>
System.out.println("Monkey get's the pole");
modifyObject(pole);
retractObject(goal);
</java:consequence>
</rule>
The above syntax would (on the fly) generate the following additional
rule (of course assuming the "not" feature):
<rule name="Hit the apple - generated goal of: Need pole">
<parameter identifier="monkey">
<java:class>Monkey</java:class>
</parameter>
<parameter identifier="pole">
<java:class>Pole</java:class>
</parameter>
<java:condition>monkey.isOnTable()</java:condition>
<java:condition match="NOT">pole.isOnTable()</java:condition>
</java:consequence>
assertObject("GETPOLE");
</java:consequence>
</rule>
And the semantic module could generate all those extra rules, THAT would
be much much easier to read and maintain. It also doesn't do anything
you can't do by hand, it's just very error prone and hard to maintain if
you try to do this by hand in more complex cases.
Steve
-----Original Message-----
From: drools-interest-admin <at> lists.codehaus.org
[mailto:drools-interest-admin <at> lists.codehaus.org] On Behalf Of Walsh,
John E
Sent: Wednesday, March 10, 2004 11:16 AM
To: drools-interest <at> lists.codehaus.org
Subject: RE: [drools-interest] Re: All conditions are tested even if a
prior condition is false
Hi all,
Maybe I'm not getting this right but it seems to me that this is along
the lines of adding an 'OR' type expression. I thought that in Rule
Systems 'OR' conditions were prohibited and that one should only use
'AND' logical expressions. Isn't it the case that if you need to handle
the 'else' situations, that should be encapsulated into a separate Rule?
I don't see the advantage of making the rules so convoluted. Also, it
seems that adding an else situation would be rather dangerous as there
is far more of an unknown quantity with alternative conditions.
John Walsh
-----Original Message-----
From: Florent LIOULT [mailto:flioult <at> financeactive.com]
Sent: Wednesday, March 10, 2004 1:57 PM
To: drools-interest <at> lists.codehaus.org
Subject: [drools-interest] Re: All conditions are tested even if a prior
condition is false
>I think what can happen is that the semantic modules can just generate
addtional rules to handle the
>"else" conditions on the fly as they come across "else" consequences.
What do you mean by "else". If condition C is true when do action A else
do action A'. But, when do you know that C is not true ? In general rule
engine, you never know that. Think about existential rule such "if exist
A such A = 5 then do something". The rule is potentialy never false
because you can always add fact to satisfy it. There are solution in
case of less expressive rule engine but it still requires noticable
change in the RETE code. If you want to do the work at the semantic
module, you must find a way to negate a condition. It's not trivial at
all.
>Even though the first condition is not satisfied (no matching trigger
instance exists), the third
>condition is being tested (and gets a null pointer violation. Shouldn't
>the
later conditions not be
>tested if the earlier condition is not satisfied. I thought that was
>the
point of making the condition
>ests a list rather then a set.
There is a strong paradigm in rule engine based on RETE algorithm :
there is no guarantee about the order of evaluation. If you break this
rule, just don't use a RETE based engine because it will become useless.
All of this optimization work is related to this ability to "explode"
condition.
<rule name="Calculate the extrema of two evaluation points" >
<parameter identifier="a">
<java:class>Alpha</java:class>
</parameter>
<parameter identifier="b">
<java:class>Beta</java:class>
<java:condition>a == 5</java:condition>
<java:condition>b == 3</java:condition>
<java:consequence>
...
</java:consequence>
</rule>
If you insert a 'Beta' fact into the working memory, the second part of
the condition will be tested. Then engine won't wait until an 'Alpha' is
inserted. Why ? Because this test could be shared among many rules. You
can have antother rule with the "b == 3" test inside. The power of RETE
is to mutualize all common tests in order to execute them once. If you
really need such a feature, write something like :
<rule name="Calculate the extrema of two evaluation points" >
<parameter identifier="a">
<java:class>Alpha</java:class>
</parameter>
<parameter identifier="b">
<java:class>Beta</java:class>
<java:condition>a == 5 && b == 3</java:condition>
<java:consequence>
...
</java:consequence>
</rule>
This way you will benefit of Java ordered evaluation. If you always use
this kind of trick, think about using something else than Drools. A rule
engine without RETE feature is very easy to realize.
- Florent Lioult _______________________________________________
drools-interest mailing list
drools-interest <at> lists.codehaus.org
http://lists.codehaus.org/mailman/listinfo/drools-interest
_______________________________________________
drools-interest mailing list
drools-interest <at> lists.codehaus.org
http://lists.codehaus.org/mailman/listinfo/drools-interest
_______________________________________________
drools-interest mailing list
drools-interest <at> lists.codehaus.org
http://lists.codehaus.org/mailman/listinfo/drools-interest
.