>> 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