Re: [rules-users] Rule using accumulate
Processing one Bid at a time, the solution is simple: skip offers
exceeding the Bid price.
If you have multiple Bids, select one (due to whatever) and mark it
with a Token WME.
This is developing into a very nice demo/exercise. The summary of requirements:
(1) Bid: price, size
(2) Offer: price, size, seqno
(3) Collect Offer facts so that sum(size) >= Bid.size, price <= Bid.price
(4) Offers must be used in increasing seqno
Is this complete? I'm going to do implement this now.
-W
2010/4/28 Andrés Corvetto <acorvetto(a)gmail.com>:
The problem with this approach is that a Bid may not always match the
head
of the list, because the price of the head Offer could be higher.
Given a Bid, I need to match it with the oldest Offer with equal o lower
price, and that Offer could be in any index of the list.
(Note that the previous approach did work, just not very efficiently)
- Andres
On Wed, Apr 28, 2010 at 6:13 AM, Wolfgang Laun <wolfgang.laun(a)gmail.com>
wrote:
>
> Here is another way of matching Offers first-in first. It is based on
> a linked list connecting new Offers the way they arrive. You'll need
> another WME OfferList containing references to the head of the list
> and to the last element. An unlinked new Offer is added at the end.
> Matching is now done by looking at the "head" field of the OfferList
> WME, and a matched Offer is removed from the list. You'll probably
> need another field in an Offer to indicate the status (new, unmatched,
> matched) so that you don't get cycles in your loop firings.
>
> -W
>
> On Wed, Apr 28, 2010 at 3:43 AM, Andres Corvetto <acorvetto(a)gmail.com>
> wrote:
> >
> > Thank you for your answers.
> >
> > I tried this approach (which yields much more elegant rules), but i'm
> > afraid
> > it does not perform very well.
> > If I insert 10000 Offers and then 1 bid, it takes too much time to
> > execute.
> > If understand correctly it's because of the "not
> > Offer(creationTimestamp <
> > $ct)" clause in the LHS, which forces a comparison of every matching
> > Offer
> > against every other Offer.
> >
> > The motivation for my original post was to find a way of achieving the
> > results of an accumulator without having to sort all the matching Offers
> > by
> > creationTimestamp.
> > Going back to that first approach (using an accumulator), I found that
> > Drools feeds the accumulator with the matching Offers in reverse order
> > (ie,
> > newest first, LIFO).
> > Is this a natural consequence of the way facts are stored in the working
> > memory or is there a way of changing this behaviour (so that oldest are
> > feeded first, FIFO)?
> >
> > Thanks again
> >
> > - Andres
> >
> > --
> > View this message in context:
> >
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
> > Sent from the Drools - User mailing list archive at Nabble.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