Opened 6 years ago

Closed 4 years ago

#1833 closed defect (done)

Checked operator information is lost in run

Reported by: abeham Owned by: abeham
Priority: medium Milestone: HeuristicLab 3.3.9
Component: Operators Version: 3.3.6
Keywords: Cc:

Description (last modified by abeham)

The information which operator is checked in a CheckedMultiOperator<T> is lost in the run as the checked information is not collected. Related to #1695 that changed parameter collection.

Attachments (1)

CheckedInformation.PNG (6.3 KB) - added by abeham 4 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 5 years ago by gkronber

  • Milestone changed from HeuristicLab 3.3.7 to HeuristicLab 3.3.x Backlog

This issue has been discussed in the architects meeting. And it was decided that we do not fix this for milestone 3.3.7.

comment:2 Changed 4 years ago by gkronber

  • Milestone changed from HeuristicLab 3.3.x Backlog to HeuristicLab 3.3.9

Should not be too much effort to implement this.

comment:3 Changed 4 years ago by abeham

  • Owner changed from swagner to abeham
  • Status changed from new to accepted

Changed 4 years ago by abeham

comment:4 Changed 4 years ago by abeham

  • Description modified (diff)
  • Owner changed from abeham to gkronber
  • Status changed from accepted to reviewing

r9838: changed parameter collection for runs, so that the "checked" information is available.

There will be problems should an operator ever contain a value parameter called "Checked", that is to be collected and that operator is included in a checked multi operator. Currently, the string "Checked" doesn't appear in our solution anywhere.

Overall, I'm not that happy with how MultiOperators are collected. Keys such as "Crossover.0" are not helpful in the run analysis at all. Using the name of the operator (e.g. OrderCrossover2) instead of the parameter (e.g. 0) would make more sense, but unfortunately could lead to clashes when the same operator is added to a CheckedMultiOperator multiple times (e.g. in different parameterizations). Also the way the probabilities are collected (as array) is not suitable for analysis. What do you think?

comment:5 Changed 4 years ago by gkronber

Reviewed r9838.

The order of operators in the list is sometimes relevant. Therefore, it would not be useful to use the operator name as key in the results.

Further considerations:

  • unchecked operators do not have an effect so it would be sufficient to store only checked operators in the results. In this case we don't need to store the 'checked' flag separately
  • maybe we should not split the list of operators into separate results at all. Similarly to the list of probabilities, it could be sufficient to use only at the combination of (checked) operators in analyses. E.g., if a single crossover should be analysed the algorithm should be configured to use only that single operator. Instead if pairs of operators should be analysed in combination, then runs with different operator pairs should be executed, and it would be sufficient to have the operator combination as string in the results.

comment:6 Changed 4 years ago by gkronber

  • Owner changed from gkronber to abeham

comment:7 Changed 4 years ago by abeham

  • Status changed from reviewing to assigned

comment:8 Changed 4 years ago by abeham

  • Status changed from assigned to accepted

comment:9 Changed 4 years ago by abeham

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

r9934:

  • Changed behavior to output results only of those operators that have been checked
  • Removed additional "Checked" result

comment:10 Changed 4 years ago by gkronber

  • Owner changed from gkronber to abeham
  • Status changed from reviewing to readytorelease

Reviewed and tested r9934. This can be merged into stable.

comment:11 Changed 4 years ago by abeham

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

r9942: merged into stable branch

Note: See TracTickets for help on using tickets.