6:08 p.m.
Hi,
What is the difference between the following 2 statements
stmt1 : FactA( attrib1 == "X" || attrib1 =="Y")
stmt2: FactA( attrib1 =="X") or FactA(attrib1 =="Y")
Thanks
Jai
6:30 p.m.
One is a field constraint disjointed connected the other is a
Conditional Element 'or'. Details of both are covered in the manual.
Suffice to say the first is like writting if ( stmt1.attrib1 == "X" ||
smt1.attrib1 == "Y" ) whil the ohte results in two separate rules, one
checking "X" and the other checking "Y", both rules can match and
fire.
Mark
Jai Vasanth wrote:
Hi,
What is the difference between the following 2 statements
stmt1 : FactA( attrib1 == "X" || attrib1 =="Y")
stmt2: FactA( attrib1 =="X") or FactA(attrib1 =="Y")
Thanks
Jai
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:25 p.m.
Here is the actual reason why I wanted to know the difference between those
2.
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
(Response( value > $r ) or Response( status == "override"))
then
retract( L );
end
The above rule performs what I intended. It retains the Response with the
largest value or it the one that has an override status (if one exists)
But I am getting a different behaviour for this one
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
Response( value > $r || status == "override" )
then
retract( L );
end
This rule seems to retain both the objects, the overriden and the largest
value
Could you explain to me how they are diffrent.
Thanks
Jai
On Feb 6, 2008 4:30 PM, Mark Proctor <mproctor(a)codehaus.org> wrote:
One is a field constraint disjointed connected the other is a
Conditional
Element 'or'. Details of both are covered in the manual. Suffice to say the
first is like writting if ( stmt1.attrib1 == "X" || smt1.attrib1 ==
"Y" )
whil the ohte results in two separate rules, one checking "X" and the other
checking "Y", both rules can match and fire.
Mark
Jai Vasanth wrote:
Hi,
What is the difference between the following 2 statements
stmt1 : FactA( attrib1 == "X" || attrib1 =="Y")
stmt2: FactA( attrib1 =="X") or FactA(attrib1 =="Y")
Thanks
Jai
------------------------------
_______________________________________________
rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:45 p.m.
Better still why don't you say why you think it's different. Remember
'or' results in two rules being generate, so write out those two rules
separately and it might help you understand. The second one is just
standard logic. And don't forget you'll get standard cross products
here, i.e. A x B and B x A.
Mark
Jai Vasanth wrote:
Here is the actual reason why I wanted to know the difference between
those 2.
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
(Response( value > $r ) or Response( status == "override"))
then
retract( L );
end
The above rule performs what I intended. It retains the Response with
the largest value or it the one that has an override status (if one
exists)
But I am getting a different behaviour for this one
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
Response( value > $r || status == "override" )
then
retract( L );
end
This rule seems to retain both the objects, the overriden and the
largest value
Could you explain to me how they are diffrent.
Thanks
Jai
On Feb 6, 2008 4:30 PM, Mark Proctor <mproctor(a)codehaus.org
<mailto:mproctor@codehaus.org>> wrote:
One is a field constraint disjointed connected the other is a
Conditional Element 'or'. Details of both are covered in the
manual. Suffice to say the first is like writting if (
stmt1.attrib1 == "X" || smt1.attrib1 == "Y" ) whil the ohte
results in two separate rules, one checking "X" and the other
checking "Y", both rules can match and fire.
Mark
Jai Vasanth wrote:
> Hi,
>
> What is the difference between the following 2 statements
>
>
> stmt1 : FactA( attrib1 == "X" || attrib1 =="Y")
>
>
> stmt2: FactA( attrib1 =="X") or FactA(attrib1 =="Y")
>
>
>
> Thanks
>
> Jai
> ------------------------------------------------------------------------
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org <mailto:rules-users@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/rules-users
------------------------------------------------------------------------
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
4:25 p.m.
The first case
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
(Response( value > $r ) or Response( status == "override"))
then
retract( L );
end
breaks down to
rule "Rule1"
dialect "java"
when
L : Response( $r : value && status != "override" )
Response( value > $r )
then
retract( L );
end
and
rule "Rule2"
dialect "java"
when
L : Response( $r : value && status != "override" )
Response( status == "override")
then
retract( L );
end
I see that the first rule removes all objects with smaller values and the
second one removes all the ones that arent overridden if there exists an
object that has an override
What I dont understand is, why the second one doesnt have similar behaviour
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
Response( value > $r || status == "override" )
then
retract( L );
end
When this rule runs , it should start removing objects with smaller values
that are *not* overridden . So if an overridden object exists finally we
will be left with 2 objects
Response( maxvalue, non override status ) and Response( somevalue,
"override" )
When the rule fires now L will take on the first one and the the other
object will match the second one since it has an override even though value
<= $r . This L should be extracted and we should just be left with the
overridden object.
But I still seem to be left with both the objects.
Jai
On Feb 7, 2008 1:45 PM, Mark Proctor <mproctor(a)codehaus.org> wrote:
Better still why don't you say why you think it's different.
Remember
'or' results in two rules being generate, so write out those two rules
separately and it might help you understand. The second one is just standard
logic. And don't forget you'll get standard cross products here, i.e. A x
B and B x A.
Mark
Jai Vasanth wrote:
Here is the actual reason why I wanted to know the difference between
those 2.
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
(Response( value > $r ) or Response( status == "override"))
then
retract( L );
end
The above rule performs what I intended. It retains the Response with the
largest value or it the one that has an override status (if one exists)
But I am getting a different behaviour for this one
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
Response( value > $r || status == "override" )
then
retract( L );
end
This rule seems to retain both the objects, the overriden and the largest
value
Could you explain to me how they are diffrent.
Thanks
Jai
On Feb 6, 2008 4:30 PM, Mark Proctor <mproctor(a)codehaus.org> wrote:
> One is a field constraint disjointed connected the other is a
> Conditional Element 'or'. Details of both are covered in the manual.
Suffice
> to say the first is like writting if ( stmt1.attrib1 == "X" ||
> smt1.attrib1 == "Y" ) whil the ohte results in two separate rules, one
> checking "X" and the other checking "Y", both rules can match
and fire.
>
> Mark
>
> Jai Vasanth wrote:
>
> Hi,
>
> What is the difference between the following 2 statements
>
>
> stmt1 : FactA( attrib1 == "X" || attrib1 =="Y")
>
>
> stmt2: FactA( attrib1 =="X") or FactA(attrib1 =="Y")
>
>
>
> Thanks
>
> Jai
>
> ------------------------------
>
> _______________________________________________
> rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
------------------------------
_______________________________________________
rules-users mailing
listrules-users@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:43 p.m.
I got it working by using the inline eval expression. The following is the
modified version of the rules.
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
Response( value > $r || eval (status.equals("override")) )
then
System.out.println("Retracting " + L);
retract( L );
end
The Response class has two fields one is value and the other is status. For
convenience, I added a constructor where the first parameter is the value and
the second is the status. I have added the following objects into the working
memory for testing.
final Response response1 = new Response(5,"override");
final Response response2 = new Response(6,"not override");
final Response response3 = new Response(7,"not override");
final Response response4 = new Response(8,"not override");
session.insert( response1 );
session.insert( response2 );
session.insert( response3 );
session.insert( response4 );
session.fireAllRules();
The result shows that the object, Response(5,"override"), is the only one left
after the all activated rules have been evaluated.
I am not sure why "==" does not work in this example. Is this a known bug?
10:52 a.m.
Very interesting. I tried it too , I dont think its about the '==' because
it seems to be working for eval( reason == 'override'). So it is more to do
with having the eval method call.
Nice find. Not too sure if this is a bug, or if there is a reason why drools
works this way.
Thanks
Jai
On Feb 7, 2008 5:43 PM, ST <super_thunder2(a)hotmail.com> wrote:
I got it working by using the inline eval expression. The following
is
the
modified version of the rules.
rule "Remove smaller or non-overriden"
dialect "java"
when
L : Response( $r : value && status != "override" )
Response( value > $r || eval (status.equals("override")) )
then
System.out.println("Retracting " + L);
retract( L );
end
The Response class has two fields one is value and the other is status.
For
convenience, I added a constructor where the first parameter is the value
and
the second is the status. I have added the following objects into the
working
memory for testing.
final Response response1 = new Response(5,"override");
final Response response2 = new Response(6,"not override");
final Response response3 = new Response(7,"not override");
final Response response4 = new Response(8,"not override");
session.insert( response1 );
session.insert( response2 );
session.insert( response3 );
session.insert( response4 );
session.fireAllRules();
The result shows that the object, Response(5,"override"), is the only one
left
after the all activated rules have been evaluated.
I am not sure why "==" does not work in this example. Is this a known
bug?
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:11 a.m.
Sorry... eval(reason == 'override') is not the right way to check for
string equality doh. Yes yours is definitely the way to go. I have had the
'==' work for many cases. In this case it seems to be not working when
there are multiple boolean disjunctions along with them.
Jai
On Feb 8, 2008 8:52 AM, Jai Vasanth <jaivasanth(a)gmail.com> wrote:
Very interesting. I tried it too , I dont think its about the
'==' because
it seems to be working for eval( reason == 'override'). So it is more to do
with having the eval method call.
Nice find. Not too sure if this is a bug, or if there is a reason why
drools works this way.
Thanks
Jai
On Feb 7, 2008 5:43 PM, ST <super_thunder2(a)hotmail.com> wrote:
> I got it working by using the inline eval expression. The following is
> the
> modified version of the rules.
>
> rule "Remove smaller or non-overriden"
> dialect "java"
> when
> L : Response( $r : value && status != "override" )
> Response( value > $r || eval (status.equals("override")) )
> then
> System.out.println("Retracting " + L);
> retract( L );
> end
>
> The Response class has two fields one is value and the other is status.
> For
> convenience, I added a constructor where the first parameter is the
> value and
> the second is the status. I have added the following objects into the
> working
> memory for testing.
>
> final Response response1 = new Response(5,"override");
> final Response response2 = new Response(6,"not override");
> final Response response3 = new Response(7,"not override");
> final Response response4 = new Response(8,"not override");
> session.insert( response1 );
> session.insert( response2 );
> session.insert( response3 );
> session.insert( response4 );
>
> session.fireAllRules();
>
> The result shows that the object, Response(5,"override"), is the only
> one left
> after the all activated rules have been evaluated.
>
> I am not sure why "==" does not work in this example. Is this a known
> bug?
>
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
12:25 p.m.
Perhaps the comparison problem is related to the bug reported by Len. See the
thread named, "boolean == String".
http://jira.jboss.org/jira/browse/JBRULES-1451
12:44 p.m.
Ok, I see the problem. It is a bug that happens when mixing alpha and
beta constraints under ||.
I will fix it.
[]s
Edson
2008/2/8, Jai Vasanth <jaivasanth(a)gmail.com>:
Sorry... eval(reason == 'override') is not the right way to check for
string equality doh. Yes yours is definitely the way to go. I have had the
'==' work for many cases. In this case it seems to be not working when
there are multiple boolean disjunctions along with them.
Jai
On Feb 8, 2008 8:52 AM, Jai Vasanth <jaivasanth(a)gmail.com> wrote:
> Very interesting. I tried it too , I dont think its about the '=='
> because it seems to be working for eval( reason == 'override'). So it is
> more to do with having the eval method call.
> Nice find. Not too sure if this is a bug, or if there is a reason why
> drools works this way.
>
>
> Thanks
>
> Jai
>
>
> On Feb 7, 2008 5:43 PM, ST <super_thunder2(a)hotmail.com> wrote:
>
> > I got it working by using the inline eval expression. The following
> > is the
> > modified version of the rules.
> >
> > rule "Remove smaller or non-overriden"
> > dialect "java"
> > when
> > L : Response( $r : value && status != "override" )
> > Response( value > $r || eval (status.equals("override"))
)
> > then
> > System.out.println("Retracting " + L);
> > retract( L );
> > end
> >
> > The Response class has two fields one is value and the other is
> > status. For
> > convenience, I added a constructor where the first parameter is the
> > value and
> > the second is the status. I have added the following objects into the
> > working
> > memory for testing.
> >
> > final Response response1 = new Response(5,"override");
> > final Response response2 = new Response(6,"not override");
> > final Response response3 = new Response(7,"not override");
> > final Response response4 = new Response(8,"not override");
> > session.insert( response1 );
> > session.insert( response2 );
> > session.insert( response3 );
> > session.insert( response4 );
> >
> > session.fireAllRules();
> >
> > The result shows that the object, Response(5,"override"), is the
only
> > one left
> > after the all activated rules have been evaluated.
> >
> > I am not sure why "==" does not work in this example. Is this a
known
> > bug?
> >
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
6:03 p.m.
This is fixed on 4.0.x branch. I will fix in trunk.
[]s
Edson
2008/2/8, Edson Tirelli <tirelli(a)post.com>:
Ok, I see the problem. It is a bug that happens when mixing alpha and
beta constraints under ||.
I will fix it.
[]s
Edson
2008/2/8, Jai Vasanth <jaivasanth(a)gmail.com>:
>
> Sorry... eval(reason == 'override') is not the right way to check for
> string equality doh. Yes yours is definitely the way to go. I have had the
> '==' work for many cases. In this case it seems to be not working when
> there are multiple boolean disjunctions along with them.
>
> Jai
>
> On Feb 8, 2008 8:52 AM, Jai Vasanth <jaivasanth(a)gmail.com> wrote:
>
> > Very interesting. I tried it too , I dont think its about the '=='
> > because it seems to be working for eval( reason == 'override'). So it
is
> > more to do with having the eval method call.
> > Nice find. Not too sure if this is a bug, or if there is a reason why
> > drools works this way.
> >
> >
> > Thanks
> >
> > Jai
> >
> >
> > On Feb 7, 2008 5:43 PM, ST <super_thunder2(a)hotmail.com> wrote:
> >
> > > I got it working by using the inline eval expression. The following
> > > is the
> > > modified version of the rules.
> > >
> > > rule "Remove smaller or non-overriden"
> > > dialect "java"
> > > when
> > > L : Response( $r : value && status != "override"
)
> > > Response( value > $r || eval
(status.equals("override")) )
> > > then
> > > System.out.println("Retracting " + L);
> > > retract( L );
> > > end
> > >
> > > The Response class has two fields one is value and the other is
> > > status. For
> > > convenience, I added a constructor where the first parameter is the
> > > value and
> > > the second is the status. I have added the following objects into
> > > the working
> > > memory for testing.
> > >
> > > final Response response1 = new Response(5,"override");
> > > final Response response2 = new Response(6,"not
override");
> > > final Response response3 = new Response(7,"not
override");
> > > final Response response4 = new Response(8,"not
override");
> > > session.insert( response1 );
> > > session.insert( response2 );
> > > session.insert( response3 );
> > > session.insert( response4 );
> > >
> > > session.fireAllRules();
> > >
> > > The result shows that the object, Response(5,"override"), is
the
> > > only one left
> > > after the all activated rules have been evaluated.
> > >
> > > I am not sure why "==" does not work in this example. Is this
a
> > > known bug?
> > >
> > >
> > >
> > > _______________________________________________
> > > rules-users mailing list
> > > rules-users(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/rules-users
> > >
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
6:36 a.m.
Done in trunk too:
http://jira.jboss.com/jira/browse/JBRULES-1472
[]s
Edson
2008/2/18, Edson Tirelli <tirelli(a)post.com>:
This is fixed on 4.0.x branch. I will fix in trunk.
[]s
Edson
2008/2/8, Edson Tirelli <tirelli(a)post.com>:
>
>
> Ok, I see the problem. It is a bug that happens when mixing alpha and
> beta constraints under ||.
> I will fix it.
>
> []s
> Edson
>
>
>
> 2008/2/8, Jai Vasanth <jaivasanth(a)gmail.com>:
> >
> > Sorry... eval(reason == 'override') is not the right way to check for
> > string equality doh. Yes yours is definitely the way to go. I have had the
> > '==' work for many cases. In this case it seems to be not working when
> > there are multiple boolean disjunctions along with them.
> >
> > Jai
> >
> > On Feb 8, 2008 8:52 AM, Jai Vasanth <jaivasanth(a)gmail.com> wrote:
> >
> > > Very interesting. I tried it too , I dont think its about the
'=='
> > > because it seems to be working for eval( reason == 'override'). So
it is
> > > more to do with having the eval method call.
> > > Nice find. Not too sure if this is a bug, or if there is a reason
> > > why drools works this way.
> > >
> > >
> > > Thanks
> > >
> > > Jai
> > >
> > >
> > > On Feb 7, 2008 5:43 PM, ST <super_thunder2(a)hotmail.com> wrote:
> > >
> > > > I got it working by using the inline eval expression. The
> > > > following is the
> > > > modified version of the rules.
> > > >
> > > > rule "Remove smaller or non-overriden"
> > > > dialect "java"
> > > > when
> > > > L : Response( $r : value && status !=
"override" )
> > > > Response( value > $r || eval
(status.equals("override")) )
> > > > then
> > > > System.out.println("Retracting " + L);
> > > > retract( L );
> > > > end
> > > >
> > > > The Response class has two fields one is value and the other is
> > > > status. For
> > > > convenience, I added a constructor where the first parameter is
> > > > the value and
> > > > the second is the status. I have added the following objects into
> > > > the working
> > > > memory for testing.
> > > >
> > > > final Response response1 = new
Response(5,"override");
> > > > final Response response2 = new Response(6,"not
override");
> > > > final Response response3 = new Response(7,"not
override");
> > > > final Response response4 = new Response(8,"not
override");
> > > > session.insert( response1 );
> > > > session.insert( response2 );
> > > > session.insert( response3 );
> > > > session.insert( response4 );
> > > >
> > > > session.fireAllRules();
> > > >
> > > > The result shows that the object, Response(5,"override"),
is the
> > > > only one left
> > > > after the all activated rules have been evaluated.
> > > >
> > > > I am not sure why "==" does not work in this example. Is
this a
> > > > known bug?
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > rules-users mailing list
> > > > rules-users(a)lists.jboss.org
> > > > https://lists.jboss.org/mailman/listinfo/rules-users
> > > >
> > >
> > >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
>
> --
> Edson Tirelli
> JBoss Drools Core Development
> Office: +55 11 3529-6000
> Mobile: +55 11 9287-5646
> JBoss, a division of Red Hat @ www.jboss.com
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
--
Edson Tirelli
JBoss Drools Core Development
Office: +55 11 3529-6000
Mobile: +55 11 9287-5646
JBoss, a division of Red Hat @ www.jboss.com
6125
days inactive
6137
days old
11 comments
4 participants
participants (4)
-
Edson Tirelli -
Jai Vasanth -
Mark Proctor -
ST