I agree with Peters last description. If people only want it once, then thats an extra constraint they will need to include somehow.
On 4/27/06, Alexander Bagerman <[EMAIL PROTECTED]> wrote: > > No, I don't happy with resolution:-) but I've got leaps working in > exactly the same way and now it's more like rete in its certain areas. > Will be checking updates in later today. > > On 4/26/06, Michael Neale <[EMAIL PROTECTED]> wrote: > > OK so is this resolved? > > Alex are you happy with this resolution? > > > > > > On 4/26/06, Michael Neale <[EMAIL PROTECTED] > wrote: > > > > > > which is what it does now, if I understand correctly. > > > > > > > > > > > > On 4/26/06, Peter Lin < [EMAIL PROTECTED]> wrote: > > > > ahh ok. > > > > > > > > if "dishonest" is asserted and retracted, the rule engine should > fire as > > > > many times as the conditions are met. > > > > > > > > if the rule engine didn't fire as "dishonest" is asserted and > retracted > > over > > > > time, the behavior would be incorrect. this is assuming a long > running > > > > process with a single rule engine. > > > > > > > > peter > > > > > > > > On 4/25/06, Alexander Bagerman <[EMAIL PROTECTED]> wrote: > > > > > > > > > > This is not Leaps question. My problem is that if "dishonest" fact > > > > > continuously asserted and retracted it should not cause the > > > > > "honestAbe" to fire more than once but what happen with current > tests > > > > > is that rules with no positive CEs will fire as many times as > > > > > "blocking" facts are retracted. > > > > > > > > > > On 4/25/06, Peter Lin <[EMAIL PROTECTED] > wrote: > > > > > > I'm having a hard time understanding the basic problem being > > > > > address. let > > > > > > me see if I understand part of it. Say I have rule > > > > > > > > > > > > rule honestAbe > > > > > > when > > > > > > Politician is in office > > > > > > NOT dishonest > > > > > > then > > > > > > allow him to stay in office > > > > > > end > > > > > > > > > > > > rule firePoliticians > > > > > > when > > > > > > there are no honest Politicians > > > > > > then > > > > > > fire all politicians > > > > > > end > > > > > > > > > > > > What I'm missing is the meaning of "blocking the rule" for > LEAPS. In > > the > > > > > > classic LEAPS approach, rules do not "block" each other in the > sense > > > > > that > > > > > > one rule prevents another rule from firing. Miranker's LEAPS has > no > > > > > agenda > > > > > > and executes the consequence (aka RHS) immediately. > > > > > > > > > > > > In the case of a NOT join, if some list of facts from the left > match > > a > > > > > fact > > > > > > on the right, it would prevent that specific combination from > > > > > propogating. > > > > > > If the right fact is retracted, then all matches on the left > would > > be > > > > > > retracted and the activation removed from the agenda. In the > case > > of > > > > > leaps, > > > > > > the rule already fired, so the only thing it can do is retract > the > > fact. > > > > > the > > > > > > activation has already fired, so there's nothing to retract. I > > looked > > > > > at > > > > > > the drools LEAP code today and it looks it's a hybrid between > LEAPS > > and > > > > > > RETE. > > > > > > > > > > > > in the interest of solving the problem, the problem should be > broken > > > > > down > > > > > > into > > > > > > > > > > > > 1. rules with no positive CE and only NOT CE > > > > > > 2. loop / no loop > > > > > > 3. if a rule should only fire once, an "exist" pattern should be > > used. > > > > > > > > > > > > peter > > > > > > > > > > > > > > > > > > > > > > > > On 4/25/06, Alexander Bagerman < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > What I'm saying that NO "Something" is not qualified and it > should > > not > > > > > > > matter if you now you retracted fact-1 that was blocking the > rule > > and > > > > > > > later you retracted fact-3 that happens to block rule at that > > moment - > > > > > > > I'd expect rule to fire once. > > > > > > > > > > > > > > I'd expect rule-1 in Edson example to fire just once. Forget > > logical > > > > > > > assertion for a second - imagine that you assert and retract > > String() > > > > > > > facts. So everytime fact is retracted rule fires in current > > > > > > > implementation. Rule states that it should fire when NO > String() > > facts > > > > > > > exists and not when String() fact happen to be retracted. At > least > > > > > > > that is how I see it. > > > > > > > > > > > > > > And to Michael's point that "there is no "fire only once" in > the > > > > > > > contract of the rule. " What if the same rule has a "positive" > > > > > > > condition in it (in addition to the "NO"). Would you expect it > to > > fire > > > > > > > on each blocking fact retraction as well? I'd say probably > not. > > > > > > > > > > > > > > Anyway, I think I need to do more thinking on what and how but > > feel > > > > > > > free to share your thought on this subject. > > > > > > > > > > > > > > On 4/25/06, Michael Neale < [EMAIL PROTECTED]> wrote: > > > > > > > > If I understand in my pre-caffeinated state, then I think > what > > you > > > > > are > > > > > > > > saying is: > > > > > > > > > > > > > > > > We start off with NO "Something" in WM. > > > > > > > > The rule "R" fires. > > > > > > > > > > > > > > > > We add "Something" to WM > > > > > > > > nothing happens > > > > > > > > > > > > > > > > We remove "Something" from WM > > > > > > > > The rule "R" fires again. ** > > > > > > > > > > > > > > > > Now in ReteOO ** will happen. In LEAPS it does not? > > > > > > > > > > > > > > > > Well, the answer is allways: WWJD: What Would Jess Do ? > > > > > > > > I am thinking the ReteOO way is what I would intuitively > expect, > > as > > > > > > > there is > > > > > > > > no "fire only once" in the contract of the rule. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/26/06, Alexander Bagerman <[EMAIL PROTECTED]> wrote: > > > > > > > > > All, > > > > > > > > > While going through fixing logical assertion tests for > leaps I > > > > > > > > > realized that I might not be able to support behavior for > > rules > > > > > with > > > > > > > > > no positive conditions in the way RETEOO does. Please do > not > > skip > > > > > the > > > > > > > > > rest of the email saying "that's ok, leaps is > experimental" > > :-) > > > > > > > > > > > > > > > > > > Here is an issue - loop / no loop tests rely on multiple > > > > > activation of > > > > > > > > > the rules that have the following structure: > > > > > > > > > rule "r" > > > > > > > > > when > > > > > > > > > not Something > > > > > > > > > then > > > > > > > > > ... > > > > > > > > > end > > > > > > > > > > > > > > > > > > You would expect this rule to fire only once but in > reality > > > > > (RETEOO > > > > > > > > > reality) it fires first time its "when" section is valid > (even > > if > > > > > > > > > there was not ever blocking facts) and than every time > when > > rule > > > > > goes > > > > > > > > > from "have blocking facts can not fire" to "ok, last > blocking > > fact > > > > > is > > > > > > > > > removed, I can fire now". Does it break a paradime that > states > > > > > that > > > > > > > > > rule can fire only once on same conditions? Let's say I > have > > one > > > > > more > > > > > > > > > condition in "when" section like that: > > > > > > > > > rule "r" > > > > > > > > > when > > > > > > > > > someFact is matching condition > > > > > > > > > and not Something > > > > > > > > > then > > > > > > > > > ... > > > > > > > > > end > > > > > > > > > > > > > > > > > > I would expect this rule to fire only once, even if it > goes > > from > > > > > "have > > > > > > > > > blocking facts can not fire" to "ok, last blocking fact is > > > > > removed, I > > > > > > > > > can fire now" multiple times assuming that someFact was > not > > > > > retracted. > > > > > > > > > > > > > > > > > > What are your thoughts on it? > > > > > > > > > > > > > > > > > > -Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
