Opened 6 weeks ago

Last modified 6 weeks ago

#2774 reviewing feature request

Individuals should be able to store additional data

Reported by: mkommend Owned by: abeham
Priority: high Milestone: HeuristicLab 3.3.15
Component: Optimization Version: 3.3.14
Keywords: Cc:


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 (5)

comment:1 Changed 6 weeks ago by mkommend

  • Status changed from new to accepted

comment:2 Changed 6 weeks ago by mkommend

  • Owner changed from mkommend to abeham
  • Status changed from accepted to reviewing

r14877: Allowed storing additional data in the scope of an individual.

comment:3 Changed 6 weeks ago by abeham

Any ideas how we add this feature in the ProblemRefactoring branch?

comment:4 Changed 6 weeks 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 6 weeks 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.

Note: See TracTickets for help on using tickets.