1:33 p.m.
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
9:35 p.m.
Hi Simon,
Could you tell me a bit more about your logic below in code level? I
can't imagine how it goes.
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
Benson
On Tue, Mar 8, 2011 at 3:33 AM, Simon Chen <simonchennj(a)gmail.com> wrote:
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
10:25 p.m.
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 <simonchennj(a)gmail.com>
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
Edson Tirelli
JBoss Drools Core Development
JBoss by Red Hat @ www.jboss.com
10:49 p.m.
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 <ed.tirelli(a)gmail.com>:
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 <simonchennj(a)gmail.com>
>
> 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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
1:41 a.m.
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 <simonchennj(a)gmail.com> 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 <ed.tirelli(a)gmail.com>:
>
> 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 <simonchennj(a)gmail.com>
>>
>> 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(a)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(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
9:59 p.m.
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 <wolfgang.laun(a)gmail.com>:
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 <simonchennj(a)gmail.com> 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 <ed.tirelli(a)gmail.com>:
> >
> > 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 <simonchennj(a)gmail.com>
> >>
> >> 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(a)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(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
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
11:24 a.m.
On 9 March 2011 04:59, Simon Chen <simonchennj(a)gmail.com> wrote:
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.
My statement about avoiding a mix of given and derived facts was
definitely exaggerating matters. But the representation of Link vs.
Reachable merits some consideration.
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?
No-loop is almost never satisfactory.
It's necessary to avoid duplications of Reachable. You can't add a "not"
CE
to
block this, but it's possible to configure against the insertion of equal
facts.
For this, equals() and hashCode() must be implemented properly, and the
AssertBehaviorOption.EQUALITY must be set.
I have found this to work quite well:
public class Reachable {
private String src;
private String tgt;
//...
public boolean equals(Object obj) {
if (this == obj) return true;
if( ! (obj instanceof Reachable)) return false;
Reachable other = (Reachable) obj;
return other.src.equals( src ) && other.tgt.equals( tgt );
}
}
public class Link extends Reachable {
public Link( String src, String tgt ){
super(src, tgt);
}
}
Notice that this subclassing avoids the creation of Reachable for each Link.
And I still think that computing the closure should be done by using
Reachable only. Note the absence of no-loop!
rule deriveReachReach
when
Reachable( $src: src, $mid: tgt )
Reachable( src == $mid, $tgt: tgt != $src )
then
insertLogical( new Reachable( $src, $tgt ));
end
kbConfig.setOption( AssertBehaviorOption.EQUALITY ); // identical and
equal not inserted
kBase = KnowledgeBaseFactory.newKnowledgeBase( kbConfig );
Cheers
-W
Thanks.
-Simon
5043
days inactive
5045
days old
6 comments
4 participants
participants (4)
-
Benson Fung -
Edson Tirelli -
Simon Chen -
Wolfgang Laun