Termination Condition and Fitness

[Martin Waßmann]

Hello,

I'm currently developing an application to evolve structures and came
across two questions/problems. Using the TerminationCondition I'm
unable to access the populations individuals, as the type parameter in
following definition is a whitespace, and therefor (without casting)
the best candidate is treated as an instance of Object.

public boolean shouldTerminate(PopulationData<?> populationData);

I wonder why TerminationCondition is no generic?

The background is, that my evolutionary algorithm should stop when all
nodes of the graph representing the best individual are connected, the
(natural) fitness however consists of several factors like area
coverage, node count or distance between sub graphs, so that there is
no one fitness value directly associated with all nodes being
connected. I guess it would be possible to change the fitness function
to make it work, but still the question remains.

The second question is, why the fitness has to be a double value?

Is there any reason preventing the framework from using
implementations of the Comparable Interface as fitness? The background
is the same, the goal is to get a connected graph, however if there
are two individuals (graphs) equally as good, prefer the one with
lesser nodes. Adding a new factor to the fitness function representing
the node count, could, under certain circumstances, interfere with the
actual important properties, making a "lesser" connected graph better
than a "more" connected graph, because of having less nodes. The node
count is regarded as a purely secondary comparison criteria, only
regarded if the "important" properties are the same.

Thanks in advance,
Martin Waßmann

[Daniel Dyer]

On May 20, 5:19 pm, Martin Waßmann <chardev....@googlemail.com> wrote:
> Hello,
>
> I'm currently developing an application to evolve structures and came
> across two questions/problems. Using the TerminationCondition I'm
> unable to access the populations individuals, as the type parameter in
> following definition is a whitespace, and therefor (without casting)
> the best candidate is treated as an instance of Object.
>
> public boolean shouldTerminate(PopulationData<?> populationData);
>
> I wonder why TerminationCondition is no generic?

This is probably just because I haven't needed it to be generic so
far. I've just taken a look at changing it. I was able to modify it
fairly easily and it compiles and the tests pass but there are lots of
warnings about generic array creation with varargs methods. To fix
these I would have to change the interfaces so that the methods take
lists of termination conditions instead of using varargs.

I think for now it is simplest just to cast the argument to the
appropriate type.

> The background is, that my evolutionary algorithm should stop when all
> nodes of the graph representing the best individual are connected, the
> (natural) fitness however consists of several factors like area
> coverage, node count or distance between sub graphs, so that there is
> no one fitness value directly associated with all nodes being
> connected. I guess it would be possible to change the fitness function
> to make it work, but still the question remains.
>
> The second question is, why the fitness has to be a double value?
>
> Is there any reason preventing the framework from using
> implementations of the Comparable Interface as fitness? The background
> is the same, the goal is to get a connected graph, however if there
> are two individuals (graphs) equally as good, prefer the one with
> lesser nodes. Adding a new factor to the fitness function representing
> the node count, could, under certain circumstances, interfere with the
> actual important properties, making a "lesser" connected graph better
> than a "more" connected graph, because of having less nodes. The node
> count is regarded as a purely secondary comparison criteria, only
> regarded if the "important" properties are the same.

This is something I considered doing. I changed my mind a few times
before settling on doubles. Eventually I decided it would make the
code simpler if you didn't have to specify the fitness type everywhere
along with all the other types you have to specify. Though, as you
suggest, there is a case for making this configurable too. Perhaps it
is something to add in a future version.

Dan.

[Martin Waßmann]

Thanks for clarifying.

-
Martin