Changeset 6042 for trunk/sources/HeuristicLab.Encodings.PermutationEncoding/3.3/Interfaces/IPermutationMultiNeighborhoodShakingOperator.cs

#1425

• Changed LocalImprovementOperators
  • Changed interface (made Problem a property, added a property that denotes the type of the problem that it can be applied on, added some general parameters)
  • Added some parameters and wiring
  • Changed move discovery and parameterization and added a helper class to ease finding compatible move operators
  • Discovering only IMultiMoveOperators and IExhaustiveMoveOperators and putting the multi move ones first
  • Fixed bug in Apply method that could create an endless string of nested execution contexts
  • Removed all problem specific analyzers in the two local improvement operators and only left the BestAverageWorstQualityAnalyzer since it doesn't make any sense to perform diversity or allele analysis during local improvement in the most common case and those analyzers take a lot of time (one can always add them manually should he/she be interested). The analyzers in the VNS's Analyzer parameter are left untouched.
• Removed shaking operator and interface from VNS plugin and added that to Optimization and Optimization.Operators
• Changed some ValueParameters to ConstrainedValueParameters and added type discovery to fill them (using the ProblemType property to get compatible local improvement operators)
• Added missing GPL license headers
• Changed some ValueParameters to the new FixedValueParameters
• Added an additional encoding specific ShakingOperator to each encoding and added that to each problem
  • reason is that only the problem/encoding can really decide if a shaking operator is meaningful or not
• Fixed an unrelated bug in the BestAverageWorstQualityAnalyzer that I encountered (and made the fix backwards compatible)
  • Also added a snippet for creating the backwards compatible comment marker and region
• Fixed the operator graph of the VNS main loop
  • The condition to continue only when the local search was not successful is not necessary and is not part of the VNS definition as far as I know it (only condition to break the inner loop is when k reaches k_max)
• Changed the ShakingOperator to input current index and output the maximum number of neighborhoods instead of a boolean that indicates that the last index has been reached since the maximum number is a little more generally useful and equally powerful in modeling
  • Remodeled the VNS main loop to check for k < k_max in order to continue the inner loop
• other changes that I forgot...

Still necessary

• test, test, test
• check for backwards compatible breakers
• add a maximum evaluated solutions stop criterion
• optionally: implement fast problem specific local search improvement operators that do not build on the whole generic overhead (e.g. a 2-opt TSP specific local search operator). The idea of VNS is really to converge to a local optimum which is difficult to achieve using the current rather limited termination options