#2774 closed feature request (done)
Individuals should be able to store additional data
Reported by: | mkommend | Owned by: | mkommend |
---|---|---|---|
Priority: | high | Milestone: | HeuristicLab 3.3.15 |
Component: | Optimization | Version: | 3.3.14 |
Keywords: | Cc: |
Description
Currently, an Individual wraps a scope and allows access to the solution (e.g., BinaryVector). However, one can't store additional information in the scope, because that is prohibited and enforced by access checks.
Change History (7)
comment:1 Changed 8 years ago by mkommend
- Status changed from new to accepted
comment:2 Changed 8 years ago by mkommend
- Owner changed from mkommend to abeham
- Status changed from accepted to reviewing
comment:3 Changed 8 years ago by abeham
Any ideas how we add this feature in the ProblemRefactoring branch?
comment:4 Changed 8 years ago by mkommend
Not really yet. The only option I could think of is to add some kind of key/value store (Dictionary?) to the solutions if necessary.
comment:5 Changed 8 years ago by abeham
I thought more about this yesterday evening and I think we're looking at this from the wrong side: It's not the inputs that we should modify (also because this creates side-effects), but the output. Simply speaking we have Evaluate methods that return more than just the fitness value (e.g. also information on whether the solution is feasible or not). And the problem is that our double return type is not flexible enough to accomodate additional results. We should change the signature to something like EvaluationResult Evaluate(...) where EvaluationResult holds a fitness as well as e.g. the Key-Value store that you proposed. The single-objective evaluator could then add the key-value elements into the scope as variables.
This creates some additional computational overhead because we have to create probably an additional 1 million instances of that class and there is some programming overhead for algorithms that need to write e.g. var quality = Evaluate(solution, random).Fitness. But I think the design is cleaner and more flexible.
For instance, we then have the potential to implement a CompareTo or IsBetter method in this class which would avoid if (maximization && a > b || !maximization && a < b) statements that are scattered over different classes when we also add a maximization property to the EvaluationResult.
comment:6 Changed 8 years ago by abeham
- Owner changed from abeham to mkommend
- Status changed from reviewing to readytorelease
Reviewed r14877.
No further comments apart from what has been said. We need to take care of this in ProblemRefactoring branch.
comment:7 Changed 7 years ago by mkommend
- Resolution set to done
- Status changed from readytorelease to closed
r14877: Allowed storing additional data in the scope of an individual.