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 <[email protected]>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 <[email protected]>: > > 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 <[email protected]> > > 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 <[email protected]> > >> 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 > >> > [email protected] > >> > https://lists.jboss.org/mailman/listinfo/rules-users > >> > > >> > >> _______________________________________________ > >> rules-users mailing list > >> [email protected] > >> https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > _______________________________________________ > > rules-users mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/rules-users > > > > > > _______________________________________________ > rules-users mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/rules-users >
_______________________________________________ rules-users mailing list [email protected] https://lists.jboss.org/mailman/listinfo/rules-users
