[rules-users] Drools Planner changing problem fact

Geoffrey De Smet ge0ffrey.spam at gmail.com
Wed Jul 18 02:48:16 EDT 2012


Op 17-07-12 20:54, Garf schreef:
> last month, Ralph wrote: /All the examples in the drools-planner-examples
> seem to have a fixed list of problem facts (rooms, teachers, timeslots)
> which only should be combined optimally./
>
> Just to address this one unanswered point.
> The Cloud Balancing example does support changing the problem facts,
> specifically by removing computers (bins).
>
> The last section of the planner documentation (section 12.4) addresses
> realtime planning, through the Solver.addProblemFactChange() API. This works
> whether you are removing problem facts (as the example shows) or modifying
> their contents.
>
> This generally restarts the Solver -- but, if you are relatively optimized,
> the adjustment is found relatively fast.
Internally, it restarts the Solver, but not from scratch, it restarts 
starting from the best solution of the last run.
As a Solver user, you don't even notice this in your code, you just call 
addProblemFactChange().
And it only takes milliseconds to find a feasible solution, see the log 
below this video:
http://blog.athico.com/2011/07/real-time-planning-with-drools-planner.html
>   (I'm curious, though -- does the
> Solver expressly prioritize doing moves associated with those problem facts
> that were just changed?)
Not really, unless you count this:
A construction heuristic will only assigning the unassigned entities,
so any entity that gets unassigned (because of the problem fact change) 
gets changed first.
For example a machine (=problem fact) got killed, so all it's processes 
(= entities) are unassigned and they get assigned first.
After that, normal localSearch kicks in.

But you could prioritize moves that affect those associated problem 
facts if you wanted to.
In 5.4 that's very hard to do, but 5.5.0.Beta1 will introduce an 
interface ProbabilitySelectionWeightFactory to make it easy to do such 
stuff.
I fear it's still going to require domain-specific code though, even if 
it's just a class implementing that interface.
>
> --
> View this message in context: http://drools.46999.n3.nabble.com/Drools-Planner-changing-problem-fact-tp4018087p4018742.html
> Sent from the Drools: User forum mailing list archive at Nabble.com.
> _______________________________________________
> rules-users mailing list
> rules-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-users
>

-- 
With kind regards,
Geoffrey De Smet






More information about the rules-users mailing list