Default operators can not be specified in the problem

[mkommend]

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.

[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.

[mkommend]

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

[mkommend]

r7510: Updated LocalSearch to use default operators.

[mkommend]

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

[mkommend]

r7512: Updated PSO to use default operators.

[mkommend]

r7516: Updated TabuSearch to use default operators.

[mkommend]

r7517: Updated SimulatedAnnealing to use default operators.

[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.

[mkommend]

r7524: Corrected parametrization of crossovers in IslandGeneticAlgorithm.

[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

[abeham]

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

[mkommend]

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

[mkommend]

Reviewed changes in r7658 and r7626