Thanks for the response Sean.

Whilst looking through the java class files, I noticed that the method
ec.gp.breed.MutateOneNodePipeline seems to swap a node with a compatible
node already present within the tree. Is this correct?

So if we have the function set { + - * % } and the tree ( + x y ), the class
will only generate ( + x y ) i.e. without considering argument
point-mutation? It would not generate ( * x y ) for example?

I was hoping to point-mutate a tree and replace a node with a compatible
node within the possible function set (not specifically the tree itself). I
guess I would have to rewrite this class to perform the desired?

I think I need to get a hold of Kumar Chellapilla, "A Preliminary
Investigation into Evolving Modular Programs without Subtree Crossover",
GP98. Is this available as a pdf somewhere on the net? The Third Annual
Conference on Genetic Programming, Jul 22-25 is not available in my local
university libraries.

Cheers, Peter

-----Original Message-----
From: ECJ Evolutionary Computation Toolkit
[mailto:[log in to unmask]] On Behalf Of Sean Luke
Sent: Saturday, 28 July 2007 5:15 AM
To: [log in to unmask]
Subject: Re: mutation (traditional and point-mutation)

On Jul 27, 2007, at 2:28 PM, Peter Walker wrote:

> 1)       (Traditional mutation): select a random node and remove it  
> (along with all its children) and replace it by a randomly  
> generated subtree and subtree root.

This is ec.gp.koza.Mutation

> The other two schemes I would like to implement are based on "point- 
> mutation". Both point-mutation schemes would start out by selecting  
> a node and generate a random node (e.g. symbol1) to replace it.  
> Symbol1 would be checked to see whether it is of the same arity as  
> the node. If it is, then the node would be replaced by symbol1. If  
> they are not of the same arity, then we would either:
>
> 2)      Pick another symbol until we find one of the same arity; OR
>
> 3)      Remove the node and replace it with a new subtree using  
> symbol1 as the root.

You'll need to make a custom mutator for this that FIRST picks a  
replacement and THEN decides on what to do (#2 or #3).  However:

- ec.gp.breed.MutateOneNodePipeline will pick another node guaranteed  
to be of the same arity (and type equivalence) and replace the node  
with the new node.  This is roughly equivalent to #2, as you've noted.

- #1 and #3 are roughly equivalent, it'd seem.

So I think you'll be writing a custom mutator -- take a look at the  
code of these classes to get an idea about how to go about doing this  
(it's nontrivial but doable!)

Sean