>I've been doing testing and am limited by the memory issue with strong 
typing.
>I'm moving my code over to one of our university's blade servers to get more
>resources.
>
Having the extra resources of the university's server didn't help much in 
controlling the memory exploitation issue of strong data typing. I didn't have 
time to look into the root issue in ECJ with strong data typing, but I assume it 
uses a greedy algorithm in tree construction. Maybe I'll look into it later. This 
post is for the benefit of others who may need to work around the issue as I 
did.

Ignoring the core dumps, the main problem is the limitation on population size. 
In my case I found a population of 350 to be the maximum I could push out. 
Once the run got past the first 2-3 gens it had no further issues. Since I used 
ERCs to generate numbers randomly, the curtailed diversity from a 350 
population was a problem. I made a few changes to adjust for this lower initial 
diversity,

1. I put parsimony pressure into the fitness function and increased tree depth 
to increase diversity in the tree (breaking the rules  :)
2. the timetable had 75 slots and I evaluated only the first 75 items which 
could be slotted in, ignoring the rest (except to count the excess baggage to 
apply toward parsimony pressure) -- this reduced selection pressure and 
carried forward genetic material
3. with 10 fitness measures to track I multiplied them (adjusting to 1-base 
level) then took their power to normalise the number (ie n x m x o --> 
nmo^1/3) -- this reduced selection pressure for large individual excursions of 
fitness with the benefit that individual small changes created more relative 
effect -- therefore more genetic material was carried forward retaining diversity 
with selection pressure increasing as it neared a solution.

This is just a simplified explanation of course. I found tuning of these values to 
be critical and sometimes counter-intuitive. 

If anyone has specific questions, email me. 

>This is a school timetable app. There are primarily 3 parts to the timetable:
>rooms, timeslots and course offerings. Then there are constraints which 
include
>instructor availability, room purpose, and curriculum concurrency, among
>others.
>
>The terminal set is 3 ERCs, one each for the 3 parts of the timetable. Then 
one
>ERC join function restricted to one of each ERC type, and a generic join
>restricted to ERC join types. Generally, this is an optimisation problem where
>one needs to find the right sets of ERCs which satisfy the constraints. I have
>plans to extend the tree with a conditional function later if I have time.
>
>-- ray