[[ cc:'d back to the list for archival purposes ]]
> This can be considered a conflict resolution problem: "Of all
> the rules that evaluate to true which gets to run first?"
Ayup.
> How about a flexible priority system. Something like a special
> variable or type of variable to order the execution of rules that
> have made it to the agenda. The idea is to use the results of
> the evaluation of the condition part of the rule stored into the
> priority variable to control which rule's action part is run.
> (Highest priority rule wins.)
Okay, I'll try to wrap my mind around that.
> What you ask should happen to the other rules that are on the
> agenda with a lower priority? They don't run because of a
> conflict resolution principle that ILOG calls refraction. That is
> only the rule with the highest priority fires all other conditions
> being equal.
My algorithm for dealing with the agenda is thus:
1) Collect all possible firings and put them on the
Agenda.
2) Fire the first one on the agenda (right now, 'first'
is defined by oder added to the agenda, but we can
certainly make this more flexible). Remove the
item once its fired.
3) If the fired rule modifies or retracts objects that
are involved in currently unfired members of the agenda,
then remove those members from the agenda.
4) If the agenda is not empty, go to (2).
So, if an assertObject(..) makes 3 different rules match, then
the agenda is:
A = { r1, r2, r3 }
So, we fire r1, which might make modifications to objects
invalidating r3, but also makes modifications to match r4
and thus it gets added to the agenda, while r1, which was
fired is removed.
A = { r2, r4 }
Then, we fire r2, which makes no big changes, leaving:
A = { r4 }
So we fire r4, and the agenda is empty
A = { }
So, we then return from assertObject(..)
Instead of just 'picking one', I'm leaning towards firing all possible
ones, taking into account the side-effects of previously fired rules.
I think the only thing we really need, then, is support for the total
ordering of rules. I'd love more information, when you get the chance,
regarding retaining condition data for rule prioritization.
-bob
>
> I hope this helps. I'll try to be clearer about the explanation
> when I figure out a better way to express it in terms of the DROOLS
> engine.
>
> Stuart
>
> BTW, ILOG has introduced 'collections' and collection rules to
> enable do general aggregation.
>
>
>
>
> ---- On Thu, 13 Dec 2001, bob mcwhirter ([EMAIL PROTECTED]) wrote:
>
> >
> > Okay...
> >
> > In CVS now is a Supply-and-Demand example, which attempts to match
> > up buyers and seller.
> >
> > ./build.pl examples
> >
> > Anyhow, this has shown me that we might need some more functionality
> > in the core engine.
> >
> > While it does successfully match a buyer who's willing to pay what a
> > seller want, it does not optimize by linking the buyer to the cheapest
> > seller.
> >
> > We *could* accomplish this already with a SellerCollection which sorts
> > by price, and each buyer just works against the head of the list, but
> > that's just somewhat unnatural.
> >
> > Though, I'm at a loss for a better solution.
> >
> > Anyone with experience with JESS or JRules have any clue how/if they
> > accomplish sorting and aggregation?
> >
> > I know JRules does *something* with aggregation, where a Seller could
> > be aware not just that he has a Buyer, but how many Buyers match him
> > out there.
> >
> > I'm just not certain.
> >
> > Anyhow, I'm looking for discussion, and possibly use-cases, if you've
> > got them.
> >
> > Anyone think they need sorting/aggregation of root fact objects?
> >
> > -bob
> >
> >
> > _______________________________________________
> > drools-interest mailing list
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/drools-interest
> >
> >
>
_______________________________________________
drools-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/drools-interest
