[rules-users] Is Drools suitable for preprocessing my Resource Allocation Problem

[Raphael Jolivet]

Thanks very much for this detailled anbwser.
this helps me much.

I am currently playing with Drools, and trying to build rules in Java from
my own Rule objects, with the help of the lang.api.

Here are some comments in the flow of your anwsers

>
> > The optimizer takes as input (among others) a list of forbiden
> allocations
> > that should be generated based on some user-provided rules.
>
> to me you mean "generating an allocation plan".
> drools-planner is for you, especially if your users want to define more
> complex rules.


Actually, there is a optimization-team that already worked on that and came
up with their own solution.
They also evaluated Drool-planner for the "planning" part but went another
direction for several reasons.

I am only working here into transforming the complex user-filled rules into
"forbid" pairs as an input
to the optimizer.

I might use drools-planner for this.


> and here it sounds like a service that has a stream to consume ?
> then just write rules, put a session in a separate thread, and send him
> your stream as input.
> You can even use drools-fusion time operators.
>

No a stream, but yes, this is a service that will stay up and act as a
method :
Return the list of forbids for a given list of activities and resources.
I will pretty much build a knowledge base, and then, from time to time,
feed it with data, fire the rules and
look for forbid pairs.

 > Performance constraints
> > Here are some rough hints about the volumetry of the problem :
> > * 1000 activities
> > * 200 resources
> > * 50 rules
> >
> > I need the forbidden allocations to be generated in under a minute.
>
> is it the due time for you plan ?
>

This is a due time, for an acceptable response time to the user.


>
> > Instead, I would try to match the resources and the activities separately
> > on each rule (each side of the rule), and then assemble the couples that
> > match at least one common rule.
>
> RETE will do that for you
>
> > Also, I would add some counter on each rule that would auto increment
> upon
> > each match, in order to apply first the rules that match often.
>
If there is a session in a thread, ie maintaining its kownledge over time,
> RETE will do that for you, by propagating only the updates to the matching
> rules (forward chaining).
>

Not sure if I get it.
If I have two rule A and B that may produce the same forbid pairs, I want
to produce this pair only once.
For that, I will use inference and produce a :

insert(new Forbid(ressource, activity))

Then, in each rule, I will check that this forbid is not already present.

So my question is :
Will Drools "learn" from preivous processings and "learn" that rule A
matches more often than rule B ? And so will it promote A to be processed
first ?
Even if I flush the working memory between two calls ?


> If you speak about optimisation using local search, drools-planner will do
> that for you (by using the previous, may be with adding so custom moves
> generators).
>
> > QuestionsIs the engine of Drools smart enought for that ? Or is he even
> > smarter ?
> If the point is to process forbidden associations, yes, drools can be
> smarter than that.
> I whould even say that drools shoud be used only if you want to do to more
> than that.


Hmm, yes, this is the dilemma :
I think that, for this particular problem, I could write an algorithm
myself.
I am trying to understand how Drools works in its guts, to foresee if
it is a good investment for the future.

For example, we are beginning to think about neighborhood forbids,
to forbid pairs of allocations <<Res1, Act1>, <Res2, Act2>> ...

> Do you have an example of Drools being used in a similar problem with
> > success ?
> optim : drools-planner and its cloud balancing sample
> real-time stream : look at drools-fusion samples and also drools-expert
> doc (to get the basis of what rules can do)


Thanks for those hints.
Brgds,

Raphael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20121211/76ffcc39/attachment.html