[rules-users] Rule using accumulate

[Andrés Corvetto]

Once again, my lack of knowledge stands in the way... How would you write
the rule to perform the skipping?

Those requirements look fine, i would add:
(5) The matching of a Bid should be 'efficient' (for example: it should not
require to sort all Offers with the right price to match a Bid)

Let me know how it goes. And thank you very much for your time and
dedication!
- Andres

On Wed, Apr 28, 2010 at 12:12 PM, Wolfgang Laun <wolfgang.laun at gmail.com>wrote:

> 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 at 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 at 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 at 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-tp757311p761181.html
> >> > Sent from the Drools - User mailing list archive at Nabble.com.
> >> > _______________________________________________
> >> > rules-users mailing list
> >> > rules-users at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/rules-users
> >> >
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20100428/1a3455c4/attachment.html