Free cookie consent management tool by TermsFeed Policy Generator

Opened 7 years ago

Closed 5 years ago

#2740 closed defect (done)

Multi encoding operators are not parameterized correctly

Reported by: abeham Owned by: abeham
Priority: medium Milestone: HeuristicLab 3.3.16
Component: Optimization Version: trunk
Keywords: merged Cc:

Description

Please bear with me, the problem requires some understanding of the implemented algorithms, encodings and the parameter lookup and wiring. I'll try to explain:

The problem surfaces when using a multi-encoded problem with ALPS. An exception will be thrown, that the random number generator is not found. ALPS doesn't have a "Random" parameter, but uses a "LocalRandom" RNG instance for each layer in addition to a "GlobalRandom" RNG instance. Algorithms are responsible to scan all of the problem's operators that implement the IStochasticOperator interface and parameterize them accordingly, ALPS does this as well. However, if the operator is never seen by the algorithm wiring will not occur. All that ALPS sees is e.g. the MultiEncodingSolutionCreator, but not the solution creator of each encoding.

The solution would be to implement IStochasticOperator on all multi encoding operators. Then the algorithms would parameterize these and the name translation would work to identify the right RNG to use. This would work for random parameters. ALPS would then correctly parameterize the operators with LocalRandom. But the general problem of not being able to parameterize individual operators remains. A general solution however cannot be to return all operators of the embedded encodings as a concatenation as this would cause, e.g. individual crossovers to appear in the crossover parameter as well.

This problem has never surfaced earlier, because every other algorithms calls the RNG instance Random which is the default name in all operators and which thus find it "by chance".

Change History (11)

comment:1 Changed 7 years ago by mkommend

A possible solution for this would be to extend the IMultiEncodingOperator interface with a method IEnumerable<IOperator> GetOperators() that returns all possible operators that can be used (e.g. ISolutionCreators for the MultiEncodingSolutionCreator). This would enable algorithms that wire certain parameters to handle MultiEncodingOperators specifically by wiring the operators returned by GetOperators instead of the MultiEncodingOperator.

This might not be the most elegant solution and requires every algorithm that is able to handle MultiEncodings and wires parameters to be adapted. An advantage however is, that no side-effects could possible occur, because of the new code necessary to utilize this method.

Version 0, edited 7 years ago by mkommend (next)

comment:2 Changed 7 years ago by gkronber

  • Milestone changed from HeuristicLab 3.3.15 to HeuristicLab 3.3.16
  • Owner changed from architects to abeham
  • Status changed from new to assigned

comment:3 Changed 7 years ago by abeham

  • Version 3.3.14 deleted

comment:4 Changed 5 years ago by abeham

  • Owner changed from abeham to mkommend
  • Status changed from assigned to reviewing
  • Version set to trunk

r16782: Fixed problem with local random number generator and multi-encoding in ALPS

comment:5 Changed 5 years ago by abeham

r16783: Fixed wiring issue in OS-ALPS too

comment:6 Changed 5 years ago by mkommend

Reviewed r16782 and r16783.

Is this only an issue for ALPS algorithms or are other algorithms such as IslandGA also affected and should be adapted? If that is not the case the ticket can be released.

Last edited 5 years ago by mkommend (previous) (diff)

comment:7 Changed 5 years ago by mkommend

  • Owner changed from mkommend to abeham

comment:8 Changed 5 years ago by abeham

  • Status changed from reviewing to readytorelease

It's the same in IslandGA

comment:9 Changed 5 years ago by abeham

  • Keywords depends-2520 added

comment:10 Changed 5 years ago by abeham

  • Keywords merged added; depends-2520 removed

r17111: merged to stable (16782, 16783)

comment:11 Changed 5 years ago by abeham

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