>> All of these constraints are hard. Over a week the timeslots should be
>> maximally filled, but in any possible combination. For example; 1, 3, 4, 5, 6, 
8,
>> 9, 10, 15, 16, 17, 18, 19, 20, 23, 24, 25, 26 satisfies the constraints. And 
so
>> does, 2, 4, 5, 6, 8, 9, 10, 15, 16, 17, 18, 19, 20, 23, 24, 25, 26. I could go
>> with a set of permutations which define all possible valid weekly timeslot
>> combinations, or I could define 26 GP functions and let GP handle the
>> permutations.
>>
>> My problem is I should be able to read in this file to create the functions. So
>> far, from what I see in the example files, functions are created in code like
>> terminals. I haven't seen a means to create them from a param file.
>
>Nope.  You'll have to invent your own way of reading them in.  What I'd do is 
create a single special kind of ERC, a terminal, which at setup() time loads all 
the constraints in, and then at reset() time sets itself up as one of your 26 
possibilities.

Hmm... I think this is the most straight-forward way to go. I was kind of hoping 
for a solution which could be translated into a potential method for GA as well. 
If I created a permutation set from the conflicts in timeslots.txt and used just 
the indices of the timeslots then it should transport over to a GA genome. One 
aspect of our project is to compare the performance of GP vs GA vs PSO and 
I'd like to restrict my advantage over GA to doing what GA can't do. 

>
>> Alternately
>> I could apply the timeslot constraints in the selection process with suitable
>> terminals to generate the timeslot functions, but do I do this with ADF and
>> progressively remove these selection constraints?
>
>This I can't help you with.  You've got your work cut out for you.
>
>If you're exercising the GE code, we have a new version coming in in just a 
bit, which will include code to convert GP trees into GE individuals (don't ask).  
If you're interested, contact Khaled Talukder ([log in to unmask]).
>
>Sean

I'm looking into another option that I find easier to wrap my brain around than 
GE. The thing is it's going to require mods to Initializer, Breeder, Evaluator, and 
probably stats if not more. The option is to use permutation trees that in 
essence act as a virtual population for the known permutations of the data. 
One instance can create the full range of permutations if selected. The 
permutations are defined by indices, making crossover easier. In my case all 
indices should be integers. A permutation tree is atomic to its type (such as 
timeslot), which forms a natural crossover boundary. It's sort of a predefined 
leafpile which, as a subtree, can be plugged into other subtrees. Along with the 
permutation tree is a collection which holds the other relevant data recovered 
by an index value. This is used by reports and possibly stats to find out what 
the heck was being worked on. Currently the permutation tree is a binary tree 
since it's easier to work out the selection mechanism with it.

So any advice on this one? Do overloading as much as possible? What about 
the scope of the work? Any particular examples that seem to fit my case?

I figure I'm already going to miss my 1st deadline, so may as well make it count 
for something. As in blowing away my competition... hopefully :/

Well, I'm gonna dig into the code now to see how much work this is.

-- ray