Opened 5 months ago

Closed 3 months ago

#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 5 months ago by mkommend

  • Status changed from new to accepted

comment:2 Changed 5 months 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 5 months ago by abeham

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

comment:4 Changed 5 months 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 5 months 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 3 months 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 3 months ago by mkommend

  • Resolution set to done
  • Status changed from readytorelease to closed

r15116: Merged r14877 into stable.

Note: See TracTickets for help on using tickets.