Free cookie consent management tool by TermsFeed Policy Generator

Opened 13 years ago

Closed 13 years ago

#1308 closed defect (done)

Michalewicz Manipulators fail when used in MultiRealVectorManipulator

Reported by: cneumuel Owned by: abeham
Priority: medium Milestone: HeuristicLab 3.3.3
Component: Encodings.RealVectorEncoding Version: 3.3.3
Keywords: Cc:

Description (last modified by abeham)

Exception when MichalewiczNonUniformOnePositionManipulator or MichalewiczNonUniformAllPositionsManipulator are used in MultiRealVectorManipulator: "MichalewiczNonUniformOnePositionManipulator: Parameter Iterations could not be found."

Reason:

  • The ActualName of the parameter Iterations is not set correctly (only when used in an MultiRealVectorManipulator). The ActualName should be set to Generations.

Steps to reproduce:

  • Create genetic algorithm
  • Add single objective test function as problem
  • In algorithm parameters select MultiRealVectorManipulator as Mutator
  • Start the algorithm

Change History (7)

comment:1 Changed 13 years ago by cneumuel

  • Description modified (diff)

comment:2 Changed 13 years ago by abeham

  • Description modified (diff)
  • Milestone changed from HeuristicLab x.x.x to HeuristicLab 3.3.3

That's true and an ugly problem. In order to wire this correctly the MultiRealVectorManipulator would need to translate the parameter. Which means that all Multi(Manipulator|Crossover) operators would need to translate all parameters of all the operators that they hold. This can't be done dynamically because the operator needs to implement the respective interface.

In any case we should fix this in the next release.

comment:3 Changed 13 years ago by abeham

  • Status changed from new to accepted

comment:4 Changed 13 years ago by abeham

r5140

  • Removed Michalewicz* operators from MultiRealVectorManipulator

I changed the MultiRealVectorManipulator to stop discovering types and instead specified the few that are in Encodings.RealVector directly. The user can add arbitrary manipulators for himself again and configure them accordingly. There is no other elegant way to solve this problem, because MultiRealVectorManipulator would need to implement any interface of any operator that it can contain to support automatic wiring.

comment:5 Changed 13 years ago by abeham

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

comment:6 Changed 13 years ago by cneumuel

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

comment:7 Changed 13 years ago by mkommend

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