I’m using Optaplanner 8.15.0 to solve a variant of the redistricting problem: Geographic areas with an expected revenue are assembled to sales districts that must be contiguous and should be balanced and compact.
The initial solution is generated by a custom phase using a greedy heuristic. Afterwards a local search hill climbing phase makes big and obvious improvements to that using custom moves. Only then, the “real” optimization starts with a tabu search.
The configuration of the first two phases:
<customPhase>
<customPhaseCommandClass>project.solver.SeedGrowthInitialSolution</customPhaseCommandClass>
</customPhase>
<localSearch>
<localSearchType>HILL_CLIMBING</localSearchType>
<moveListFactory>
<moveListFactoryClass>project.move.SplitAndJoinMoveFactory</moveListFactoryClass>
</moveListFactory>
<termination>
<unimprovedSecondsSpentLimit>60</unimprovedSecondsSpentLimit>
</termination>
</localSearch>
It turned out that the quality (=score) of the overall solution depends very much on the quality of the initial solution after the second phase. I.e. the tabu search will improve the solution substantially, but it’s not able to “fix” a bad initial solution.
Is there a way to run the first two phases repeatedly to generate several candidate solutions and then continue with the best of them?
My current workaround is to start several instances manually, watch the logs for the achieved scores after the first two phases and restart all instances where the initial scores are not promising.
The answer is no, when the problem is specified like this. However, we could maybe change the problem statement a bit. If you run multiple independent solvers and, at the end, pick the best result, you can then pass that to a new solver which will start from there. This would be a variant of multi-bet solving. It is not supported out of the box, but would be relatively easy to code yourself, using either the Solver or SolverManager APIs.
That said, your entire approach is very unconventional. Custom construction heuristic is understandable, as are custom moves. But the fact that you feel the need to separate the moves into different phases makes me curious. Have you benchmarked this to be the best possible approach?
I would think that using the default local search (late acceptance), with your custom moves and our generic moves all thrown into the mix, would yield decent results already. If that fails to happen, then generally either your constraints need to be faster, or the solver needs to run for longer. For large problems, multi-threaded solving can help, too.
Related
I'm using Optaplanner to make a schedule for a school. Every works good, except that it sometimes have gaps between the lessons, which I do not want. I have rules for punishing this but I think the search space is so big that it will take quite a while before it "fixes" this.
Is it possible to tell Optaplanner to try out some "selected/calculated" moves first and then continue with the moves it is supposed to do?
I'm using the time grain patterns with this.
It is possible to do, but not recommended. There is good literature on the subject here: https://www.optaplanner.org/docs/optaplanner/latest/move-and-neighborhood-selection/move-and-neighborhood-selection.html
I would start first by experimenting with configuring the generic moves that are provided out-of-the-box in optaplanner, which you can do by editing the XML file included with the distribution.
If a custom move is really what you need, you can refer to the docs above, but it is much harder to avoid bugs this way and you will want to enable full assert to double-check that score corruption is not occurring after implementation.
I created a solution based on the task assigning example of OptaPlanner and observe one specific behavior in both the original example and my own solution:
Solving the 100tasks-5employees problem does hardly produce new better scores after half a minute or so, but terminating the solver and restarting it again does immediately bring up better solutions.
Why does this happen? In my understanding the repeated construction heuristic does not change any planning entity as all of them are already initialized. Then local search is started again. Why does it immediately find new better solutions, while just continuing the first execution without interruption does not or at least much slower?
By terminating and restarting the solver, you're effectively causing Late Acceptance to do a reheating. OptaPlanner will do automatic reheating once this jira is prioritized and implemented.
This occurs on a minority of the use cases. But if it occurs on a use case, it tends to occur on all datasets.
I've some cases workaround it by configuring multiple <localSearch> phases with <unimprovedSecondsSpentLimit> terminations, but I don't like that. Fixing that jira is the only real solution.
I'm trying to develop a chess program. It will be regular bruteforce searching of a tree, the only thing different will be the evaluation. Initially I will use a standard evaluator as designed by Claude Shannon so that it is more easy to test if it works fine at the base. Move list generation and all other infra around it works fine.
Now for the searching: I would like to use the alpha/beta pruning code example of wikipedia.
And that's what is a bit of a problem: it is ambiguous about one thing; from who's perspective should the evaluation be done? I've been googling for days (literally) but no example says this explicitly.
So: should the evaluation be
from the point of view of the "current mover" at that depth
from the point of view of the "opponent of current move" at that depth
from the point of view of the mover at the root of the tree, e.g. the person for who this tree-search is being done (the AI player)
from the point of view of the opponent of the mover at the root of the tree
?
I experimentally tried rootSide, side, rootOpponent, well basically all options and then let them play against each other. The outcome of that was that "current mover at that depth" would be the one to use (it won most frequently) but testing that version against any other engine result in 100% loss.
Of course wikipedia will be updated to be more clear about it! (please ignore the note on the side in the wikipedia history: that was from myself which might be incorrect so I removed it)
Evaluation should be performed from the perspective of the node invoking it. This is your first case, and it is the only one that really makes sense.
If you're testing your very basic engine against other complete engines then yes you can expect to lose every match. You are missing lots of techniques so playing against other engines is not a good method of testing right now. Once your engine is stronger then yes you can use this method to improve strength or perform regression testing.
I'd recommend setting up simple positions and playing with it manually to look at whether it can see basic captures, checks, checkmates, etc. Be warned that even with a perfect implementation of alpha-beta and simple evaluation that your engine will still blunder at times. This is because of the fixed search horizon so next you may want to look into quiescence search.
When I look at optimization problems I see a lot of options. One is linear programming. I understand in abstract terms how LP works, but I find it difficult to see whether a particular problem is suitable for LP or not. Are there any heuristics that can help guide this decision?
For example, the work described in Is there a good way to do this type of mining? took weeks before I saw how to structure the problem correctly. Is it possible to know "in advance" that problem could be solved by LP, without first seeing "how to phrase it"?
Is there a checklist I can use to decide whether a problem is suitable for LP? Is there a standard (readable) reference for this topic?
Heuristics (and/or checklists) to decide if the problem at hand is really a Linear Program.
Here's my attempt at answering, and I have also tried to outline how I'd approach this problem.
Questions that indicate that a given problem is suitable to be formulated as an LP/IP:
Are there decisions that need to be taken regularly, at different time intervals?
Are there a number of resources (workers, machines, vehicles) that need to be assigned tasks? (hours, jobs, destinations)
Is this a routing problem, where different "points" have to be visited?
Is this a location or a "layout" problem? (Whole class of Stock-cutting problems fall into this group)
Answering yes to these questions means that an LP formulation might work.
Commonly encountered LP's include: Resource allocation.: (Assignment, Transportation, Trans-shipment, knapsack) ,Portfolio Allocation, Job Scheduling, and network flow problems.
Here's a good list of LP Applications for anyone new to LPs or IPs.
That said, there are literally 1000s of different types of problems that can be formulated as LP/IP. The people I've worked with (researchers, colleagues) develop an intuition. They are good at recognizing that a problem is a certain type of an Integer Program, even if they don't remember the details, which they can then look up.
Why this question is tricky to answer:
There are many reasons why it is not always straightforward to know if an LP formulation will cut it.
There is a lot of "art" (subjectivity) in the approach to modeling/formulation.
Experience helps a lot. People get good at recognizing that this problem can be "likened" to another known formulation
Even if a problem is not a straight LP, there are many clever master-slave techniques (sub-problems), or nesting techniques that make the overall formulation work.
What looks like multiple objectives can be combined into one objective function, with an appropriate set of weights attached.
Experienced modelers employ decomposition and constraint-relaxation techniques and later compensate for it.
How to Proceed to get the basic formulation done?
The following has always steered me in the right direction. I typically start by listing the Decision Variables, Constraints, and the Objective Function. I then usually iterate among these three to make sure that everything "fits."
So, if you have a problem at hand, ask yourself:
What are the Decision Variables (DV)? I find that this is always a good place to start the process of formulation. How many types of DV's are there? (Which resource gets which task, and when should it start?)
What are the Constraints?
Some constraints are very readily visible. Others take a little bit of teasing out. The constraints have to be written in terms of your decision variables, and any constants/limits that are imposed.
What is the Objective Function?
What are the quantities that need to be maximized or minimized? Note: Sometimes, it is not clear what the objective function is. That is okay, because it could well be a constraint-satisfaction problem.
A couple of quick Sanity Checks once you think your LP formulation is done:
I always try to see if a trivial solution (all 0s or all big
numbers) is not part of the solution set. If yes, then the
formulation is most probably not correct. Some constraint is
missing.
Make sure that each and every constraint is "related"' to
the Decision Variables. (I occasionally find constraints that are
just "hanging out there." This means that a "bookkeeping constraint"
has been missed.)
In my experience, people who keep at it almost always develop the needed intuition. Hope this helps.
There used to be a graph that tracked the implementation of Perl6 against the test suite for Perl6. I was interested in watching it progress (and, regress). What happened to that graph, it used to be hosted on the site www.rakudo.de
Is there any other easy way an outsider can get an idea of where Rakudo stands in relation to the perfected spec? What features is it yet-missing?
As for he second question, the way is the feature comparison matrix.
There is no official place for spectest graphs, but there are some good ones too
I used to run a cron job that generated the graph, and eventually stopped it. The reason was that lots of people put way too much weight into the numbers of that graph, and generally assumed that the test suit was perfect, covering all features of the spec homogeneously etc.
In addition there's no easy way to count the number of total tests, making the numbers not very reliable.
In the end I had the feeling that the graph was more misleading than informative.
The best way to get a feeling for the progress is to become an insider, ie start playing with Rakudo. It's still lots slower than Perl 5 (though not as much as it used to be), but it's quite usable, and fun to use.