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

_______________________________________________
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users