>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