How is Node type-safety ensured during Xover?

[Matthias F. Brandstetter]

Hi all,

I was looking through the sources of epochX and wondering how the
"strongly-typed" feature of the a GP is ensured during crossover.
Within the UniformPointCrossover class the swap points in both parent
programs are determined via the RNG, then both subtrees are exchanged,
but I see no check for the type of the nodes to swap here (either
Void, Boolean, or Double).

Then I have looked into the CrossoverManager class, where both parents
for crossover are selected. I can see there that all produced children
are checked via the allValid() method, which in turn calls the
isValid() method of both candidate programs. But, within this method
of the GPCandidateProgram class, only the max depth is checked, not
any of the nodes and their types.

So, do I have missed anything here? Shouldn't the types of the nodes
to be swapped be checked, so that for example a child node of the
IfFunction will not be swapped to a Float-typed node during crossover?

Thanks for your clarification :)

Cheers, Matthias

[Tom Castle]

Matthias,

Very sorry about the delay in replying. You're not missing anything,
the UniformPointCrossover does not actually ensure the strong typing
at all. The support in 1.3 for strong typing generally is very weak
(excuse the pun!).

I'm currently working on v2.0 of EpochX which will be quite a
substantial upgrade. One of the new features is a complete redesign of
the typing system. In response to your message I've decided to push
this feature out early as version 1.4.

Of course, this does mean the documentation of these new features will
be a bit lacking until the material for v.2.0 is pushed out. But, I
think the improvement is worth it. You will also find that some
packages and classes have been moved around, this is a reflection of
some of the changes to come. In particular you will find
UniformPointCrossover renamed SubtreeCrossover.

Just to give a quick overview of the new typing features:

- Each function defines a getReturnType method which specifies what
its return type is for a given set of input types, or it must return
null if it does not support those input types. This allows for
polymorphic typing - where one function can handle multiple datatypes.
- Terminal nodes also have a getReturnType method, but of course does
not have any inputs so its result is based on its own type.
- All built-in initialisation/crossover/mutation operators use the
getReturnType methods to determine which types can plug in where.

This form of polymorphic typing is extremely powerful, and should be
sufficient for most typing constraints. Feel free to leave a message
here if you need any further help with these features.

Tom

On Apr 2, 12:32 pm, "Matthias F. Brandstetter" <hai...@gmail.com>
wrote:

[Matthias]

Hi Tom,

thanks for your reply -- and the new version 1.4 :)
I will check it out during the next days...

Cheers!

[Tom Castle]

No problem! Be sure to let me know if you have any issues, because I
rather rushed this release out!