Re: [rules-users] priority based on object properties
Wolfgang, How does the offset thing work exactly? Do we set one salience value for a rule and another offset value based on the fact fields? Or do we have one expression for salience, in the form of X+Y, where X is a static numeric value and Y is a formula based on the facts? It seems to me that the latter case is not much different, because all activations must be sorted based on the derived salience. The former case might be useful, as Drools can potentially first "roughly" sort the activations based on salience values, and then sort the smaller subsets of activations based on their offset values. Thanks. -Simon 2011/7/19 Wolfgang Laun : > A rule's salience can be defined with an arbitrary expression which > may include variables bound to mathced fact fields. > > It should be possible to compute the effective salience from a "base" > salience (according to the rule) plus an offset value derived from > field values. > > -W > > > On 18 July 2011 21:44, Simon Chen wrote: >> >> Hi all, >> >> I am curious if we can inform Drools' execution based on properties >> within objects. >> >> In particular, the salience value is defined for each rule, in the >> sense that rule A has priority over rule B to execute. I am wondering >> if we can define some kinda of salience metric, such that object X has >> higher priority than object Y to be executed in the same rule. >> >> To give an example, I am (still) playing with implementing shortest >> path using a few rules. I have a rule for selecting a shortest path on >> a node (among all the paths received from its neighbors) to a source >> node, and another rule for propagating the shortest path on a node to >> neighboring nodes. When I have many nodes in my graph, I found that >> the paths propagated (via the second rule) are not always the >> shortest, while Dijkstra's algorithm always "propagate" from the node >> with the shortest distance to the source. The effect is that my rules >> are wasting most of the time propagating paths that would be dropped >> in the end anyway... >> >> Any ideas? >> >> Thanks. >> -Simon >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] priority based on object properties
But here comes another problem... I used "salience (-$path.cost)" in the rule for propagating current shortest paths on a node to neighboring nodes. At first, it worked great, as in the log I see routes with smaller costs being propagated. But later on, I see the progress slowing down quite a bit. My guess is that the sorting based on (-$path.cost) takes longer and longer as the number of objects increases - now my java process takes about 8GB of memory. One idea is to use some sort of bucketing, such that I duplicate the propagation rule from one to, for example, five, and each of the five rules would be applied on a subset of the paths with a particular range of costs. This might work, but has the downside of needing the input of some data statistics (for proper bucketing, for example.) Any ideas on this? Thanks. -Simon On Mon, Jul 18, 2011 at 4:07 PM, Simon Chen wrote: > I think it works. > > Actually, just found it in the current Drools expert documentation > too. Shame on me... > > Thanks. > -Simon > > 2011/7/18 Michael Anstis : >> I believe this >> http://blog.athico.com/2007/05/dynamic-salience-expressions.html still >> works. >> >> On 18 July 2011 20:44, Simon Chen wrote: >>> >>> Hi all, >>> >>> I am curious if we can inform Drools' execution based on properties >>> within objects. >>> >>> In particular, the salience value is defined for each rule, in the >>> sense that rule A has priority over rule B to execute. I am wondering >>> if we can define some kinda of salience metric, such that object X has >>> higher priority than object Y to be executed in the same rule. >>> >>> To give an example, I am (still) playing with implementing shortest >>> path using a few rules. I have a rule for selecting a shortest path on >>> a node (among all the paths received from its neighbors) to a source >>> node, and another rule for propagating the shortest path on a node to >>> neighboring nodes. When I have many nodes in my graph, I found that >>> the paths propagated (via the second rule) are not always the >>> shortest, while Dijkstra's algorithm always "propagate" from the node >>> with the shortest distance to the source. The effect is that my rules >>> are wasting most of the time propagating paths that would be dropped >>> in the end anyway... >>> >>> Any ideas? >>> >>> Thanks. >>> -Simon >>> ___ >>> rules-users mailing list >>> rules-users@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] priority based on object properties
I think it works. Actually, just found it in the current Drools expert documentation too. Shame on me... Thanks. -Simon 2011/7/18 Michael Anstis : > I believe this > http://blog.athico.com/2007/05/dynamic-salience-expressions.html still > works. > > On 18 July 2011 20:44, Simon Chen wrote: >> >> Hi all, >> >> I am curious if we can inform Drools' execution based on properties >> within objects. >> >> In particular, the salience value is defined for each rule, in the >> sense that rule A has priority over rule B to execute. I am wondering >> if we can define some kinda of salience metric, such that object X has >> higher priority than object Y to be executed in the same rule. >> >> To give an example, I am (still) playing with implementing shortest >> path using a few rules. I have a rule for selecting a shortest path on >> a node (among all the paths received from its neighbors) to a source >> node, and another rule for propagating the shortest path on a node to >> neighboring nodes. When I have many nodes in my graph, I found that >> the paths propagated (via the second rule) are not always the >> shortest, while Dijkstra's algorithm always "propagate" from the node >> with the shortest distance to the source. The effect is that my rules >> are wasting most of the time propagating paths that would be dropped >> in the end anyway... >> >> Any ideas? >> >> Thanks. >> -Simon >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] priority based on object properties
Hi all, I am curious if we can inform Drools' execution based on properties within objects. In particular, the salience value is defined for each rule, in the sense that rule A has priority over rule B to execute. I am wondering if we can define some kinda of salience metric, such that object X has higher priority than object Y to be executed in the same rule. To give an example, I am (still) playing with implementing shortest path using a few rules. I have a rule for selecting a shortest path on a node (among all the paths received from its neighbors) to a source node, and another rule for propagating the shortest path on a node to neighboring nodes. When I have many nodes in my graph, I found that the paths propagated (via the second rule) are not always the shortest, while Dijkstra's algorithm always "propagate" from the node with the shortest distance to the source. The effect is that my rules are wasting most of the time propagating paths that would be dropped in the end anyway... Any ideas? Thanks. -Simon ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] recursive queries
Hi all, I am wondering if it is possible to write more complex queries, e.g., running a query inside of a query. An example is that I have one query to enumerate all books, and have another query to enumerate the people that have not read all books. According to a colleague of mine, the syntax for a query only allows the entity LHS in its declaration: http://docs.jboss.org/drools/release/5.2.0.CR1/drools-expert-docs/html/ch05.html#d0e5565 By definition, the entity LHS cannot contain the keyword query, as it can only contain conditional elements: http://docs.jboss.org/drools/release/5.2.0.CR1/drools-expert-docs/html/ch05.html#RuleLanguage-ConditionalElements Any thoughts? Thanks. -Simon ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] list operations in "then" part
"not memberOf" somehow worked for me... My actual line of code was: router not memberOf $route.hops I got around the addAll() issue by passing the list into the constructor of fact1... -Simon 2011/6/4 Wolfgang Laun : > I cannot reproduce this error. > > Do NOT rely on the automatic substitution of getters for simple field > accesses on a rule's right hand side, at least not for 5.2.0 CR. > > Moreover, I cannot compile the constraint > "jones" memberOf authors > This should be written as > authors contains "jones". > > For further analysis full workable code reproducing the issue would be > required. > > -W > > > On 3 June 2011 22:47, Simon Chen wrote: >> >> Can I maybe do a for loop in the "then" part? Is there a documentation >> regarding what is possible/impossible in the "then" part? >> >> Thanks. >> -Simon >> >> On Fri, Jun 3, 2011 at 3:23 PM, Simon Chen wrote: >> > No, this doesn't work... >> > >> > Drools-5.2 doesn't help either :-( >> > >> > 2011/6/2 Joe White : >> >> If you cast $b on the RHS it will probably work. We’ve had to do this >> >> in the >> >> past for rules like this. >> >> >> >> >> >> >> >> …. >> >> >> >> then: >> >> Test fact = new Test(); >> >> >> >> Book rhsBook = (Book)$b; >> >> fact.getList().addAll( rhsBook.authors ); >> >> insert(fact); >> >> end >> >> >> >> >> >> >> >> >> >> >> >> From: rules-users-boun...@lists.jboss.org >> >> [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Mark Proctor >> >> Sent: Thursday, June 02, 2011 8:52 AM >> >> To: rules-users@lists.jboss.org >> >> Subject: Re: [rules-users] list operations in "then" part >> >> >> >> >> >> >> >> On 02/06/2011 08:14, Wolfgang Laun wrote: >> >> >> >> On 1 June 2011 21:43, Simon Chen wrote: >> >> >> >> Hi all, >> >> >> >> I am always confused about what we can do in the "then" part of the >> >> rule. >> >> >> >> In particular, I have problem duplicate a list. For example: >> >> >> >> when: >> >> $b: Book( "james" memberOf authors ) >> >> then: >> >> Test fact = new Test(); >> >> fact.getList().addAll( $b.authors ); >> >> insert(fact); >> >> end >> >> >> >> The error message reads like this: >> >> >> >> BuildError: Unable to build expression for 'consequence': [Error: >> >> Failed to compile: 2 compilation error(s): >> >> - (1,7) unqualified type in strict mode for: $b >> >> - (1,12) unqualified type in strict mode for: authors] >> >> >> >> What is the right way to do this? >> >> >> >> Granted - the error message is a puzzle in itself, but basically, the >> >> RHS >> >> must be written according to Java rules. Hence, if $b is an object of >> >> type >> >> Book, $b.authors depends on the (Java!) visibility of member authors. >> >> If it >> >> isn't public, you must use the getter. >> >> >> >> I believe he's using "mvel" judging by the error. >> >> >> >> mark >> >> >> >> >> >> -W >> >> >> >> >> >> Thanks. >> >> -Simon >> >> ___ >> >> rules-users mailing list >> >> rules-users@lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> >> >> >> >> >> >> >> >> ___ >> >> >> >> rules-users mailing list >> >> >> >> rules-users@lists.jboss.org >> >> >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> >> >> >> >> ___ >> >> rules-users mailing list >> >> rules-users@lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> >> > >> >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] list operations in "then" part
Can I maybe do a for loop in the "then" part? Is there a documentation regarding what is possible/impossible in the "then" part? Thanks. -Simon On Fri, Jun 3, 2011 at 3:23 PM, Simon Chen wrote: > No, this doesn't work... > > Drools-5.2 doesn't help either :-( > > 2011/6/2 Joe White : >> If you cast $b on the RHS it will probably work. We’ve had to do this in the >> past for rules like this. >> >> >> >> …. >> >> then: >> Test fact = new Test(); >> >> Book rhsBook = (Book)$b; >> fact.getList().addAll( rhsBook.authors ); >> insert(fact); >> end >> >> >> >> >> >> From: rules-users-boun...@lists.jboss.org >> [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Mark Proctor >> Sent: Thursday, June 02, 2011 8:52 AM >> To: rules-users@lists.jboss.org >> Subject: Re: [rules-users] list operations in "then" part >> >> >> >> On 02/06/2011 08:14, Wolfgang Laun wrote: >> >> On 1 June 2011 21:43, Simon Chen wrote: >> >> Hi all, >> >> I am always confused about what we can do in the "then" part of the rule. >> >> In particular, I have problem duplicate a list. For example: >> >> when: >> $b: Book( "james" memberOf authors ) >> then: >> Test fact = new Test(); >> fact.getList().addAll( $b.authors ); >> insert(fact); >> end >> >> The error message reads like this: >> >> BuildError: Unable to build expression for 'consequence': [Error: >> Failed to compile: 2 compilation error(s): >> - (1,7) unqualified type in strict mode for: $b >> - (1,12) unqualified type in strict mode for: authors] >> >> What is the right way to do this? >> >> Granted - the error message is a puzzle in itself, but basically, the RHS >> must be written according to Java rules. Hence, if $b is an object of type >> Book, $b.authors depends on the (Java!) visibility of member authors. If it >> isn't public, you must use the getter. >> >> I believe he's using "mvel" judging by the error. >> >> mark >> >> >> -W >> >> >> Thanks. >> -Simon >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> >> >> ___ >> >> rules-users mailing list >> >> rules-users@lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] list operations in "then" part
No, this doesn't work... Drools-5.2 doesn't help either :-( 2011/6/2 Joe White : > If you cast $b on the RHS it will probably work. We’ve had to do this in the > past for rules like this. > > > > …. > > then: > Test fact = new Test(); > > Book rhsBook = (Book)$b; > fact.getList().addAll( rhsBook.authors ); > insert(fact); > end > > > > > > From: rules-users-boun...@lists.jboss.org > [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Mark Proctor > Sent: Thursday, June 02, 2011 8:52 AM > To: rules-users@lists.jboss.org > Subject: Re: [rules-users] list operations in "then" part > > > > On 02/06/2011 08:14, Wolfgang Laun wrote: > > On 1 June 2011 21:43, Simon Chen wrote: > > Hi all, > > I am always confused about what we can do in the "then" part of the rule. > > In particular, I have problem duplicate a list. For example: > > when: > $b: Book( "james" memberOf authors ) > then: > Test fact = new Test(); > fact.getList().addAll( $b.authors ); > insert(fact); > end > > The error message reads like this: > > BuildError: Unable to build expression for 'consequence': [Error: > Failed to compile: 2 compilation error(s): > - (1,7) unqualified type in strict mode for: $b > - (1,12) unqualified type in strict mode for: authors] > > What is the right way to do this? > > Granted - the error message is a puzzle in itself, but basically, the RHS > must be written according to Java rules. Hence, if $b is an object of type > Book, $b.authors depends on the (Java!) visibility of member authors. If it > isn't public, you must use the getter. > > I believe he's using "mvel" judging by the error. > > mark > > > -W > > > Thanks. > -Simon > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > ___ > > rules-users mailing list > > rules-users@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] list operations in "then" part
2011/6/2 Wolfgang Laun : > On 1 June 2011 21:43, Simon Chen wrote: >> >> Hi all, >> >> I am always confused about what we can do in the "then" part of the rule. >> >> In particular, I have problem duplicate a list. For example: >> >> when: >> $b: Book( "james" memberOf authors ) >> then: >> Test fact = new Test(); >> fact.getList().addAll( $b.authors ); >> insert(fact); >> end >> >> The error message reads like this: >> >> BuildError: Unable to build expression for 'consequence': [Error: >> Failed to compile: 2 compilation error(s): >> - (1,7) unqualified type in strict mode for: $b >> - (1,12) unqualified type in strict mode for: authors] >> >> What is the right way to do this? > > Granted - the error message is a puzzle in itself, but basically, the RHS > must be written according to Java rules. Hence, if $b is an object of type > Book, $b.authors depends on the (Java!) visibility of member authors. If it > isn't public, you must use the getter. I always have the variables "protected" and use public getters. For other variables, $b.xxx just works, as long as getXxx() exists. But for $b.authors, even if I have getAuthors() there, it still doesn't work. That's why I'm suspecting something wrong with the list - the only difference is that authors is an EList object... Still don't know why... -Simon > > -W > >> >> Thanks. >> -Simon >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] list operations in "then" part
Hi all, I am always confused about what we can do in the "then" part of the rule. In particular, I have problem duplicate a list. For example: when: $b: Book( "james" memberOf authors ) then: Test fact = new Test(); fact.getList().addAll( $b.authors ); insert(fact); end The error message reads like this: BuildError: Unable to build expression for 'consequence': [Error: Failed to compile: 2 compilation error(s): - (1,7) unqualified type in strict mode for: $b - (1,12) unqualified type in strict mode for: authors] What is the right way to do this? Thanks. -Simon ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] how to do things like "distinct"?
Hi all, I have the following problem. Let's say, I have a class Number3(), with three fields a, b, and c. I have the following rule: rule "test3" when Number3($a: a, $b: b) $minvalue: Number() from accumulate(Number3(a == $a, b == $b, $c: c), min($c)) then System.out.println($a + " " + $b + " " + $minvalue); end Say, I have four objects (1,2,3), (1,2,4), (1,3,4), (1,3,5). The result shows four lines: 1 3 4.0 1 3 4.0 1 2 3.0 1 2 3.0 But I want the output to be: 1 3 4.0 1 2 3.0 meaning that for each unique pair of a and b, I want the rule to fire only once. Is this doable? Thanks. -Simon ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] not sure if this is a bug of drools or my bad usage...
Hi Wolfgang, First, your rules work... But for the second rule, I replaced the first Reachable() in the when clause to Link(), and the result is still correct. Only if I remove "no-loop true", the issue I had appeared. So, I understand how "no-loop true" in this case helps to make the result correct. But, do you see any scenarios where "no-loop" can cause incorrect results? For example, not enough number of recursions? Thanks. -Simon 2011/3/8 Wolfgang Laun : > I think there is some fundamental error in deriving truths from givens and > other derived facts that are then interpreted as given truths, and, > moreover, with subtly varying semantics. In terms of graph theory: > reachability is based on (directed) edges, but it does not establish > additional edges. > > Deriving Reachability should be done by: > > rule deriveLink > when > Link( $a: a, $b: b ) > then > insertLogical(new Reachable($a,$b)); > System.out.println( "ins reach " + $a + " " + $b ); > end > > rule deriveReachReach > no-loop true > when > Reachable( $a: a, $b: b ) > Reachable( a == $b, $c: b != $a ) > then > insertLogical(new Reachable($a,$c)); > end > > Ideally, I would like to use > not Reachable(a == $a, b == $c) > instead of the (last resort) no-loop in the second rule, but Drools' truth > maintenance is incomplete: it does not let your define the logical > dependency on part of the condition (i.e., excluding the CE "not" in this > case). > > -W > > > > > > > On 8 March 2011 05:49, Simon Chen wrote: >> >> What I had is a very simplified version of how calculating transitive >> closure could go wrong... >> >> Let's say we have two rules: >> rule 1 >> when >> link(a,b) >> then >> insertLogical(new reachable(a,b)) >> >> rule 2 >> when >> link(a,b) reachable(b,c) >> then >> insertLogical(new reachable(a,c)) >> >> Let's say, I have link(a,b), link(b,c), link(b,a), link(c,b). So, >> we'll have reachable(a,b), reachable(b,c), reachable(a,c), etc. But, >> after I retract link(a,b) and link(b,a), guess what, reachable(c,a) >> still exists! This doesn't sound right to me. >> >> But in Drools, this is possible, because we have: >> reachable(c,a) <- link(c,b), reachable(b,a) >> reachable(b,a) <- link(b,c), reachable(c,a) >> >> The problem here is that we actually inserted reachable(b,a) multiple >> times: first supported by link(b,a) and rule 1, and secondly by >> link(b,c) and reachable(c,a) and rule 2. When reachable(b,a) was >> inserted the second time, link(b,c) and reachable(c,a) become the >> additional supporting condition - maintained by the truth maintenance >> system. So, even if link(b,a) is retracted, reachable(b,a) still >> exists further supporting reachable(c,a). >> >> Is it clearer? >> >> Thanks. >> -Simon >> >> 2011/3/7 Edson Tirelli : >> > >> > Simon, >> > The behavior seems correct to me as B is justified by either A or C >> > (or >> > both). Of course, from the initial state, A is required for C to first >> > exist, but once it starts to exist, your rules say that B and C justify >> > each >> > other and so both remain in memory. >> > This is design as intended, but do you think that is wrong? >> > Edson >> > >> > 2011/3/7 Simon Chen >> >> >> >> Hi all, >> >> >> >> An interesting finding: >> >> >> >> I have three simple rules: >> >> rule "A2B" >> >> when >> >> A() >> >> then >> >> insertLogical(new B()); >> >> end >> >> rule "B2C" >> >> when >> >> B() >> >> then >> >> insertLogical(new C()); >> >> end >> >> rule "C2B" >> >> when >> >> C() >> >> then >> >> insertLogical(new B()); >> >> end >> >> >> >> Basically, once we have an A(), we'll logically insert a B(). Once we >> >> have a B(), we'll logically insert a C(). Once we have a C(), we'll >> >> logically insert a B(). >> >> >> >> So, I first insert an A(), print all the objects. Retract A(), and >>
Re: [rules-users] not sure if this is a bug of drools or my bad usage...
What I had is a very simplified version of how calculating transitive closure could go wrong... Let's say we have two rules: rule 1 when link(a,b) then insertLogical(new reachable(a,b)) rule 2 when link(a,b) reachable(b,c) then insertLogical(new reachable(a,c)) Let's say, I have link(a,b), link(b,c), link(b,a), link(c,b). So, we'll have reachable(a,b), reachable(b,c), reachable(a,c), etc. But, after I retract link(a,b) and link(b,a), guess what, reachable(c,a) still exists! This doesn't sound right to me. But in Drools, this is possible, because we have: reachable(c,a) <- link(c,b), reachable(b,a) reachable(b,a) <- link(b,c), reachable(c,a) The problem here is that we actually inserted reachable(b,a) multiple times: first supported by link(b,a) and rule 1, and secondly by link(b,c) and reachable(c,a) and rule 2. When reachable(b,a) was inserted the second time, link(b,c) and reachable(c,a) become the additional supporting condition - maintained by the truth maintenance system. So, even if link(b,a) is retracted, reachable(b,a) still exists further supporting reachable(c,a). Is it clearer? Thanks. -Simon 2011/3/7 Edson Tirelli : > > Simon, > The behavior seems correct to me as B is justified by either A or C (or > both). Of course, from the initial state, A is required for C to first > exist, but once it starts to exist, your rules say that B and C justify each > other and so both remain in memory. > This is design as intended, but do you think that is wrong? > Edson > > 2011/3/7 Simon Chen >> >> Hi all, >> >> An interesting finding: >> >> I have three simple rules: >> rule "A2B" >> when >> A() >> then >> insertLogical(new B()); >> end >> rule "B2C" >> when >> B() >> then >> insertLogical(new C()); >> end >> rule "C2B" >> when >> C() >> then >> insertLogical(new B()); >> end >> >> Basically, once we have an A(), we'll logically insert a B(). Once we >> have a B(), we'll logically insert a C(). Once we have a C(), we'll >> logically insert a B(). >> >> So, I first insert an A(), print all the objects. Retract A(), and >> print all the objects. Here's what I got: >> com.sample.B@42 >> com.sample.C@43 >> com.sample.A@548997d1 >> after retract! >> com.sample.B@42 >> com.sample.C@43 >> >> So, B() and C(), which should be logically depend on A(), somehow are >> not retracted. The problem I see is the truth maintenance system allow >> B() and C() to depend on each other, thus not affected by losing A(). >> >> Is this a bug or my bad usage? >> >> Thanks. >> -Simon >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users > > > > -- > Edson Tirelli > JBoss Drools Core Development > JBoss by Red Hat @ www.jboss.com > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] not sure if this is a bug of drools or my bad usage...
Hi all, An interesting finding: I have three simple rules: rule "A2B" when A() then insertLogical(new B()); end rule "B2C" when B() then insertLogical(new C()); end rule "C2B" when C() then insertLogical(new B()); end Basically, once we have an A(), we'll logically insert a B(). Once we have a B(), we'll logically insert a C(). Once we have a C(), we'll logically insert a B(). So, I first insert an A(), print all the objects. Retract A(), and print all the objects. Here's what I got: com.sample.B@42 com.sample.C@43 com.sample.A@548997d1 after retract! com.sample.B@42 com.sample.C@43 So, B() and C(), which should be logically depend on A(), somehow are not retracted. The problem I see is the truth maintenance system allow B() and C() to depend on each other, thus not affected by losing A(). Is this a bug or my bad usage? Thanks. -Simon ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Object updated as rules are running
Try setting the second rule with a higher salience value?
2011/2/25 Jon Gil :
> Hi, I have a very simple rules flow that I am getting odd results from. For
> now, our project is planning on using spreadsheets and a drools server.
>
> The test project we are working on accepts a movie name from an external
> source and creates a Movie object that is passed to the rules. The first
> rule looks at the movieName attribute and assigns it a movieStar using the
> Movie objects setMovieStar call. We have printLn statements before and
> after this action to confirm that it does in fact work.
>
> The second rule, where things go wrong, checks the MovieStar attribute, but
> no matter what we've just set it to, it always uses the value
> ("NoStarYet") that was originally created when we create the Movie object in
> our Java code in the condition of our second rule. We've tried using the
> getMovieStar call in the condition, but it has been throwing errors when we
> startup the Drools Server.
>
> When we retreive the Movie object from the resultSet, the movieStar
> attribute is set correclty, but we can't get our flow to go as expected.
>
> This really seems like a simple issue, but we've had no luck with it. Any
> thoughts? Does the rules engine use the getter methods for conditions or
> does it use the values from the entityXML we pass in? Is there a way to
> make the engine update the object between running each rule?
>
> Any help is appreciated greatly.
> ___
> rules-users mailing list
> rules-users@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] unsolved myth regarding transitive closure using insertlogical...
On Tue, Feb 22, 2011 at 4:21 PM, Greg Barton wrote: > Implementations of equals() and hashCode() should always agree: > > http://www.javapractices.com/topic/TopicAction.do?Id=28 Ah, I'm making a joke out of myself again... :-) Haven't really needed to override equals() and hashCode() before, but now I know. Thanks for the pointer. -Simon > > --- On Tue, 2/22/11, Simon Chen wrote: > >> From: Simon Chen >> Subject: Re: [rules-users] unsolved myth regarding transitive closure using >> insertlogical... >> To: "Rules Users List" >> Date: Tuesday, February 22, 2011, 2:24 PM >> On Sun, Feb 20, 2011 at 10:11 PM, >> Mark Proctor >> wrote: >> > On 21/02/2011 03:03, Simon Chen wrote: >> >> On Sun, Feb 20, 2011 at 8:20 PM, Ansgar Konermann >> >> >> wrote: >> >>> On 19.02.2011 16:01, Simon Chen wrote: >> >>>> The example you gave seems to be the >> one-hop case. For the two-hop >> >>>> case, we need something like this >> >>>> >> >>>> when >> >>>> edge(a, b), reach(b, c), not >> exists reach(a, c) >> >>>> then >> >>>> insertLogical( reach(a,c) ) >> >>>> >> >>>> So, where do you put your logical around? >> It should include both >> >>>> edge(a,b) and reach(b,c), right? >> >>>> >> >>>> Another thought, can we have something >> like >> >>>> testExistsAndInsertLogical() to replace >> insertLogical()? But this may >> >>>> be buggy, as the conditions are all met, >> so the rule actually fired... >> >>>> >> >>> Hi, >> >>> >> >>> from my experience, insertLogical does exactly >> what >> >>> testExistsAndInsertLogical would suggest. If >> the same object is already >> >>> in the working memory, it keeps this object >> and does not insert another >> >>> instance. This behaviour is not stated >> explicitly in the documentation, >> >>> but I did a learning test a few weeks ago and >> IIRC it clearly showed >> >>> this behaviour (at least for 5.0.1). -- I >> consider this behaviour a >> >>> feature and would like it to be kept this >> way. >> >> I am using Drools 5.1.1, and I don't think >> insertLogical prevents >> >> duplicates automatically. This also boils down to >> the question of how >> >> Drools decides whether two objects are indeed the >> same. For strings >> >> and integers, it is straightforward, but not much >> so for complex >> >> objects. Is there a way to pass in a comparison >> function? >> > InsertLogical operates on equality mode, that is >> determined by the >> > pojo's equals() method implementation. If an object >> already exists that >> > is equal, it will use that and the justification >> counter for that >> > existing object is increased. >> >> Mark, >> >> I did a bit debugging using the drools source code, which >> is neatly >> written btw. I now know what caused my problem. When >> logically >> inserting an object, the current implementation would >> compare the >> object with saved EqualityKeys in the >> TruthMaintenanceSystem. The >> comparison is done through hashCode(), not equals(). So, a >> duplicate >> (by value) object can be inserted, because the hashcode is >> different. >> >> I am not sure if this is a design decision, but I would >> rather using >> equals() here. I overrode the hashCode() implementation of >> my objects, >> and it is working now... >> >> Thanks. >> -Simon >> >> > >> > Mark >> >>> With this, all which is necessary to implement >> transitive closure is to >> >>> remove the contradicting part of the >> precondition to avoid oscillation. >> >>> If it turns out that insertLogical does not >> perform a "does fact already >> >>> exist" check and thus might potentially insert >> duplicates, put exists( ) >> >>> around the two preconditions and also use >> "exists( reach(x,y) )" to >> >>> check whether y is reachable from x. >> >> I don't quite follow. Can you elaborate with an >> actual rule? >> >> >> >> Thanks! >> >> -Simon >> >> >> >>> Kind regards >> >>> >> >>> Ansgar >> >>> >> ___ >> >>> rules-users mailing list >> >>> rules-users@lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/rules-users >> >>> >> >> ___ >> >> rules-users mailing list >> >> rules-users@lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> >> >> >> > >> > >> > ___ >> > rules-users mailing list >> > rules-users@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/rules-users >> > >> >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> > > > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] unsolved myth regarding transitive closure using insertlogical...
On Sun, Feb 20, 2011 at 10:11 PM, Mark Proctor wrote: > On 21/02/2011 03:03, Simon Chen wrote: >> On Sun, Feb 20, 2011 at 8:20 PM, Ansgar Konermann >> wrote: >>> On 19.02.2011 16:01, Simon Chen wrote: >>>> The example you gave seems to be the one-hop case. For the two-hop >>>> case, we need something like this >>>> >>>> when >>>> edge(a, b), reach(b, c), not exists reach(a, c) >>>> then >>>> insertLogical( reach(a,c) ) >>>> >>>> So, where do you put your logical around? It should include both >>>> edge(a,b) and reach(b,c), right? >>>> >>>> Another thought, can we have something like >>>> testExistsAndInsertLogical() to replace insertLogical()? But this may >>>> be buggy, as the conditions are all met, so the rule actually fired... >>>> >>> Hi, >>> >>> from my experience, insertLogical does exactly what >>> testExistsAndInsertLogical would suggest. If the same object is already >>> in the working memory, it keeps this object and does not insert another >>> instance. This behaviour is not stated explicitly in the documentation, >>> but I did a learning test a few weeks ago and IIRC it clearly showed >>> this behaviour (at least for 5.0.1). -- I consider this behaviour a >>> feature and would like it to be kept this way. >> I am using Drools 5.1.1, and I don't think insertLogical prevents >> duplicates automatically. This also boils down to the question of how >> Drools decides whether two objects are indeed the same. For strings >> and integers, it is straightforward, but not much so for complex >> objects. Is there a way to pass in a comparison function? > InsertLogical operates on equality mode, that is determined by the > pojo's equals() method implementation. If an object already exists that > is equal, it will use that and the justification counter for that > existing object is increased. Mark, I did a bit debugging using the drools source code, which is neatly written btw. I now know what caused my problem. When logically inserting an object, the current implementation would compare the object with saved EqualityKeys in the TruthMaintenanceSystem. The comparison is done through hashCode(), not equals(). So, a duplicate (by value) object can be inserted, because the hashcode is different. I am not sure if this is a design decision, but I would rather using equals() here. I overrode the hashCode() implementation of my objects, and it is working now... Thanks. -Simon > > Mark >>> With this, all which is necessary to implement transitive closure is to >>> remove the contradicting part of the precondition to avoid oscillation. >>> If it turns out that insertLogical does not perform a "does fact already >>> exist" check and thus might potentially insert duplicates, put exists( ) >>> around the two preconditions and also use "exists( reach(x,y) )" to >>> check whether y is reachable from x. >> I don't quite follow. Can you elaborate with an actual rule? >> >> Thanks! >> -Simon >> >>> Kind regards >>> >>> Ansgar >>> ___ >>> rules-users mailing list >>> rules-users@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] unsolved myth regarding transitive closure using insertlogical...
On Mon, Feb 21, 2011 at 4:03 PM, Ansgar Konermann wrote: > On 21.02.2011 04:11, Mark Proctor wrote: >> On 21/02/2011 03:03, Simon Chen wrote: >> >>> On Sun, Feb 20, 2011 at 8:20 PM, Ansgar Konermann >>> wrote: >>> >>>> On 19.02.2011 16:01, Simon Chen wrote: >>>> >>>>> The example you gave seems to be the one-hop case. For the two-hop >>>>> case, we need something like this >>>>> >>>>> when >>>>> edge(a, b), reach(b, c), not exists reach(a, c) >>>>> then >>>>> insertLogical( reach(a,c) ) >>>>> >>>>> So, where do you put your logical around? It should include both >>>>> edge(a,b) and reach(b,c), right? >>>>> >>>>> Another thought, can we have something like >>>>> testExistsAndInsertLogical() to replace insertLogical()? But this may >>>>> be buggy, as the conditions are all met, so the rule actually fired... >>>>> >>>>> >>>> Hi, >>>> >>>> from my experience, insertLogical does exactly what >>>> testExistsAndInsertLogical would suggest. If the same object is already >>>> in the working memory, it keeps this object and does not insert another >>>> instance. This behaviour is not stated explicitly in the documentation, >>>> but I did a learning test a few weeks ago and IIRC it clearly showed >>>> this behaviour (at least for 5.0.1). -- I consider this behaviour a >>>> feature and would like it to be kept this way. >>>> >>> I am using Drools 5.1.1, and I don't think insertLogical prevents >>> duplicates automatically. This also boils down to the question of how >>> Drools decides whether two objects are indeed the same. For strings >>> and integers, it is straightforward, but not much so for complex >>> objects. Is there a way to pass in a comparison function? >>> >> InsertLogical operates on equality mode, that is determined by the >> pojo's equals() method implementation. If an object already exists that >> is equal, it will use that and the justification counter for that >> existing object is increased. >> >> Mark >> >>>> With this, all which is necessary to implement transitive closure is to >>>> remove the contradicting part of the precondition to avoid oscillation. >>>> If it turns out that insertLogical does not perform a "does fact already >>>> exist" check and thus might potentially insert duplicates, put exists( ) >>>> around the two preconditions and also use "exists( reach(x,y) )" to >>>> check whether y is reachable from x. >>>> >>> I don't quite follow. Can you elaborate with an actual rule? >>> > > Easy case (insertLogical does not introduce duplicate objects): > > when > edge(a, b) > reach(b, c) > then > insertLogical( reach(a,c) ) > > > If insertLogical did introduce duplicate objects, we'd need this: > > when > exists edge(a, b) > exists reach(b, c) > then > insertLogical( reach(a,c) ) I don't see why this would prevent the duplicate objects... Let's say, the first rule inserted reach(a1,c1) as a duplicate, given edge(a1,b1) and reach(b1,c1). The same duplicate reachable(a1,c1) would be inserted by the second rule as well, right? I don't see why duplicates are prevented by the second rule. Again, I'm not a language person, so please educate me... Thanks. -Simon > > > Kind regards > > Ansgar > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] unsolved myth regarding transitive closure using insertlogical...
On Sun, Feb 20, 2011 at 10:11 PM, Mark Proctor wrote: > On 21/02/2011 03:03, Simon Chen wrote: >> On Sun, Feb 20, 2011 at 8:20 PM, Ansgar Konermann >> wrote: >>> On 19.02.2011 16:01, Simon Chen wrote: >>>> The example you gave seems to be the one-hop case. For the two-hop >>>> case, we need something like this >>>> >>>> when >>>> edge(a, b), reach(b, c), not exists reach(a, c) >>>> then >>>> insertLogical( reach(a,c) ) >>>> >>>> So, where do you put your logical around? It should include both >>>> edge(a,b) and reach(b,c), right? >>>> >>>> Another thought, can we have something like >>>> testExistsAndInsertLogical() to replace insertLogical()? But this may >>>> be buggy, as the conditions are all met, so the rule actually fired... >>>> >>> Hi, >>> >>> from my experience, insertLogical does exactly what >>> testExistsAndInsertLogical would suggest. If the same object is already >>> in the working memory, it keeps this object and does not insert another >>> instance. This behaviour is not stated explicitly in the documentation, >>> but I did a learning test a few weeks ago and IIRC it clearly showed >>> this behaviour (at least for 5.0.1). -- I consider this behaviour a >>> feature and would like it to be kept this way. >> I am using Drools 5.1.1, and I don't think insertLogical prevents >> duplicates automatically. This also boils down to the question of how >> Drools decides whether two objects are indeed the same. For strings >> and integers, it is straightforward, but not much so for complex >> objects. Is there a way to pass in a comparison function? > InsertLogical operates on equality mode, that is determined by the > pojo's equals() method implementation. If an object already exists that > is equal, it will use that and the justification counter for that > existing object is increased. I looked at my output, but this seems not to be the case... Here are two duplicated objects inserted by insertLogical() according to the event log (unless the two factIds are referring to the same object?) Please ignore the details, but the key point is that the two facts are indeed the same, but inserted within the same session. 1 41 Route(router: r1, prefix: 192.168.1.2/30, nexthop: r2:ge0) 1 43 Route(router: r1, prefix: 192.168.1.2/30, nexthop: r2:ge0) I overrode the equals() function of Route object, so as long as the values are the same, the two objects are considered equal. Thanks. -Simon > > Mark >>> With this, all which is necessary to implement transitive closure is to >>> remove the contradicting part of the precondition to avoid oscillation. >>> If it turns out that insertLogical does not perform a "does fact already >>> exist" check and thus might potentially insert duplicates, put exists( ) >>> around the two preconditions and also use "exists( reach(x,y) )" to >>> check whether y is reachable from x. >> I don't quite follow. Can you elaborate with an actual rule? >> >> Thanks! >> -Simon >> >>> Kind regards >>> >>> Ansgar >>> ___ >>> rules-users mailing list >>> rules-users@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] unsolved myth regarding transitive closure using insertlogical...
On Sun, Feb 20, 2011 at 10:11 PM, Mark Proctor wrote: > On 21/02/2011 03:03, Simon Chen wrote: >> On Sun, Feb 20, 2011 at 8:20 PM, Ansgar Konermann >> wrote: >>> On 19.02.2011 16:01, Simon Chen wrote: >>>> The example you gave seems to be the one-hop case. For the two-hop >>>> case, we need something like this >>>> >>>> when >>>> edge(a, b), reach(b, c), not exists reach(a, c) >>>> then >>>> insertLogical( reach(a,c) ) >>>> >>>> So, where do you put your logical around? It should include both >>>> edge(a,b) and reach(b,c), right? >>>> >>>> Another thought, can we have something like >>>> testExistsAndInsertLogical() to replace insertLogical()? But this may >>>> be buggy, as the conditions are all met, so the rule actually fired... >>>> >>> Hi, >>> >>> from my experience, insertLogical does exactly what >>> testExistsAndInsertLogical would suggest. If the same object is already >>> in the working memory, it keeps this object and does not insert another >>> instance. This behaviour is not stated explicitly in the documentation, >>> but I did a learning test a few weeks ago and IIRC it clearly showed >>> this behaviour (at least for 5.0.1). -- I consider this behaviour a >>> feature and would like it to be kept this way. >> I am using Drools 5.1.1, and I don't think insertLogical prevents >> duplicates automatically. This also boils down to the question of how >> Drools decides whether two objects are indeed the same. For strings >> and integers, it is straightforward, but not much so for complex >> objects. Is there a way to pass in a comparison function? > InsertLogical operates on equality mode, that is determined by the > pojo's equals() method implementation. If an object already exists that > is equal, it will use that and the justification counter for that > existing object is increased. But, insertLogical() is in the "then" part of the rule, which means at that point the rule is already fired... Without something like "not exists", the rules just keep firing... I've been trying to read the source code of drools-core, but haven't got to that level of details yet. My question is if a duplicated object is logically inserted, would that trigger another round of rule firing? If it's just justification counter update, it shouldn't be counted as object modification, right? Thanks. -Simon > > Mark >>> With this, all which is necessary to implement transitive closure is to >>> remove the contradicting part of the precondition to avoid oscillation. >>> If it turns out that insertLogical does not perform a "does fact already >>> exist" check and thus might potentially insert duplicates, put exists( ) >>> around the two preconditions and also use "exists( reach(x,y) )" to >>> check whether y is reachable from x. >> I don't quite follow. Can you elaborate with an actual rule? >> >> Thanks! >> -Simon >> >>> Kind regards >>> >>> Ansgar >>> ___ >>> rules-users mailing list >>> rules-users@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/rules-users >>> >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] unsolved myth regarding transitive closure using insertlogical...
On Sun, Feb 20, 2011 at 8:20 PM, Ansgar Konermann wrote: > On 19.02.2011 16:01, Simon Chen wrote: >> The example you gave seems to be the one-hop case. For the two-hop >> case, we need something like this >> >> when >> edge(a, b), reach(b, c), not exists reach(a, c) >> then >> insertLogical( reach(a,c) ) >> >> So, where do you put your logical around? It should include both >> edge(a,b) and reach(b,c), right? >> >> Another thought, can we have something like >> testExistsAndInsertLogical() to replace insertLogical()? But this may >> be buggy, as the conditions are all met, so the rule actually fired... >> > Hi, > > from my experience, insertLogical does exactly what > testExistsAndInsertLogical would suggest. If the same object is already > in the working memory, it keeps this object and does not insert another > instance. This behaviour is not stated explicitly in the documentation, > but I did a learning test a few weeks ago and IIRC it clearly showed > this behaviour (at least for 5.0.1). -- I consider this behaviour a > feature and would like it to be kept this way. I am using Drools 5.1.1, and I don't think insertLogical prevents duplicates automatically. This also boils down to the question of how Drools decides whether two objects are indeed the same. For strings and integers, it is straightforward, but not much so for complex objects. Is there a way to pass in a comparison function? > > With this, all which is necessary to implement transitive closure is to > remove the contradicting part of the precondition to avoid oscillation. > If it turns out that insertLogical does not perform a "does fact already > exist" check and thus might potentially insert duplicates, put exists( ) > around the two preconditions and also use "exists( reach(x,y) )" to > check whether y is reachable from x. I don't quite follow. Can you elaborate with an actual rule? Thanks! -Simon > > Kind regards > > Ansgar > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] unsolved myth regarding transitive closure using insertlogical...
On Sun, Feb 20, 2011 at 2:10 AM, Mark Proctor wrote: > On 19/02/2011 15:01, Simon Chen wrote: >> Let me make sure I get it correctly... >> >> The example you gave seems to be the one-hop case. For the two-hop >> case, we need something like this >> >> when >> edge(a, b), reach(b, c), not exists reach(a, c) >> then >> insertLogical( reach(a,c) ) >> >> So, where do you put your logical around? It should include both >> edge(a,b) and reach(b,c), right? >> >> Another thought, can we have something like >> testExistsAndInsertLogical() to replace insertLogical()? But this may >> be buggy, as the conditions are all met, so the rule actually fired... >> >> I really need this working, so I'll probably take a crack at modifying >> drools, although haven't done it before... > I'm just thinking about what it is you want to do. Do you wan to > pre-compute a matrix for fast lookup if C is reachable from A? Where the > integrity of that matrix is maintained by logical insertions? > > Or are you trying to do adhoc reachability with minimial maintained > state, no pre-calculated state, where performance is not such an issue? Hi Mark, Well, I came from the datalog world, where such issue doesn't exist. Basically, I am trying to mimic datalog's reachability rules in Drools. In datalog, we simply put: reachable(a,b) :- link(a,b) reachable(a,b) :- link(a,z), reachable(z,b) Insertion is always easy to handle, but deletion isn't, unless we keep some sort of dependency among different objects. It seems that insertLogic() in Drools is an easy way out, except for the tricky issue I mentioned in the original post. To answer your question, I have all sort of different objects flying around, and want to derive certain knowledge based on those objects. The derived knowledge should be dependent on the existing objects, which may change over time. This reachability is just an example of such recursive dependency. Thanks. -Simon > > Mark >> Thanks. >> -Simon >> >> On Saturday, February 19, 2011, Mark Proctor wrote: >>> I think to impl this what is needed is a "logical" node. At the moment >>> the entire LHS forms the justification. But if we supported a logical >>> node, we could do this: >>> rule "reachDirect" >>> salience 10 >>> when >>> logical( e : Edge(s1 : source, t1 : target) ) >>> not( Reach(source == s1, target == t1) ) >>> then >>> insertLogical( new Reach(e.getSource(),e.getTarget()) ); >>> System.out.println( "Reach " + e.getSource() + "," + >>> e.getTarget() ); >>> end >>> >>> >>> That means that it would be inserted when there was no Reach, but it >>> would only be retracted when there was no matching Edge. The >>> justification is only for the part of the rule that is in the logical >>> grouping. >>> >>> To do this is actually quite a trivial change in drools, but it's not >>> something we do now. I think one reason why I held off was that i was >>> looking at Jess and Clips that have this and they state you can have >>> multiple logical elements. But i could't figure out how having 2 or 3 >>> would differ, compare to having just one. >>> >>> Anway to support a singe logical element, you'd need to update the >>> parser to support 'logical' conditional element, in the same format as >>> 'not' and 'exists'. Then if you look at RuleTerminalNode you'll see the >>> part of the code that is related to removing the justifications, on a >>> retract or modify - removeLogicalDependencies. Likewise if you look in >>> the DefaultKnowlegeHelper you'll see how the insertion works. That could >>> would instead be copied to the logical node. If a logical node exists >>> the RTN should have an if statement so the same code does not execute again. >>> >>> Any takers? >>> >>> Mark >>> >>> >>> On 19/02/2011 05:20, Simon Chen wrote: >>>> Hi all, >>>> >>>> I know this is kinda an old topic, but I just couldn't get it working. >>>> >>>> Here is a previous attempt using insertLogical() to handle transitive >>>> closure: >>>> http://drools-java-rules-engine.46999.n3.nabble.com/transitive-closure-td56855.html#a56858 >>>> The problem with this one is that the newly "logically inserted" object >>>> would viol
Re: [rules-users] unsolved myth regarding transitive closure using insertlogical...
Let me make sure I get it correctly... The example you gave seems to be the one-hop case. For the two-hop case, we need something like this when edge(a, b), reach(b, c), not exists reach(a, c) then insertLogical( reach(a,c) ) So, where do you put your logical around? It should include both edge(a,b) and reach(b,c), right? Another thought, can we have something like testExistsAndInsertLogical() to replace insertLogical()? But this may be buggy, as the conditions are all met, so the rule actually fired... I really need this working, so I'll probably take a crack at modifying drools, although haven't done it before... Thanks. -Simon On Saturday, February 19, 2011, Mark Proctor wrote: > I think to impl this what is needed is a "logical" node. At the moment > the entire LHS forms the justification. But if we supported a logical > node, we could do this: > rule "reachDirect" > salience 10 > when > logical( e : Edge(s1 : source, t1 : target) ) > not( Reach(source == s1, target == t1) ) > then > insertLogical( new Reach(e.getSource(),e.getTarget()) ); > System.out.println( "Reach " + e.getSource() + "," + > e.getTarget() ); > end > > > That means that it would be inserted when there was no Reach, but it > would only be retracted when there was no matching Edge. The > justification is only for the part of the rule that is in the logical > grouping. > > To do this is actually quite a trivial change in drools, but it's not > something we do now. I think one reason why I held off was that i was > looking at Jess and Clips that have this and they state you can have > multiple logical elements. But i could't figure out how having 2 or 3 > would differ, compare to having just one. > > Anway to support a singe logical element, you'd need to update the > parser to support 'logical' conditional element, in the same format as > 'not' and 'exists'. Then if you look at RuleTerminalNode you'll see the > part of the code that is related to removing the justifications, on a > retract or modify - removeLogicalDependencies. Likewise if you look in > the DefaultKnowlegeHelper you'll see how the insertion works. That could > would instead be copied to the logical node. If a logical node exists > the RTN should have an if statement so the same code does not execute again. > > Any takers? > > Mark > > > On 19/02/2011 05:20, Simon Chen wrote: >> Hi all, >> >> I know this is kinda an old topic, but I just couldn't get it working. >> >> Here is a previous attempt using insertLogical() to handle transitive >> closure: >> http://drools-java-rules-engine.46999.n3.nabble.com/transitive-closure-td56855.html#a56858 >> The problem with this one is that the newly "logically inserted" object >> would violate its own "not exists" condition term, thus removing itself, >> then goes the infinite circle of insert/remove... >> >> Here is a post that deals with transitive closure using "insert", but it >> doesn't handle object removal correctly: >> http://drools-java-rules-engine.46999.n3.nabble.com/one-question-about-Transitive-Closure-td57289.html >> >> >> To me, using insertLogical is attractive because it doesn't require me to >> write specific rules to handle object removal. Is there a trick that I can >> use to actually implement transitive closure with insertLogical? >> >> Thanks a lot! >> -Simon >> ___ >> rules-users mailing list >> rules-users@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/rules-users >> >> > > > ___ > rules-users mailing list > rules-users@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/rules-users > ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] unsolved myth regarding transitive closure using insertlogical...
Hi all, I know this is kinda an old topic, but I just couldn't get it working. Here is a previous attempt using insertLogical() to handle transitive closure: http://drools-java-rules-engine.46999.n3.nabble.com/transitive-closure-td56855.html#a56858 The problem with this one is that the newly "logically inserted" object would violate its own "not exists" condition term, thus removing itself, then goes the infinite circle of insert/remove... Here is a post that deals with transitive closure using "insert", but it doesn't handle object removal correctly: http://drools-java-rules-engine.46999.n3.nabble.com/one-question-about-Transitive-Closure-td57289.html To me, using insertLogical is attractive because it doesn't require me to write specific rules to handle object removal. Is there a trick that I can use to actually implement transitive closure with insertLogical? Thanks a lot! -Simon ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
