[rules-dev] Planner: should getBestSolution() return null when there is no initialized solution?
Geoffrey De Smet
ge0ffrey.spam at gmail.com
Tue Jun 28 06:04:14 EDT 2011
Op 28-06-11 11:23, Michael Anstis schreef:
> Not completely understanding why solver.solve() would only run for 1ms,
It seems stupid indeed, but there are some cases:
- Cancellation: the user presses the "terminate early" button
- Cancellation: the whole system is going down (ctrl-c / kill)
- In real-time planning cases, the answer is needed NOW (even though we
just started planning 1 or 10ms ago).
In that last case you'll probably still want to have an initialized
solution and configure it appropriate to do random initialization (=
really fast and really stupid) anyway.
So it looks like cancellation is the only real use case.
And I 'll support JBRULES-3105 "Planner: construction heuristics should
be able to optionally ignore terminateEarly until a solution is
initialized" in the future,
for the real-time planning case.
> isn't a partially initialised starting solution a runtime error and
> (3) have solver.getBestSolution() throw a
> "SolutionsNotInitialisedException" an option?
Intresting idea. It should definitely not be a checked exception. Let's
call this 3)
> 1) It returns null. So you 'll need to do null checks:
> Solution bestSolution = solver.getBestSolution();
> if (bestSolution == null) {
> // ... do things with bestSolution
> Score bestScore = bestSolution.getScore();
> }
>
> 2) It returns the partially initialized solution. So you'll need to do
> isBestSolutionInitialized checks:
> Solution bestSolution = solver.getBestSolution();
> if (solver.isBestSolutionInitialized()) {
> // ... do things with bestSolution
> Score bestScore = bestSolution.getScore();
> }
3) it throws a SolutionUninitialisedException (runtime exception)
If you configured JBRULES-3105, then this works:
Solution bestSolution = solver.getBestSolution();
// ... do things with bestSolution
Score bestScore = bestSolution.getScore();
Otherwise, you probably want to do this instead:
try {
Solution bestSolution = solver.getBestSolution();
// ... do things with bestSolution
Score bestScore = bestSolution.getScore();
} catch (SolutionUninitialisedException e) {
// ...
}
>
> On 28 June 2011 10:18, Geoffrey De Smet <ge0ffrey.spam at gmail.com
> <mailto:ge0ffrey.spam at gmail.com>> wrote:
>
> Normally you use Planner like this:
>
> solver.solve()
> Solution bestSolution = solver.getBestSolution();
> // ... do things with bestSolution
> Score bestScore = bestSolution.getScore();
>
> But let's suppose we give it 1 millisecond to plan and use a big,
> uninitialized starting solution
> and our initialization algorithm actually terminates immediately as
> requested.
> It won't be able to completely initialize the solution in that case.
> What should solver.getBestSolution() return in that case? null or the
> partially initialized solution?
>
> 1) It returns null. So you 'll need to do null checks:
> Solution bestSolution = solver.getBestSolution();
> if (bestSolution == null) {
> // ... do things with bestSolution
> Score bestScore = bestSolution.getScore();
> }
>
> 2) It returns the partially initialized solution. So you'll need to do
> isBestSolutionInitialized checks:
> Solution bestSolution = solver.getBestSolution();
> if (solver.isBestSolutionInitialized()) {
> // ... do things with bestSolution
> Score bestScore = bestSolution.getScore();
> }
>
> What makes more sense?
>
> --
> With kind regards,
> Geoffrey De Smet
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org <mailto:rules-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/rules-dev
>
>
>
> _______________________________________________
> rules-dev mailing list
> rules-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/rules-dev
--
With kind regards,
Geoffrey De Smet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-dev/attachments/20110628/2e38b1ce/attachment-0001.html
More information about the rules-dev
mailing list