Population Constraints

Population's Constraints

Basically, population's constraints describe the structure of an individual in the experiment you are trying to run. For example, if you are trying to find the highest point in an function with n variables, a work-in-progress individual in this problem will be a set of n real numbers; if you are trying to find an assembly program able to set apart between odd and even number, then your individual will be an assembly program.

This is probably the most useful feature of µGP: thanks to the great flexibility of the constraints file, it is able to represent almost all kind of individuals, ranging from trivial to extremely complex. Note that constraints.xml is the default name for the file, but the effective name must be specified in the apposite option of your population's settings file (usually named population.settings.xml, but the effective name of the population file is specified in ugp3.settings.xml).

Constraints strictly follow the internal structure of individuals (described here). The XML file defining constraints is composed of any number of type definitions, and one or more sections.

<constraints>
    <typeDefinitions>
        <item item_attributes>
            ... 
        </item>
        ...
    </typeDefinitions> 

    <prologue prologue_attributes>
        <expression>
            ...
        </expression>
        <parameters>
            ...
        </parameters>
    </prologue>
    <epilogue epilogue_attributes>
        <expression>
            ...
        </expression>
        <parameters>
            ...
        </parameters>
    </epilogue>

    <sections>
        <section section_attributes>
            ...
        </section>
        <section section_attributes>
            ...
        </section>
        ...
    </sections>
</constraints>

The Section Element

Each section contains a prologue, and epilogue and an arbitrary number of subsections. Prologue and epilogue are full fledged macros, see their definition later.

<section section_attributes>
    <prologue prologue_attributes>
        <expression>
            ...
        </expression>
        <parameters>
            ...
        </parameters>
    </prologue>
    <epilogue epilogue attributes >
        <expression>
            ...
        </expression>
        <parameters>
            ...
        </parameters>
    </epilogue>
    <subSections>
        <subSection subsection_attributes>
            ...
        </subSection>
        <subSection subsection_attributes>
            ...
        </subSection>
        ...
    </subSections>
</section>

More details can be found in the Section page, Prologue page, and Epilogue page.

The Subsection Element

Each subsection contains a prologue, and epilogue and an arbitrary number of macros. Also prologue and epilogue are macros, see their definition later.

<subSection subsection_attributes>
    <prologue prologue_attributes>
        <expression>
            ...
        </expression>
        <parameters>
            ...
        </parameters>
    </prologue>
    <epilogue epilogue_attributes>
        <expression>
            ...
        </expression>
        <parameters>
            ...
        </parameters>
    </epilogue>
    <macros macros_attributes>
        <macro macro_attributes>
            ...
        </macro>
        <macro macro_attributes>
            ...
        </macro>
        ... 
    <macros>
</subSection>

More details can be found in the Subsection page, Prologue page, and Epilogue page.

The Macro Element

Macros are the building block of the individuals. A macro is composed of a fixed part (the expression) and a variable part (the parameters).

<macro macro_attributes>
    <expression>
        ...
    </expression>
    <parameters>
        <item item_attributes />
        <item item_attributes />
        ...
    </parameters>
</macro>

More details can be found in the Macros page (the macro container) and the Macros page. Remember that also Prologue and Epilogue are macro.

Formats

In each level of the hierarchy (section/subsection/macro) it is possible to change four formats. The expression is

<fooFormat>prefix<value/>postfix</fooFormat>

Value is the internal identifier for the object.

commentFormat: Format used to add comments. Note that µGP may add notes in the form of comments inside the generated code.

identifierFormat: How the internal identifier can be translated into a valid identifier. Remember that internal identifiers uses all letters and numbers allowed in the BASE32 encoding (ABCDEFGHIJKLMNOPQRSTUVWXYZ234567). Symbols can appear in every position, without syntactic restrictions. Many applications, like the generation of assembly language, require that identifiers start with a letter. For instance,

<identifierFormat>J_<value/></identifierFormat>

may generate assembly code like

jmp J_2NS345

labelFormat: How the identifier of a macro is dumped if that macro is the target of some reference. The identifier has already been patched according to identifierFormat. For instance,

<identifierFormat>J_<value/></identifierFormat>
<labelFormat><value/>:</labelFormat>

may generate assembly code like

J_2NS345: sub ax, 2  

uniqueTagFormat:

Format used for the unique tag parameter (see macro).