Thanks for the fast reply! You are probably right, I enter debug mode and halt right before the heap memory error, and try to the tree that is being cloned. It gives a memory error too, probably because the tree is way too big. Some of the previous trees that are printable give me a huge string of trees.

However, in my parameter file, I clearly set:
parent.0 = ../koza/koza.params
gp.koza.xover.maxdepth = 4
gp.koza.mutate.maxdepth = 4
and I am using the default koza half builder, with: =
gp.koza.half.min-depth = 2
gp.koza.half.max-depth = 6
gp.koza.half.growp = 0.5

According to my understanding, the parameters I have set should overwrite the default ones. Is there anywhere else I should be aware of to control the size of my trees? Thanks!

Ye Xiaomeng

On Tue, Feb 11, 2014 at 3:18 PM, Sean Luke <[log in to unmask]> wrote:
Xiaomeng, it sounds like you're making truly massive trees, like 100MB apiece.  That's so large there's likely a bug in your code.

There's no real gotcha with cloning: it makes a deep copy of the tree.


On Feb 11, 2014, at 2:00 PM, Xiaomeng Ye <[log in to unmask]> wrote:

> Hello everyone,
> I am trying to integrate lambda-calculus into the GP package of ECJ. Everything works just like any GPIndividual, GPTree, GPNode, except that the LambdaTree can go through a process of reduction, which produces a minimal form of the LambdaTree.
> Because I used cloning and the tree could be potentially huge, I keep getting this error:
> java.lang.OutOfMemoryError: Java heap space
> Even after extended the JVM heapsize to 1 GB, I can only avoid it by setting extremely small population size like 20 (which produces nothing interesting as the population is too small). Other than that, the program runs out of memory at some point.
> Has anyone play with the cloning? Is there any pitfall? How is Java Garbage collection treating those nodes? (If they are treated just like any other java object, I think I might exploit cloning wrongly)
> Thanks a lot!
> Ye Xiaomeng