James, I think it'd be great if we got a maxsize parameter added.  But we need to make sure that it's included in all GP operators which can increase the tree size.  I think that's:

- CrossoverPipeline
- MutationPipeline
- InternalCrossoverPipeline
- MutateDemotePipeline

It'll take me a while to get that copied to all of them, if you can't beat me to it.

BTW, your setup() method uses getInt( rather than getIntWithMax( but you're talking about maximums.  That doesn't look right.

We'd either need to enable ECJ to run without the max-size parameter in a parameter file or include it in the koza.params file.


On May 3, 2012, at 9:23 AM, James McDermott wrote:

> On Wed, May 2, 2012 at 7:02 PM, Sean Luke <[log in to unmask]> wrote:
>> It doesn't.  But you can pretty easily add it in, just override Crossover's verifyPoints(...) method to check to see if the resulting sizes would be valid.  Same thing for Mutation.  There are some GPNode utility methods to help you in counting nodes.
> Thanks!
> Any interest in the patch? It adds a maxsize parameter to both
> Crossover and Mutation. It seems to be doing the right thing. I think
> oversize trees can still make it into the population either through
> Initialisation or cases when the loop runs out of tries. I'm not sure
> I understand the code that handles those cases (after "// So now we
> will transfer to a tree which has res1 or res2 valid, otherwise it'll
> just get replicated") -- should I be editing that too?
> For reference, I'm looking at the Punch et al paper describing the
> Royal Tree problem, where both a max depth and a max size are used.
> James