[rules-users] Rule using accumulate

[Andrés Corvetto]

I couldn't help myself and started looking at the source code to find the
reason for the order in which facts are fed to the accumulator.
I found that in version 5.1.0 M1, JBRULES-2242 was fixed, which (as a side
effect, I guess) changes that order to insertion time, ascending (FIFO). The
class that keeps the facts is org.drools.util.RightTupleList.
I don't know if it is correct to rely on that order, but this could helpful
with the accumulator approach again.

- Andrés


On Wed, Apr 28, 2010 at 2:02 PM, Andrés Corvetto <acorvetto at gmail.com>wrote:

> 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/d73be96d/attachment.html