Subject: | |
From: | |
Reply To: | |
Date: | Sat, 12 Apr 2014 14:16:02 -0400 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
>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
|
|
|