We are actually writing a paper that, amongst other things, touches the
subject on how a LEAPS-like executed language (CHR) should/could behave
in these circumstances. We also had the fire-once versus fire-many
semantics debate at our research group, and the outcome is still more or
less undecided. Most agree that it should be fire-many (we have a
similar "resolution"), but some still believe fire-once is the way to go
(we have our own Alexander ;-)). Just to say: you are not alone
Alexander, but personally I'm happy to see the Drools people reach a
resolution towards the fire-many semantics!
Greets,
Peter
Michael Neale wrote:
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
