Advanced Mapping

Advanced Mapping Concepts

Choice Types

For structural choices that are shared among several parameters in the space, choice type can be defined as a means to reduce redundancy. An example in the context of evolutionary algorithms:

<SChoiceType id="Mutation">
		<NParam type="integer" id="Points" inclMin="1" />
		<NParam type="double" id="Probability" exclMin="0" exclMax="1" />
</SChoiceType>

The type can now be reused with the following reference:

<SChoice id="StringMutation" type="Mutation">
	<NParam type="double" id="Probability" exclMin="0.7"	exclMax="0.95" />
</SChoice>

In this example, the probability range has been narrowed down for this specific use. The implementation of StringMutation in the mapping can now point to a specific implementation of choice.

Mapping Types

Mapping types are similar to choice types, with the difference that they are specified in the code mapping, and that they are not restricted to choices, but can be used for structural and numerical parameters too. Mapping types follow the exact same syntactical structure as mappings, with the difference that they can be referred to as in:

 <Mapping id="StringCrossover.Probability" type="Probability">

Numeric Wrappers

Numeric Wrappers ensure that type consistency for framework specific wrapper classes can be guaranteed without losing expressiveness with InPUT. One example is the probability values in the Watchmaker framework, which are wrapped by a proprietary Probability class. However, the class simply wraps numeric values, and should in the design space not be defined as a structural, but a plain type (see above). In the code mapping, the wrapper can be specified, as follows:

<MappingType id="Probability" get="doubleValue">
    <Wrapper type="org.uncommons.maths.random.Probability" />
</MappingType>

Here, for reasons of reusability, the probability is defined as a mapping type. The "get" tag tells InPUT how the primitive value can be retrieved from the wrapper, while the Wrapper element defines type, getter, setter, and constructor of the wrapper (in this case only type).

Complex Parameter Types

Complex parameter types grew from the need to offer user customized abstract datatypes where simple array parameter definitions are not enough, or simply not supported by a framework. In the design mapping, they are defined as usual, as array types:

  <SParam id="Operators" type="[3]">
		<SChoice id="Mutation" type="StringMutation"/>
		<SChoice id="Crossover" type="StringCrossover"/>
	</SParam>

In the mapping though, they are defined to be of complex type. The example is based on the Watchmaker operators abstraction, that allows a genetic algorithm to have multiple operators to be executed in a row:

  <Mapping id="Operators" type="org.uncommons.watchmaker.framework.EvolutionaryOperator">
	<Complex type="se.miun.itm.watchmaker.CustomizableEvolutionPipeline" add="addOperator"/>
   </Mapping>

We therefore extended the EvolutionPipeline that watchmaker provides by a customizable variant, with the addOperator methods which is required for the injection based setting of operators. InPUT can now treat the internal mapping, and will return a fully initialized operator from the Java code, by:

EvolutionaryOperator operators = design.getValue("Operators");

This operator can contain multiple choice entries, which can have been randomly initialized, or set by a design file, as in:

<SValue id="Operators">
     <SValue id="1" value="Crossover">
      <NValue id="Probability" value="0.6" />
      <NValue id="Points" value="2" />
    </SValue>
    <SValue id="2" value="Mutation">
      <NValue id="Probability" value="0.01" />
    </SValue>
    <SValue id="3" value="Crossover">
      <NValue id="Probability" value="0.75" />
      <NValue id="Points" value="1" />
    </SValue>
  </SValue>

In this case, it would mean that a crossover is first applied followed by a mutation operator and a final second crossover operator. It is further possible to set certain positions as fixed, in order to make sure that they are always applied:

<SParam id="Operators" type="[3]" fixed=".. .. Mutation">
	...
</SParam>

This means that the third position in any random drawing is always a mutation. If the first position is always supposed to be a crossover instead, this could be expressed as in fixed="Crossover" (the wildcard does not have to be set in that case). A combination would also be valid with fixed="Crossover .. Mutation".