1. Christoph F. Eick: Thoughts on Designing Michigan-style Classifier Systems Thoughts on Selection Methods in Michigan-style Classifier Systems  When solving optimization problems it is desirable to replace good solutions whereas in LCS replacing a very good classifier is quite dangerous, because the system’s real-time performance might drop significantly after a “few good” rules have been replaced.  Usually, the amount of change in LCS is significantly less compared to to EC systems that solve optimization problems, especially after the system has evolved over a certain amount of time, and the environment is somewhat stable.  Niche methods are much more attractive for LCS style system, because designing a classifier systems can be viewed as “finding a good set of collaborating rules; rules can be viewed as experts on what to do if a particular situation occurs”. You are looking for a team not super-fit individuals.  Coverage is another important aspect of classifier systems that does not exist in tradition EC systems: a rule set has to be evolved that covers many different situations. Having a few good rules with narrow expertise might result in a system that guesses for most inputs.

2. Christoph F. Eick: Thoughts on Designing Michigan-style Classifier Systems Other Problems in Designing Classifier Systems 1. What strength/fitness value should be given to new rules? Giving them average values or slightly below average values seems to be a good strategy. Another problem with new rules is that they might get deleted prior to being used often enough to evaluate their usefulness. 2. What about duplicate rules? No clear answer to this question. For example in systems in which decisions are made using voting redundancy is desirable. Moreover, redundancy makes it less likely that “good genetic material” is lost. On the other hand, copy of the same rule can produce a significant overhead and might reduce “situation coverage”. 3. How often should we learn, and how much change should we apply to the current rule-set if we learn? I am afraid that this is a question that can only answered empirically. 4. What should I do if there is no rule that covers a given input? Obviously, you do not know what action to take. Moreover, generating a new rule that covers this situation might not be a bad idea in an XCS-style system.

3. Christoph F. Eick: Thoughts on Designing Michigan-style Classifier Systems Other Problems in Designing Classifier Systems (cont.) 5. How should a generate my initial rule-set? What mutation operator should I use? Generate the don’t cares dependent on the rule-set size, the number of possible inputs, and how much coverage for a given input you might like to have. 6. How should actions be selected, if rules with different actions match the input? Many approaches are possible here including: random selection (might not be a bad strategy at the beginning of the evolution process), strength based (classifiers with higher past payoffs are preferred), accuracy based (classifiers whose performance is predictable are preferred), simple voting (each classifier has one vote), strength-weighted, accuracy-weighted,… voting,… 7. How should I evolve strength, fitness, and other values based on system feedback? In my opinion, the strategies employed in XCS seem to be a good choice. Initially, set your learning rate between 0.1 and 0.3 and adjust it based on experimental results. In general, if the experiment is short or the environment is changing a lot higher learning rates are useful.

4. Christoph F. Eick: Thoughts on Designing Michigan-style Classifier Systems Other Problems in Designing Classifier Systems (cont.)  The learning period seems to be short for my system to learn something; what should I do? Either adjust your system parameters, or if you demonstrate that the performance of your system improves over longer learning (e.g. you ran it for 4x1200 examples) periods this is also good enough for the course project.  How complex should the system be a should I design? Don’t make your system to complicated unless you are a very fast programmer, because this will give you enough time for fine tuning based on experimental results. Moreover, if you understand what your system is doing, it might be easier to enhance it.  Do I have to write a large report? No just a short description of the strategies your system employs is sufficient.