Add a tutorial on how to implement a new problem/solver #426
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nhuet
force-pushed
the
tuto-howto
branch
4 times, most recently
from
ae4dd1a to
50931d9
Compare
This allows IDE like vscode to auto-generate the skeleton of child classes. (It was already the case for pycharm) To avoid raising a TypeError, - remove unused not implemented abstract method in MultiskillRcpspProblem - Implement change_problem() for WTSolution
For instance, in knapsack, we cache the computed value and weight in the solution. While the use of `force_recompute_values` can fix the issue, we could as in other mutations use a lazy copy of the solution before mutation.
- `__init__()` stores problem
- `change_problem()` update the attributes
- consequences for implemented `Solution` child classes
- call `super().__init__()`
- add annotation type for attribute `problem`
- implement `change_problem()` only when evaluation results are cached
into the solution in order to invalidate them.
- remove copies of attributes in `change_problem()`
(done via `copy()` and `lazy_copy()` methods)
As already in SolverDO
convert_to_variable_values enables warmstart but is not necessary for a mere solve. So we avoid forcing users to implement it.
Run evaluation if cached results not there (like length)
- Problem: evaluate(), evaluate_mobj(), and satisfy() - Mutation: mutate() and mutate_and_compute_obj() We should keep arg name from the inherited method (as the user can call it with named arg which respect the inherited method)
They are not mandatory in general but - get_dummy_solution: nice to have to have a trivial solution for a given problem - evaluate_from_encoding: mandaotry to run Ga and Nsga solvers
g-poveda
reviewed
Dec 12, 2025
Collaborator
There was a problem hiding this comment.
Hi, good for me, i think a following change would be to even more simplify the solver signature, with
[objective_handling, objective_weights, objectives] -> the params objectivefunction should be enough.
- EncodingRegister wraps a dict that maps
- attribute name (was not always the case)
- to a AttributeType (new class to take place of TypeAttribute
enumeration) which gathers the necessary fields (length, lows, ups,
range, ...)
- the new class AttributeType allows hierarchy of attribute types (list
boolean knapsack < list boolean< list integer)
- the mutation catalog maps this nex AttributeType classes to mutations
classes with their kwargs
- get_available_mutations(): only the second output was used so we keep
only this one, enriched with the attribute name on which the mutation
will be applied. So it returns more mutations: before if a problem
declared 2 solution attributes with same type, only one mutation was
applied to the first one, now we will return a mutation per attribute.
- create_mutations_portfolio_from_problem: utility function to create a
portfolio with available mutations in a problem according
to the mutation catalog
- Mutation.build is now a classmethod so that a generic method can be
written in base class calling the __init__ of the mutation class with
the given kwargs
- Mutation.__init__ defined stroing the problem and taking **kwargs so
that build always pass.
- SingleAttributeMutation subclass created to share the code finding the
proper attribute name according to expected attribute type, when
attribute not specified by user.
- mutations renaming to be more consistent within the library
- mutations shared for rcsp and rcsp_multiskill put in
generic_rcpsp_tools
This is used by GA which already reconstruct a solution (at the end of solve()) from the encoding. So a natural implementation (and which was reproduced in each implementation) is to - reconstruct the solution - apply self.evaluate on it All the mechanics to build other necessary solution attributes is reported in solution.__init__.
- create a common base class to share code - use new AttributeType class - update tests & examples with valid encoding names
Drop support of "objectives", "objective_weights" and "objective_handling" in genetic algorithm in favor of "params_objective_function", to be more consistent with the library api.
nhuet
force-pushed
the
tuto-howto
branch
2 times, most recently
from
57fa161 to
5a5299d
Compare
- Fix typos - Reformulate some sentences - Add a section about key classes/concepts of d-o
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.