Opened 6 years ago

Closed 5 years ago

#1691 closed enhancement (done)

Default operators can not be specified in the problem

Reported by: mkommend Owned by: abeham
Priority: medium Milestone: HeuristicLab 3.3.7
Component: General Version: 3.3.7
Keywords: Cc:

Description

It is not possible to specify in the operators list of the problem, which of the operators (e.g., encoding specific crossover or mutator) should be taken as default operator. Currently the alphabetically first operator is taken instead. This behavior is caused by the ConstrainedValueParameterView and should be changed so that the first matching operator is selected. As a result the problem can specify the different default operators for the algorithms by changing the order of the operators in its collection.

Change History (22)

comment:1 Changed 6 years ago by mkommend

  • Owner changed from swagner to mkommend
  • Status changed from new to assigned

comment:2 Changed 6 years ago by mkommend

  • Component changed from Parameters.Views to General

comment:3 Changed 6 years ago by mkommend

  • Status changed from assigned to accepted

comment:4 Changed 6 years ago by mkommend

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

comment:5 Changed 5 years ago by mkommend

r7493: Reordered problem dependent operators in the GeneticAlgorithm and the OSGA.

Now the first matching operator (e.g. ICrossover) in the operators collection of the problem is assumed to be the default operator and is set if no previous value was set in the ConstrainedValueParameter.

comment:6 Changed 5 years ago by mkommend

r7509: Corrected setting of default operators in the GeneticAlgorithm & OSGA.

comment:7 Changed 5 years ago by mkommend

r7510: Updated LocalSearch to use default operators.

comment:8 Changed 5 years ago by mkommend

r7511: Updated IslandGA, NSGA2 and IslandOSGA to use default operators.

comment:9 Changed 5 years ago by mkommend

r7512: Updated PSO to use default operators.

comment:10 Changed 5 years ago by mkommend

r7516: Updated TabuSearch to use default operators.

comment:11 Changed 5 years ago by mkommend

r7517: Updated SimulatedAnnealing to use default operators.

comment:12 Changed 5 years ago by mkommend

r7518: Updated VariableNeighborHoodSearch to use default operators for the shaking factor parameter.

I was not sure if this should be also done for the LocalImprovmentOperator parameter as these operators are discovered by the plugin infrastructure and are not specified by the problem.

comment:13 Changed 5 years ago by mkommend

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

comment:14 Changed 5 years ago by mkommend

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

comment:15 Changed 5 years ago by mkommend

  • Status changed from assigned to accepted

comment:16 Changed 5 years ago by mkommend

r7524: Corrected parametrization of crossovers in IslandGeneticAlgorithm.

comment:17 Changed 5 years ago by mkommend

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

comment:18 Changed 5 years ago by abeham

r7626:

  • Set default operators for TSP to be OrderCrossover2, InversionManipulator, and StochasticInversionMultiMoveGenerator
  • Set default operators for QAP to be PartiallyMatchedCrossover, Swap2Manipulator, and ExhaustiveSwap2MoveGenerator
  • Added a TypeEqualityComparer to HeuristicLab.Common

comment:19 Changed 5 years ago by abeham

  • Owner changed from abeham to mkommend

I noticed in the GA that when setting the problem to a new type that uses the same encoding (e.g. first the TSP then the QAP), the default operators of the second problem are not used, but still those that were selected in the first. I think however it gets a bit complex if we'd detect these kind of situations.

The default LocalImprovementOperator in the VNS should be the most specific for the problem, because there can be general ones and problem specific ones. I leave it to you if you want to implement this.

I reviewed the specific changes in the range r7493:7524. Here's my conclusion:

Does the code follow the DevelopersGuidelines (style, naming conventions, etc.) and the DevelopersBestPractices?

  • Yes

Are suitable class, property and parameter names used?

  • No new classes, properties or parameters have been introduced in the changes

Is the code understandable or is there an appropriate comment?

  • The additions are understandable

Is backwards compatibility maintained?

  • Backwards compatibility is not affected

Is the code written according to already used concepts?

  • Yes, the code integrates nicely

Are existing components reused and/or is the code written in a way that it can be easily reused by other components?

  • The added code is not intended for reuse, though the setting of parameters follows a general pattern that could possibly be abstracted (not a priority though)

Were common pitfalls avoided (missing event handler registration in AfterDeserializationHook, missing members in cloning constructor)?

  • Does not apply

Do the common unit tests pass?

  • Relying on the build server here

Are the classes well designed?

  • Does not apply

Are the code files well structured?

  • Structure was not affected by the changes

comment:20 Changed 5 years ago by mkommend

r7658: Corrected GetHashCode in TypeEqualityComparer and updated operator discovery in TSP.

comment:21 Changed 5 years ago by mkommend

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

Reviewed changes in r7658 and r7626

comment:22 Changed 5 years ago by mkommend

  • Resolution set to done
  • Status changed from readytorelease to closed
  • Version changed from 3.3.5 to 3.3.7
Note: See TracTickets for help on using tickets.