>> 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,
>> 9, 10, 15, 16, 17, 18, 19, 20, 23, 24, 25, 26 satisfies the constraints. And
>> 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
>> 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
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.
>> 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]).
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.