6:50 p.m.
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) insertion time .
I have managed to write a rule using 'accumulate', but i feel it's not too
efficient, since i have to match every Offer in the working memory with the
right price, sort them and then pick the first n ones.
Here's the rule:
rule "Match Bids"
when
$b : Bid($s:size, $p:price)
$i : OfferAccumulator(acumSize >= $s) from accumulate ( $o:Offer(price<=$p)
,
init(OfferAccumulator accum = new OfferAccumulator($s); ),
action( accum.add($o);),
reverse ( accum.remove($o);),
result( accum ))
then
System.out.println( "Matched Bid:" + $b + "," + $i.getOffers());
end
and here's OfferAccumulator:
public class OfferAccumulator {
private int sizeLimit=0;
private int accumSize=0;
Set<Offer> offers = new TreeSet<Offer>();
public OfferAccumulator(int sizeLimit) {
this.sizeLimit = sizeLimit;
}
public void add(Offer op) {
accumSize+=op.getSize();
offers.add(op);
}
public void remove(Offer op) {
if (offers.remove(op)) {
accumSize-=op.getSize();
}
}
public List<Offer> getOffers() {
List<Offer> ret = new ArrayList<Offer>();
int accum=0;
Iterator<Offer> it = offers.iterator();
while (it.hasNext() && acum<sizeLimit) {
Offer offer = it.next();
accum+=offer.getSize();
ret.add(offer);
}
return ret;
}
}
Can you think of a more efficient way of achieving the same result? Is there
a way of controlling the order in which facts are feeded to the accumulator?
Thanks in advance!
Andres
7:46 p.m.
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 and
prize. A rule to add another Offer to the PartiallyCoveredBid would
have to check that the PartiallyCoveredBid isn't fully covered yet,
and that the Offer isn't contained in the "associated" Collection.
This should provide an opportunity to select the next Offer by
smallest prize/size ratio or other criteria.
Note that this is just a sketchy idea - your requirements may not
permit this approach - but I have a gut feeling that this may permit a
more flexible approach.
HTH
-W
2010/4/26 Andrés Corvetto <acorvetto(a)gmail.com>:
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) insertion time .
I have managed to write a rule using 'accumulate', but i feel it's not too
efficient, since i have to match every Offer in the working memory with the
right price, sort them and then pick the first n ones.
Here's the rule:
rule "Match Bids"
when
$b : Bid($s:size, $p:price)
$i : OfferAccumulator(acumSize >= $s) from accumulate ( $o:Offer(price<=$p)
,
init(OfferAccumulator accum = new OfferAccumulator($s); ),
action( accum.add($o);),
reverse ( accum.remove($o);),
result( accum ))
then
System.out.println( "Matched Bid:" + $b + "," + $i.getOffers());
end
and here's OfferAccumulator:
public class OfferAccumulator {
private int sizeLimit=0;
private int accumSize=0;
Set<Offer> offers = new TreeSet<Offer>();
public OfferAccumulator(int sizeLimit) {
this.sizeLimit = sizeLimit;
}
public void add(Offer op) {
accumSize+=op.getSize();
offers.add(op);
}
public void remove(Offer op) {
if (offers.remove(op)) {
accumSize-=op.getSize();
}
}
public List<Offer> getOffers() {
List<Offer> ret = new ArrayList<Offer>();
int accum=0;
Iterator<Offer> it = offers.iterator();
while (it.hasNext() && acum<sizeLimit) {
Offer offer = it.next();
accum+=offer.getSize();
ret.add(offer);
}
return ret;
}
}
Can you think of a more efficient way of achieving the same result? Is there
a way of controlling the order in which facts are feeded to the accumulator?
Thanks in advance!
Andres
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
9:43 p.m.
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 that possible?
The rule would be something like:
rule "Match Offer"
when
$b : PartiallyCoveredBid(uncoveredSize>0, $p:price)
$o : Offer(price<$p. alreadyUsed==false, [this is the oldest Offer in
memory with these conditions])
then
[ add Offer $o to Bid $b]
end
Thanks again
Andrés
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
Sent from the Drools - User mailing list archive at Nabble.com.
8:16 a.m.
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:43 PM, Andres Corvetto <acorvetto(a)gmail.com> wrote:
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 that possible?
The rule would be something like:
rule "Match Offer"
when
$b : PartiallyCoveredBid(uncoveredSize>0, $p:price)
$o : Offer(price<$p. alreadyUsed==false, [this is the oldest Offer in
memory with these conditions])
then
[ add Offer $o to Bid $b]
end
Thanks again
Andrés
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:56 p.m.
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:price)
$o : Offer(price<$p, alreadyUsed==false, creationTimestamp<[all other
matching Offer creationTimestamps ])
then
[ add Offer $o to Bid $b]
end
is that possible?
- Andres
Wolfgang Laun-2 wrote:
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:43 PM, Andres Corvetto <acorvetto(a)gmail.com>
wrote:
>
> 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 that possible?
> The rule would be something like:
>
> rule "Match Offer"
> when
> $b : PartiallyCoveredBid(uncoveredSize>0, $p:price)
> $o : Offer(price<$p. alreadyUsed==false, [this is the
> oldest Offer in
> memory with these conditions])
> then
> [ add Offer $o to Bid $b]
> end
>
> Thanks again
> Andrés
> --
> View this message in context:
>
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
> Sent from the Drools - User mailing list archive at Nabble.com.
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
Sent from the Drools - User mailing list archive at Nabble.com.
4:38 p.m.
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
[ add Offer $o to Bid $b]
end
-W
On Tue, Apr 27, 2010 at 3:56 PM, Andres Corvetto <acorvetto(a)gmail.com> wrote:
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:price)
$o : Offer(price<$p, alreadyUsed==false, creationTimestamp<[all
other
matching Offer creationTimestamps ])
then
[ add Offer $o to Bid $b]
end
is that possible?
- Andres
Wolfgang Laun-2 wrote:
>
> 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:43 PM, Andres Corvetto <acorvetto(a)gmail.com>
> wrote:
>>
>> 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 that possible?
>> The rule would be something like:
>>
>> rule "Match Offer"
>> when
>> $b : PartiallyCoveredBid(uncoveredSize>0, $p:price)
>> $o : Offer(price<$p. alreadyUsed==false, [this is the
>> oldest Offer in
>> memory with these conditions])
>> then
>> [ add Offer $o to Bid $b]
>> end
>>
>> Thanks again
>> Andrés
>> --
>> View this message in context:
>>
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
>> Sent from the Drools - User mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:01 p.m.
Use an existence check:
rule "Match Offer"
when
$b :PartiallyCoveredBid(uncoveredSize>0, $p:price)
$o :Offer(price<$p, alreadyUsed==false, $ct:creationTimestamp)
not Offer(creationTimestamp < $ct)
then
[ add Offer $o to Bid $b]
end
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 <acorvetto(a)gmail.com> wrote:
From: Andres Corvetto <acorvetto(a)gmail.com>
Subject: Re: [rules-users] Rule using accumulate
To: rules-users(a)lists.jboss.org
Date: Tuesday, April 27, 2010, 8:56 AM
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:price)
$o :
Offer(price<$p, alreadyUsed==false,
creationTimestamp<[all other
matching Offer creationTimestamps ])
then
[ add Offer $o to Bid
$b]
end
is that possible?
- Andres
Wolfgang Laun-2 wrote:
>
> 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:43 PM, Andres Corvetto
<acorvetto(a)gmail.com>
> wrote:
>>
>> 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 that possible?
>> The rule would be something like:
>>
>> rule "Match Offer"
>> when
>> $b :
PartiallyCoveredBid(uncoveredSize>0, $p:price)
>> $o : Offer(price<$p.
alreadyUsed==false, [this is the
>> oldest Offer in
>> memory with these conditions])
>> then
>> [ add Offer $o to Bid $b]
>> end
>>
>> Thanks again
>> Andrés
>> --
>> View this message in context:
>>
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
>> Sent from the Drools - User mailing list archive
at Nabble.com.
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
--
View this message in context:
http://drools-java-rules-engine.46999.n3.nabble.com/Rule-using-accumulate...
Sent from the Drools - User mailing list archive at
Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:43 a.m.
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...
Sent from the Drools - User mailing list archive at Nabble.com.
11:13 a.m.
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(a)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...
Sent from the Drools - User mailing list archive at Nabble.com.
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
3:44 p.m.
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(a)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(a)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...
> Sent from the Drools - User mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
5:12 p.m.
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(a)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(a)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(a)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...
> > Sent from the Drools - User mailing list archive at Nabble.com.
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
7:02 p.m.
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(a)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(a)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(a)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(a)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...
>> > Sent from the Drools - User mailing list archive at Nabble.com.
>> > _______________________________________________
>> > rules-users mailing list
>> > rules-users(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/rules-users
>> >
>>
>> _______________________________________________
>> rules-users mailing list
>> rules-users(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
>
_______________________________________________
rules-users mailing list
rules-users(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
8:08 p.m.
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(a)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(a)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(a)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(a)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(a)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...
> >> > Sent from the Drools - User mailing list archive at Nabble.com.
> >> > _______________________________________________
> >> > rules-users mailing list
> >> > rules-users(a)lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/rules-users
> >> >
> >>
> >> _______________________________________________
> >> rules-users mailing list
> >> rules-users(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
> > _______________________________________________
> > rules-users mailing list
> > rules-users(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/rules-users
> >
> >
>
> _______________________________________________
> rules-users mailing list
> rules-users(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>
5105
days inactive
5107
days old
12 comments
4 participants
participants (4)
-
Andres Corvetto -
Andrés Corvetto
-
Greg Barton -
Wolfgang Laun