<div>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.</div><div>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.</div>
<div>(Note that the previous approach did work, just not very efficiently)</div><div><br></div><div>- Andres</div><br><div class="gmail_quote">On Wed, Apr 28, 2010 at 6:13 AM, Wolfgang Laun <span dir="ltr"><<a href="mailto:wolfgang.laun@gmail.com">wolfgang.laun@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Here is another way of matching Offers first-in first. It is based on<br>
a linked list connecting new Offers the way they arrive. You'll need<br>
another WME OfferList containing references to the head of the list<br>
and to the last element. An unlinked new Offer is added at the end.<br>
Matching is now done by looking at the "head" field of the OfferList<br>
WME, and a matched Offer is removed from the list. You'll probably<br>
need another field in an Offer to indicate the status (new, unmatched,<br>
matched) so that you don't get cycles in your loop firings.<br>
<br>
-W<br>
<br>
On Wed, Apr 28, 2010 at 3:43 AM, Andres Corvetto <<a href="mailto:acorvetto@gmail.com">acorvetto@gmail.com</a>> wrote:<br>
><br>
> Thank you for your answers.<br>
><br>
> I tried this approach (which yields much more elegant rules), but i'm afraid<br>
> it does not perform very well.<br>
> If I insert 10000 Offers and then 1 bid, it takes too much time to execute.<br>
> If understand correctly it's because of the "not Offer(creationTimestamp <<br>
> $ct)" clause in the LHS, which forces a comparison of every matching Offer<br>
> against every other Offer.<br>
><br>
> The motivation for my original post was to find a way of achieving the<br>
> results of an accumulator without having to sort all the matching Offers by<br>
> creationTimestamp.<br>
> Going back to that first approach (using an accumulator), I found that<br>
> Drools feeds the accumulator with the matching Offers in reverse order (ie,<br>
> newest first, LIFO).<br>
> Is this a natural consequence of the way facts are stored in the working<br>
> memory or is there a way of changing this behaviour (so that oldest are<br>
> feeded first, FIFO)?<br>
><br>
> Thanks again<br>
><br>
> - Andres<br>
><br>
> --<br>
> View this message in context: <a href="http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate-tp757311p761181.html" target="_blank">http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate-tp757311p761181.html</a><br>
<div class="im">> Sent from the Drools - User mailing list archive at Nabble.com.<br>
> _______________________________________________<br>
> rules-users mailing list<br>
</div>> <a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<div class="im">> <a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
><br>
<br>
_______________________________________________<br>
rules-users mailing list<br>
</div><a href="mailto:rules-users@lists.jboss.org">rules-users@lists.jboss.org</a><br>
<div><div></div><div class="h5"><a href="https://lists.jboss.org/mailman/listinfo/rules-users" target="_blank">https://lists.jboss.org/mailman/listinfo/rules-users</a><br>
</div></div></blockquote></div><br>