>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