timefold-solver
timefold-solver copied to clipboard
Filters for KOptListMove don't work yet?
Hello. Describe the bug After you made KOptListMove public, I tried to create trivial filter for it, but it didn't work. https://stackoverflow.com/questions/77619677/timefold-is-it-possible-to-filter-out-all-trivial-2opt-moves-for-planninglistva.
public class KOptFilter implements SelectionFilter<Table, KOptListMove> {
@Override
public boolean accept(ScoreDirector<Table> scoreDirector, KOptListMove kOptListMove) {
System.out.println(kOptListMove.getSimpleMoveTypeDescription() +" "+kOptListMove.getPlanningEntities().size()+" "+kOptListMove.getPlanningValues().size());
System.out.println(kOptListMove);
return true;
}
}
Expected behavior I expected some information in log, which would help me to understand, how filter out moves with firstEndpointIndex == secondEndpointIndex + 1
Actual behavior
But I haven't got any information in log. Instead I've got warning messages:
2024-01-16 11:26:26,118 WARN [ai.tim.sol.cor.imp.heu.sel.mov.dec.FilteringMoveSelector] (pool-7-thread-1) Bailing out of neverEnding selector (Filtering(ai.timefold.solver.core.impl.heuristic.selector.move.generic.list.kopt.KOptListMoveSelector@4b8a1b5)) after (0) attempts to avoid infinite loop.
And looks like k-opt moves weren't accepted at all. I couldn't find any "firstEndpointIndex" in log.
To Reproduce Create any filter for KOptListMove
Environment
Timefold Solver Version or Git ref: 1.6.0
Output of java -version:
java version "21" 2023-09-19 LTS
Java(TM) SE Runtime Environment (build 21+35-LTS-2513)
Java HotSpot(TM) 64-Bit Server VM (build 21+35-LTS-2513, mixed mode, sharing)
Output of uname -a or ver:
Microsoft Windows [Version 10.0.22621.3007]
Hello @AlexeyTrefilov,
thanks for reporting. There are good reasons why K-Opt moves would be filtered out even before the selection got to your filter. (For example, in cases where we could not find a single valid K-Opt move in your data set.) It could also be a bug in our code.
It is impossible to say which is the case without being able to step through the code. Please provide something that we can run on our end to see the problem.
(Also: we have already pre-filtered trivial K-Opt moves, and the way to filter out K-Opts of any particular K is to configure it using the minimumK and maximumK parameters. Therefore there should be no need for custom K-Opt filtering.)
Hello @AlexeyTrefilov,
thanks for reporting. There are good reasons why K-Opt moves would be filtered out even before the selection got to your filter. (For example, in cases where we could not find a single valid K-Opt move in your data set.) It could also be a bug in our code.
It is impossible to say which is the case without being able to step through the code. Please provide something that we can run on our end to see the problem.
If I remove filter from config, warnings will disappear and k-opt moves will return. Could you just add any trivial KOptListMove filter to any your model with KOptListMoves to reproduce the problem?
(Also: we have already pre-filtered trivial K-Opt moves, and the way to filter out K-Opts of any particular K is to configure it using the
minimumKandmaximumKparameters. Therefore there should be no need for custom K-Opt filtering.)
As I've mentioned, I want to filter out moves with firstEndpointIndex == secondEndpointIndex + 1, which reverse full route. I don't need them.
@AlexeyTrefilov Thanks for the information. We'll look into this if/when time permits.