[Cs254f11] My plan

Lee Spector lspector at hampshire.edu
Mon Oct 17 12:47:01 EDT 2011


What Tom said :-)

On his first point, try to structure things so that the population size and number of survivors are parameters, so that you can play with them easily if you find that you want to.

On the second, I know that you don't want to pre-digest the data too much, but it still might be a good idea to provide some reasonably-high-level functions for evolution to work with, e.g. to pull out all of the note numbers within a chunk of the file, or do averaging of notes or intervals, or something like that. Hard to say what will be useful, and it depends on what else will be in your function set and what data types your functions will work with, but often it will help to provide evolution with a reasonable toolkit.

On the third: definitely excellent advice.

A new point: I don't see why you'd want to do *anything* random in your fitness test. Don't you just want to evaluate the fitness of a program by running it on each MIDI file, getting a score for each, and adding up the errors of those scores relative to your hand-coded scores? 

 -Lee

On Oct 17, 2011, at 12:12 PM, Thomas Helmuth wrote:

> A few thoughts, which might be useful to everyone:
> 
> - Why limit yourself to 2 survivors and 20 individuals (soup-mixes) each generation? This small of a population and of surviving individuals can sometimes work, but is generally unpreferred in the evolutionary computation community. One reason is that having very few surviving individuals is not very robust - you may lose promising individuals to ones that are only slightly better in a totally different way. Similarly, this will cause your algorithm to only concentrate in a small area of the search space, instead of using the power of a larger number of surviving individuals to search the space more in parallel, which also helps prevent it from getting stuck in local optima. I would suggest using at least 100 to 200 individuals and 10 to 50 surviving individuals that are allowed to reproduce. (One reason you may choose to go with a smaller population is if your fitness evaluations are going to be very computationally expensive. But, it doesn't seem like that will be the case here).
> 
> - I think you need to think a bit about how your individuals will input your midi files. Are you going to give evolution instructions to read the whole file, read a specific line of the file, or read a specific value from the CSV? If it is a specific value, will it be indexed by line and column, or just by a single integer? To me, it seems like any of these methods might not be strong enough to give evolution the things it needs, so you might need to give it more specialized input methods, such as the interval between a pair of notes, etc. Though, I might be wrong here.
> 
> - You're a bit vague about your program language and structure. Will these be lisp expressions? What instructions will be included? It is always good when developing a genetic algorithm to write a sample program by hand that won't solve your problem, but which you think might have a chance at doing better than random junk. If you find you can't do so with the instructions you give evolution, chances are that it won't do any better.
> 
> I hope this helps!
> 
> -Tom
> 
> On Mon, Oct 17, 2011 at 11:13 AM, Wm. Josiah Erikson <wjerikson at hampshire.edu> wrote:
> So I'm now messing about with reading in files and putting them into data structures that I can do useful things with, but before I get too deep into committing myself to particular methods, I want some people who know more than me to read over my plan and tell me if they see any big problems with this other than the questions I have already identified below that I will have to figure out. Comments from my code:
> 
> ;I'm going to attempt to evolve a program that has the same opinions of various MIDI files that I do.
> ;I'm going to listen to 20-50 publicly available MIDI files and score them, then hardcode those scores
> ;into this program. Then I'm going to covert said MIDI files into .csv, and attempt to evolve some scoring
> ;method that comes up with the same scores for these files that I do. I'm going to do this without teaching
> ;my program very much about how the MIDI file is formatted, so my evolutionary "soup" will be fairly dumb.
> ;The idea behind this is that one of the things that GP does well is to find patterns in things that we don't
> ;understand very well, and in that light, I ought to be able to evolve a music critic without teaching it the
> ;format of MIDI files - it will try sampling the MIDI file in lots of random ways, applying random scores (think
> ;this through - maybe actually I have to always apply the same scores? I can't have randomness twice, unless
> ;both randomnesses are factored into making that "genome" unique, otherwise I'll get faulty evolution), then
> ;applying the same set of "soup components" to all of the MIDI files, comparing the scores to my scores, adding
> ;up the difference, and then that will be the fitness value of that particular "soup mix" or genetic code.
> ;Each generation will have, say, 20 different "soup mixes". I will pick the two that have the best fitness values,
> ;breed them together and randomly mutate them (how, exactly?) to get 20 new ones, them start over. I will stop
> ;after either an arbitrary number of generations or when the fitness value goes below x, and then see what I get!
> 
> Thanks in advance for any feedback!
> 
> -- 
> Wm. Josiah Erikson
> Network Engineer
> Hampshire College
> Amherst, MA 01002
> (413) 559-6091
> 
> _______________________________________________
> Cs254f11 mailing list
> Cs254f11 at lists.hampshire.edu
> https://lists.hampshire.edu/mailman/listinfo/cs254f11
> 
> _______________________________________________
> Cs254f11 mailing list
> Cs254f11 at lists.hampshire.edu
> https://lists.hampshire.edu/mailman/listinfo/cs254f11

--
Lee Spector, Professor of Computer Science
Cognitive Science, Hampshire College
893 West Street, Amherst, MA 01002-3359
lspector at hampshire.edu, http://hampshire.edu/lspector/
Phone: 413-559-5352, Fax: 413-559-5438



More information about the Cs254f11 mailing list