Thank you all for your feedback, I will try to implement at least the part of
collapsing the multiple evals() into a single one.
Edson Tirelli-4 wrote
>
>Also, I just read the example in your link where you have multiple
> accumulates in a single rule... that is *bad*
>
The accumulate()
Listen to what others are saying in this thread... it is very good
advice, specially what wolfgang suggests bellow regarding collapsing evals.
Also, I just read the example in your link where you have multiple
accumulates in a single rule... that is *bad*
For those that attended or s
A last effort from my side.
Given any number of bound variables a, b, c: to determine whether an
arbitrary boolean expression involving arithmetic and comparison
operators, a single eval() is sufficient and preferable to a CE
combination involving the CE operators "and", "or", "not" combining
many
Thanks for your explanation Edson, it makes sense now I think!
Basically what you are saying is that there is a limit, beyond which is no
longer feasible to use more ORs on a rule.
Edson Tirelli-4 wrote
>
> You are trying to avoid the issue. As reported by others, your
> conditions should be ins
You are trying to avoid the issue. As reported by others, your
conditions should be inside the patterns, not in "or'd" evals in the end,
and yes, it is possible to generate rules like that in an automated program.
Now, the reason it is taking so long is because of the "or"s. I don't
think th
I understand that the rule looks pointless and under-optimized, but it's the
only way I could represent this kind of rule in an automated way (I didn't
write the rule by hand). Basically with these rules I try to pre-compute the
amount of some products on the WM (using count() inside a accumulate
f
Hi,
There is something that I must ask... Why do you evaluate perfectly simple
patterns in an eval, I wonder?
rule "CONFIG_1-3UCO07"
salience -90
when
Number(rel_4226982244: intValue < 1 )
Number(rel_7521194: intValue < 1 )
Number(rel_787633980: intValue < 1 )
Number(qty_13315
There are 26 patterns Number(). Now I don't know how many facts of
that type you have, but this sequence will produce all combinations of
all available facts. (This is the worst example of this anti-pattern
I've seen.)
The or-ed evals will try to create parallel nodes in the network, and
the not s
As far as I remember, there were some fixes around compilation time for
edge cases in 5.4. Could you please give a try to 5.4 or even 5.5-SNAPSHOT?
Best Regards,
Esteban Aliverti
- Blog @ http://ilesteban.wordpress.com
On Tue, Jul 24, 2012 at 1:11 PM, W
laune wrote
>
> Well, I do mind the "nonsense Number()". There's no point in
> discussing this if you don't post an exact image of your rule.
>
> -W
>
There is a point, because the rule I've posted compiles and causes the same
problem, I've just removed redundant code to expose the problematic
On 24/07/2012, fx242 wrote:
> Hi,
>
> This single
> rule was taking all the 4h to compile!
> I'm using DROOLS 5.2 Final.
> The rule example below samples the problem (don't mind the nonsense
> Number()
> conditions):
>
Well, I do mind the "nonsense Number()". There's no point in
discussing this
Hi,
Recently I was trying to optimize the rule compilation time for my KB (~4K
rules).
I do a full KB compilation every night, as most of the rules are dynamic
generated/converted and managed by the business operators.
The compile time was not very good (around 3 hours on a 8 core Xeon CPU),
but i
12 matches
Mail list logo
