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 tha
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
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,
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 appr
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
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 1 Offers and then 1 bid, it takes too much time to execute.
If understand correctly it's because of the "not Offer(creationTimestamp <
$ct)" c
i.e. pick an Offer o such that there does not exist another Offer with a
creationTimestamp less than o.creationTimestamp.
--- On Tue, 4/27/10, Andres Corvetto wrote:
> From: Andres Corvetto
> Subject: Re: [rules-users] Rule using accumulate
> To: rules-users@lists.jboss.org
> Date
A typical case for the "not" CE:
rule "Match Offer"
when
$b : PartiallyCoveredBid(uncoveredSize>0, $p:price)
$o : Offer(price<$p, alreadyUsed==false, $cts :
creationTimestamp )
not Offer( creationTimestamp < $cts )
then
Offers already have a creationTimestamp, that could be used for this.
However, it's not clear to me how to write a rule that matches only the
Offer with the minimum creationTimestamp.
Something like:
rule "Match Offer"
when
$b : PartiallyCoveredBid(uncoveredSize>0, $p:p
If the age of Offers is so important it ought to be represented as
fact data. If it cannot be added to the Offer itself, a proxy fact
could be created, combining a counter with an Offer reference. A high
salience rule for an Offer without OfferProxy would create this.
-W
On Mon, Apr 26, 2010 at 9
Thank you for your reply!
I understand your approach, and I think it could work if Offers were
inserted into the working memory after the Bid.
However, to implement your approach for already inserted Offers I think I
would need some way of forcing the matching Offer to be the oldest in
memory, is
I'm not going to propose a complete solution, merely the outline of a
different approach.
It would introduce a "PartiallyCoveredBid", which is a Bid with one or
more Offers associated with the original Bid. It extends a Bid with a
Collection of associated Offers (so far) and the accumulated size a
Hi guys,
I'm new to drools, and i'm trying to build a small prototype.
I have 2 entities in my model: Offers and Bids. Both have a size (and a
price). I need a rule that matches a single Bid with multiple Offers adding
up in size to the Bid size. Matched Offers have to be sorted
by (increasing) in
13 matches
Mail list logo
