Dev restart

[cprudhom]

This branch is dedicated to a small revamp of the way restarts are managed.
The main idea is to avoid using a Move implementation to deal with restarts but to integrate this directly in the Solver object. Doing so, it becomes easier (well, doable) to remove or replace a restart policy.
In addition, strategies and variable selectors are instrumented to indicate if they are dynamic, that is learn-based objects that are to be combined with restarts to be more efficient. A warning is printed to the console (if warnings are enabled) to indicate poor combinations (such as dyn. strat. without restarts).

[sonatype-lift]

⚠️ 87 God Classes were detected by Lift in this project. Visit the Lift web console for more details.

[jgFages]

Why not putting the nextrestart variable in the abstract class?

[cprudhom]

You're right.
Well, that was because NO_RESTART singleton must not declare next, but I can manage that differently.

[jgFages]

Is there a benefit from declaring this class final?

[jgFages]

I find the concept of dynamic search quite vague and possibly confusing.
If it is really about restarts i would suggest a more explicit name, like isImprovedByRestarts.
However, i am not 100% convinced by the idea of this feature, because it often depends on the problem.

[cprudhom]

Indeed, the choice of the term and the concept it encapsulates are debatable.
However, it happens quite often (and this is notably the case of the default strategy 🤦) that the strategy/restarts couple is unsuitable.

However, this can be the subject of another RP with a more in-depth discussion.

[jgFages]

For instance here it is not so clear to me that we should recommend restarts

[cprudhom]

I agree, I asked myself the same question and made the choice that seemed most logical.

[jgFages]

Hi, I find the refactoring of the restart a very good idea, because it is indeed sometimes hard to follow.

What would the code look like to restart both on solutions and every 100 fails for instance?

I am just not so sure about the isDynamical function.
I feel it is not so easy to answer true or false to that question (exept for inputOrderLB). So i wonder if it is worth increasing the codebase, especially if it is just for a warning.

[cprudhom]

What would the code look like to restart both on solutions and every 100 fails for instance?

solver.setLubyRestart(100, new FailCounter(target, 0), 5000);
solver.setRestartOnSolutions();

I agree that the 2nd point must be discussed (somewhere else)

[jgFages]

Thanks for your answers!

What would the code look like to restart both on solutions and every 100 fails for instance?

solver.setLubyRestart(100, new FailCounter(target, 0), 5000);
solver.setRestartOnSolutions();

Before we had java ref().setMove(new MoveRestart(ref().getMove() , so the "set" was actually an add operation -> we had in the end the two restart strategies.

However, the new implementation looks like a real setter (the new Restarter will replace the previous one).
It is more consistent with the method name, but I feel the luby restart will be erased by the setRestartOnSolutions.
I would expect the two restarts to be linked by a call to setNext()... Maybe I missed something

[cprudhom]

True, that was my first intention but I didn't go through with it
I'll fix that.
I can do that with a factory, which may ease the definition of the restarter (and we can keep the setRestarter method as is) and hides implementation details.

[cprudhom]

Proposal :

Prop 0 (current):

model.getSolver().setLubyRestart(2, new FailCounter(model, 2), 25000);
model.getSolver().setRestartOnSolutions();

Prop 1:

model.getSolver().makeRestarter().luby(2).onFailure().upTo(25000).restartOnSolution();

Prop 2:

model.getSolver().setLubyRestart(2, new FailCounter(model, 2), 25000, true);

where true indicates that restart on solution is required.

I can keep Prop 0, but I think there is a side effect which allows to combine n restarts policy inadvertently (actually, I can add checks).
Prop 1 is quite verbose.
Prop 2 is not very flexible.

Pull request has been modified.