Current MS Students/Steven Emory/CS590 Page

From CSWiki

Contents 1 Jan 5 (week 1) 2 Jan 12 (week 2) 3 Jan 19 (week 3) 3.1 Monday, Jan 14 3.2 Saturday, Jan 19 4 Jan 26 (week 4) 5 Feb 2 (week 5) 6 Feb 9 (week 6) 7 Feb 16 (week 7) 8 Feb 23 (week 8) 8.1 How Humans and Computers Transcribe Music 9 Mar 1 (week 9) 10 Mar 8 (week 10) 11 Mar 16 (finals week)

[edit] Jan 5 (week 1)

[edit] Jan 12 (week 2)

I'm currently preparing a presentation on MFC, the Microsoft Foundation Classes. After Dr. Guo presented his own MFC demo in 537 (which I believe threw all the students off ha ha ha because he started with MFC's DOCVIEW architecture (that's normally covered in the middle or end of an MFC book), I wanted to show you guys the easier way to develop a basic MFC application (not using any wizards like Dr. Guo did) and I'm going to show a more complicated (way beyond a Hello World) demo of an MFC program I wrote a while back ago and tell why one would want to choose MFC over say Java or C#. I'll also talk a little about the history of MFC and Microsoft business practices (but we already know about those right?), and who's using MFC and why MFC is important. For the second platform/framework presentation I'll probably talk about the XNA 2.0 Framework, which I wanted to do this week, but didn't have enough time to prepare enough materials for a good demo (I wouldn't want to bore you guys with a bad demo).

As for the thesis preparation, I'm going to get started on that soon, probably this weekend. There are a few projects that I'd like to try out, problems in artificial intelligence that I'd like to talk to Dr. Abbott about to see if he thinks they're good ideas (or downright impossible). But first I have to organize all my journal articles and conference papers on the subject :-). I've downloaded quite a few off the net and the ACM Digital Library so as I organize the journal articles and conference papers on the topic I'll post here some things about the problems.

Basically one of the ideas I have for a thesis project is to work on something called the Transcription/Arrangement Problem. It's a problem in artificial intelligence because the computer algorithm must be trained to be able to interpret and reinterpret musical forms. Current research is filled with "specialized problems" in transcribing and arranging music, since the generalized Transcription/Arrangement Problem has been remarked by one author as "probably won't be solved anytime soon," and of course, I would work on a specialized problem myself since I have particular expertise in classical guitar.

One recent (2006) research article I am currently eying on is here [1]. They basically use a genetic algorithm to obtain a solution to the Transcription/Arrangement Problem. It really is the Transcription Problem that they are focusing on however, since they are trying to stay as truthful as possible to the original music. Arrangement really involves style changes. Their examples are kind of simple. Can it transcribe the entire Swan Lake suite for a guitar quartet (and as good as they could transcribe themselves as they say in their paper)?

I would like to work on something similar, but try to extend it to do better transcribing and more "arrangement." I'd also incorporate more guitar techniques, since their implementation only relies on MIDI which cannot handle any guitar technique other than legato. Harmonics? MIDI can't do it. Percussion? MIDI can't do it. Rasgueado? No can do either. Tapping, picking, bending a string behind the neck, and other right handed techniques.... MIDI = nope nope nope. Other examples include: can an orchestral piece be transcribed for guitar with a Spanish "Flamenco" flavor? How about arranged with tremolo (repetitive notes played throughout a piece)?

There is also the "Automated Transcription Problem," where based on audio you transcribe a song for an instrument (instead of starting with sheet music or MIDI). Wikipedia says only a few attempts have been made at this, usually a part of someone's Masters or PhD thesis. But I'm not sure if this would fall into the realm of artificial intelligence (it's more of a signal processing application, i.e. Fourier and Wavelet Transforms etc.), so I'll have to research it more and look for some articles on it this weekend.

There's also some 3D computer graphics articles and research I'm interested in but I really don't know Dr. Kang or Dr. Akis all that well so I think I'll stay within an AI topic.

Also, perhaps sometimes next week as a 2nd option I might talk to Dr. Crespi to see what kind of Automata projects he might have as I do like automata, although I'm not all that interested in compiler design or anything, but I do know that automata are a lot more useful in things other than compilers. So next week since I won't have to give a presentation for 590 I'll talk to Dr. Crespi and read some journal articles.

[edit] Jan 19 (week 3)

[edit] Monday, Jan 14

I'm reading a book on genetic algorithms right now. GAs never really did excite me or anything (I always thought there were better non-derivative based optimization techniques), but once I saw that GAs had something to do with mating it quickly turned my attention he he he. Good fun stuff even though I don't like the book's sample code (Matlab code == yuck). It's a big book covering lots of GAs so it might take me a few days before I can start coding some stuff up. Maybe I'll even be able to use some of this stuff in my 560 class too.

[edit] Saturday, Jan 19

So I'm preparing a pretty long presentation for next Saturday. Hopefully I won't bore you guys this time like I did last week he he he. It'll basically go something like this (talking about music, journal articles, genetic algorithms, colorization algorithms and genre theory):

1. Introduce Transcription/Arrangement Problem
   Problem in CS about converting musical forms... why it's a problem in artificial intelligence and give some audio and video examples...
2. Discuss Special Cases
   Some problems are impossible to solve. For example, from orchestra to a single instrument a lot of musical data is going to be lost, and trying to convert back to an orchestral arrangement is impossible. This is like converting a color image to black and white and then trying to convert it back to a color image. A computer cannot do it without human computation (i.e. human help), and even then the results are not guaranteed to be pleasing.
3. Discuss How Current Problems Are Solved
   Basically discuss recent research. I have a couple nice articles to discuss.
4. Discuss Things That I Think I Can Add or Experiment With
   This is where I'll talk about genre theory and some other things related to arranging music. Content management systems that employ genre theory tag data with metadata at a granular level so that data is always presented to the correct genre. I was thinking of exploring the CS view of genre theory and seeing what can be done with it as they are very fuzzy with it in research articles.

The last few days though I haven't spent too much time thinking about a thesis since Dr. Kang finally gave us our first CS560 homework assignment and I've been reading about ANNs and Hebbians. ANN books are pretty fun to read (aside from looking at more MatLAB code), as reading about how houseflies and mice think is pretty funny. For example, a Hebbian learning example.... a mouse sees a cat, which triggers a run away neuron R. A mouse sees a cat bowl, which triggers a cat bowl neuron B. However, the B neuron doesn't trigger the R neutron. But if the mouse sees B and R at the same time long enough, there comes a time where B will fire R automatically ha ha ha. Hebbian learning sounds like a fancy word for conditioning to me. Too bad when Richard gave his Hebbian presentation I didn't understand it at the time (then I don't think even the professors understood it as even Dr. Sun didn't ask him any questions ha ha ha). Silly stories like that... kind of funny hey?

[edit] Jan 26 (week 4)

This week all I did for this class was pretty much just prepare for the presentation and reread a couple journal articles so as to make sure that anything I mentioned in the presentation was clear (hopefully) or any questions asked I could answer. Otherwise, nothing new as this last week was kind of busy with CS560 stuff and Grady and Spencer driving me crazy (I will kill Grady) with turning in a last minute qualifying entry for the Software Development competition of the Imagine Cup this Friday night. Next presentation I will finish presenting the GA part of that algorithm and read more into ANN-based musical phrase classification articles.

As for where I'd like to go with this, I'm still getting a feel for what's out there in research. But in that one paper, they describe what is strictly a Many (Instruments)-to-One (Instrument) type algorithm. In other words, an entire orchestra condensed to a single guitar. This is probably the main factor in why their algorithm takes an hour even for even a moderately short piece of music such as their example (their GA is "mutating, determining playability, returning not playable, and repeat). With so many instruments needing to be condensed, their algorithm has a high probability of returning "not playable" for most populations. So basically they have to search the entire population to find those "one or two" playable variations with high fitness.

So perhaps I could explore things to make it faster, i.e. explore shortcuts, different fitness functions (their fitness function has an exponential factor I think is unnecessary), and perhaps explore the "Many-to-Few" transcriptions (for example, Orchestra to a guitar quartet). In the Many-to-Few problem, the GA's playability test might be more likely to return playable (and less likely to do exhaustive searching) than the Many-to-One problem since we are dividing the problem into four pieces.

[edit] Feb 2 (week 5)

This week I finally got around to understanding GAs, and actually it's a pretty easy concept. Easy to code too! Just a matrix of binary encoded variable sequences that get updated according to rules loosely based on biology. I've also spent some time reading some other articles and conference papers such as this one to see some current research on how people are using them.

So going back to that one journal artice, I think I now understand how they implement their GA-based transcription algorithm, and as I understand it I noticed some good things and some strange things:

1.) Music Broken Into Phrases (Good)

A full musical piece can have thousands of notes, and hence thousands of GA variables. Better to break the musical piece up into sections. They reference a paper on how this can be done.

2.) Steady-State GA (Strange)

So using tournament selection, they select two parents, mate them using double point crossover (generating only one offspring), replace the bottom (worst) chromosome with the offspring, randomly mutate 3% of all bits, and repeat. One thing I don't get here is that double-point crossover suggests two offspring. How do they choose one over they other? Any why steady-state (only one chromosome is updated per generation)? Why not 10%? 20%? Is it too slow otherwise?

3.) Tournament Selection (Good)

I read that tournament selection with thresholding is the most popular GA selection rule since it doesn't require sorting according to rank. So seems good to me, although they really didn't say what their threshold was and why it was chosen etc.

4.) Melody is Always Included (Strange)

This seemed OK to me at first, but what about if the melody is unplayable? I think it should definitely be included into the search space of the GA. If a melody note is removed, it could just result in a very high penalty. They probably did this to simplify their search and save time. However, I believe the final result should always be playable, regardless if the music is perfect (the melody is intact) or not.

5.) Their GA is Slow (Strange)

For musical phrases, which typically range from only a few notes to less than a hundred, why does it take one hour per phrase? He he he answer: well, they used Java (some Java code is presented in the author's Masters thesis appendix).

6.) Conclusions:

I'm beginning to think this is too easy for a Masters thesis or project. A lot of work, but maybe too easy as it seems like a simple application of GAs to music. I want my thesis or project to be hard; I want to suffer :D! Besides, this is their work and they are probably currently working on improving it anyways. I think I'll look elsewhere for something with GAs and ANNs and stuff.

Next Week Presentation

So for next weeks presentation, if I haven't decided on something else by then I'll talk about some other interesting topic other than music (more AI goodness or some graphics stuff) :).

[edit] Feb 9 (week 6)

This week I spent my time coding a little C++ GA demo for a class presentation. It is a demo on the transcription problem. It is certainly not a full implementation of the journal article's GA since it only does one bar of piano music, 20 notes, and almost all chromosome combinations are playable on the target instrument so there is no need to worry about a second GA to solve the fingering problem. I'll post the slides later today.

The demo:

1.) Describes the problem

we want to convert one musical form into another, from

Piano
First measure of Chopin's Etude in E Major Op. 10, No. 3

to

Guitar

Since piano has a wider range and supports up to 10 notes at a time, converting a piece of piano music to another form oftentimes introduces playability problems. Humans solve this problem all the time (just go to the music store and you'll find thousands of piano transcriptions). Question is: Can a computer do it and can I make a thesis or project out of it such that I feel I can get better results than previous authors? I was thinking of trying another method other than a GA or a different type of GA since the standard crossover isn't likely to get you to a better solution for this problem (as you are oftentimes crossing over traits of two completely unrelated pieces of music).

2.) Uses a simple, steady-state GA with a population of 4, and I demo how to setup musical variables into a binary chromosome (setting up chromosomes, genes, and the initial population)

0 = note is not played in transcribed piece (colored red)

1 = note is played in transcribed piece (colored black)

Since variables are already in binary format, there is no need to encode them. Each note represents a single variable, or gene. The genes are linked and represented as an array or vector called a chromosome.

10111101011110001001 (chromosome #1)

00001101011001001111 (chromosome #2)

01001100110001100000 (chromosome #3)

11101110101100000100 (chromosome #4)

3.) Shows how to evaluate the fitness function (the first generation)

compute

f(00001101011001001111), f(10111101011110001001), f(01001100110001100000), and f(11101110101100000100)

and sort them.

4.) Selects the best two (selection)

Chromosomes #2 "10111101011110001001" and #4 "11101110101100000100" are the best in this initial case since most of the melody is intact.

5.) Mates the selected ones (using crossovers)

An example of a simple single point crossover.

Oh, I haven't heard of that one yet, I read about single point, double point, uniform, weighted and analytic. I'll give universal a try.

6.) Randomly changes the bits for 20% of the population except for the best chromosome (mutation) to keep the GA from converging to fast (before being able to sample the entire cost surface)

Mutated Offspring #1 (Visual Representation)

Mutated Offspring #2 (Visual Representation)

You're right, the journal article uses only 3%, but when I wrote my little C++ demo it was meant for presentation (not a serious demo) so I used the simplest GA I could write and modified a lot just for show. I'll write a more serious demo too with tournament selection and universal crossover.

7.) Evaluates the fitness of the offspring and mutated chromosomes, replacing the bottom two chromosomes with the offspring from the parents

The fitness of the offspring are computed and they replace the two worst chromosomes in the initial population. The chromosomes are then sorted by fitness, and now "111111110100110101101" (what was Mutated Offspring #2) is now the most fit chromosome in the next generation.

8.) Repeat

The presentation only goes through one iteration of this process, then I discuss some other fun things about GAs.

Oh, hi Dr. Abbott, ha ha ha looks like we were both editing this page at the same time. I just noticed your comments. I am posting up my stuff right now. But Ok cool, I'll edit my code a bit and have some fun with the different methods.

As far as I've looked, there's only been one previous attempt (2005, the one paper I referenced). They even say in their paper, "We know of no other research pertaining to automatic arranging for the guitar or any instrument, and we believe this system to be the first of its kind." Their results are link here. Very easy to play songs, and their demos only last a few seconds. The music they have posted on their website is in fact simple enough that I can even transcribe it by hand faster than if I ran their algorithm. I have a feeling they didn't bother trying more complex pieces because their GA used to solve the "Playability Problem," which is required to compute the fitness, is a time consuming process. So I guess my answer to how well previous efforts to use GAs to solve the problem is that it's good enough to solve simple, short pieces of music, but not complex, long ones.

I was also thinking applying this to the piano as well as the guitar since most transcription pieces you buy at the music store are for the piano, not the guitar. The piano also suffers from the "Playability Problem" as well when transcribing music.

Yes, the way the genes are ordered in a chromosome is likely to make a big difference. The article doesn't discuss how they order their genes, just that "1" means "in the piece" and "0" means "not in the piece." In my demo I ordered them such that the melody genes came first, then harmony ones next, and then less important notes (from counter melody, bass) last.

The GA does not need to know anything about clefs. The first step in the process is to convert the original music to a single clef system, preferably using the clef most commonly used by the target instrument, so that GA only needs to be aware of one clef.

Yes, the GA needs to keep track of what notes are played simultaneously, since I would most likely also implement an extra penalty for missing notes in a chord.

It would be easy to take the output of a GA and run it and play it. The MIDI file format is really simple (just a list of chunks, 4-character IDs + size of chunk + binary chunk data), so no problem reading or writing online music files. Java also has the Sound API which is really easy to use as well.

[edit] Feb 16 (week 7)

Well, I'm up at the ungodly hour of 6:00 AM getting ready to go to school to help out with Progfest. One of the problems for Progfest was mines and Carlos' idea, I wonder if anyone is going to be able to solve it (it took me several hours to solve it ha ha ha aww poor High School students).

So I gotta leave right now, but I'll be posting up some stuff here on the wiki throughout the day (since being a judge means waiting around eating Subway until the kids finish he he he).

This week I looked at all the requirements to work on the transcription problem and realized that this problem will probably take a minimum of 3-4 quarters to finish, but that's OK since I know at least one student here who wants me to stay still until 2010 ha ha ha! But no, I think by next Spring would be nice.

I would need at least one quarter to write a codebase (MIDI support, musical phrase sepatation, and I'm also thinking of making this into a Sibelius plugin) and implement templates for the GA way and my own way (I'll even try exhaustive search). Another quarter to implement the playability problem and another quarter to implement musical foreground and background extraction (harmony, melody, counterpoint, bass, etc.), and at least one quarter to put all my buggy code together and write up a thesis. Should be fun too, my thesis presentation should be full of noise ha ha ha!

Time to start on that prospectus now!

[edit] Feb 23 (week 8)

Getting ready to prepare another presentation (I guess not this week since it's full). The topics I will cover are described below.

[edit] How Humans and Computers Transcribe Music

Step #1: Choosing a Piece of Music to Transcribe

Humans

In general a person picks a piece of music for transcription that:

1. is interesting.
2. is well-known and liked.
3. is not pedagogical (a teaching piece).
4. will be challenging to play on the target instrument(s).
5. adds something interesting to the original piece.

Computers

Since a computer can't pick an interesting piece of music, this always has to be done by a human.

Step #2: Determine Target Instruments

Humans

In complex orchestral scores, there can be many instruments playing different lines at the same time. Depending on the complexity of the original score, a transcriber may have to transcribe for multiple instruments instead of a solo instrument.

When choosing instruments, one would like to choose instruments of a different 'timbre' or color from the original. For example, if an original orchestral score uses flutes to play the main melody, you don't want to have flutes in the transcribed piece. Choosing an appropriate instrument also depends on range, since a Cello (which is a bass instrument) cannot play anything originally written for flute.

If transcribing for different instruments, a transcriber would want to choose instruments that not only can play the original piece, but choose instruments that also sound good together. For example, a transcriber would never transcribe for a Harp, Piccolo, Trumpet, and Glockenspiel quartet even if that was the only combination that could play the original piece.

A transcriber would also like to use as few instruments as possible. This is called Contraction Scoring' - the reduction of a larger score to a smaller score. This is because the transcriber wants the transcription to be challenging to play and to minimize the amount of 'idle time' the instrumentalists go through. For example, in a typical orchestral piece, more than 1/2 of the instrumentalists at any one time are playing nothing. If transcribing for a piano duet, the transcriber would like both pianists to be consistently playing something.

Computers

A computer can pick suitable instruments based on range, but definitely cannot pick the most pleasing instrument combinations (which is usually left for the human to decide).

One thing the journal article didn't cover was that if a piece was determined to be unplayable, what happens next? I think one thing I can also add is finding the minimal number of instruments required to play at least 90% of the original piece and determine which instruments need to play what in order to keep both instrumentalists busy most of the time.

Step #3: Transcribe the Piece

Humans

Once a transcriber has picked a piece to transcribe and instruments to transcribe to, he can start transcribing the piece. If the piece is easy enough, and all notes fit within the range of the target instruments he can literally 'copy and paste' components from the original score into the target score.

For more complex scores, what the transcriber does depends on the situation. Somehow he must simplify and condense the original score to reduce the complexity. For example, if an orchestral score requires 12 notes to be played at once, it cannot be transcribed exactly for piano, as a piano only supports as many simultaneous notes as a human has fingers (10). Therefore the transcriber must either delete notes or arrange the score (see Step #4 below).

Another situation arises when all notes fit within the natural ranges of the instruments, but they are not physically playable. This is called "The Fingering Problem." For example, on the piano you cannot play notes in the high, middle, and low ranges at the same time. You would need 3 hands to do so since a full grand piano is an extremely long and wide instrument. In this case a transcriber would probably remove the notes in the middle range.

Other simplification methods include 1.) listening to the original music and determining which instruments in the original score do no contribute much and deleting them from the score and 2.) rearranging the music (replacing old complex melodies and harmonies with new simpler ones).

Computers

Computer can easily transcribe simple scores, but for large complex ones, they are currently limited to transposing (moving) notes or deleting them. Rearranging music is extremely difficult for a computer to do.

A computer can solve The Fingering Problem very effectively and there are many research articles on it (they currently use GAs too).

Step #4: Arrange the Piece

Humans

Sometimes, when transcribing music, the transcriber runs into a brick wall where he cannot transcribe the piece accurately in it's original form due to range or playability issues. Sometimes problems with playability can be solved by 'transposing' the original piece into a new key (B flat minor to E minor) or tuning the instrument (such as the guitar) to a different key.

In other cases, the transcriber has to explicitly remove whole notes and passages. What notes or passages do you delete? In general one would like any melodies to be left intact, while deleting any harmonies or bass lines that do not contribute heavily to the original score. This can be easily done by a human because a human can listen to an original piece and distinguish melodies and harmonies almost immediately.

And in other cases, a transcriber may be unsatisfied with a transcribed passage that he may arrange the passage completely (although this must be done in good taste).

Computers

The original journal article on transcription for guitar did not cover what happens if a transcribed piece returns as unplayable. They did not discuss transposing the piece or tuning the instrument to try to make it playable. This would be interesting to try. Doing so adds a lot of different states to the problem however.

Removing notes and passages was fairly well discussed in the journal article. However, I can think of some cases where their algorithm probably wouldn't generate pleasing results (for example, random notes being deleted from repetitive harmony and base lines might sound awful).

Arranging passages is extraordinarily difficult for a computer to do since a computer really can't be creative. You are essentially being asked to overwrite existing music with your own, trying to maintain the original style, flavor, and flow of the original piece. This is another one of those 'Holy Grails' in computer music research where if you can create pleasing original music in a specific genre using a computer you would be famous!

[edit] Mar 1 (week 9)

Hey there Dr. Abbott, do you know anything about Human-Based Genetic Algorithms? Seems the papers on them refer to them being used on knowledge management systems with lots of human users. Can it be used using a single human to solve a single problem rather than a bunch of humans used to solve many problems?

This week and this weekend I've been reading up on human-based and interactive GAs to see how they are used in music and to see if they can be used to not only compose music, but arrange it as well. There are many papers on composing with interactive GAs, but none so far that I can find on arranging music. There is this article in particular that is interesting and others on music compositional intelligence (determining if a song is happy or sad and arranging music based on that).

PowerPoint slides for presentation this week: Steve3.ppt

[edit] Mar 8 (week 10)

With one week left, I think it's time to finish the plan and get working on finishing that prospectus. This past week I was laying out plans for everything I intend to work (and not work) on so I can clearly define the prospectus. So the following outline are all the things that will eventually make its way into the prospectus:

The Guitar Transcription Problem (Note: Before I was planning to also work on the piano transcription problem, but I think it's best to narrow it down and just focus on a single instrument, choosing the harder and more interesting problem to solve).

1. (Old) Issues to be Investigated
   * Thematic Extraction (Harmony, Melody, Counter Melody, Bass)
   * Genetic Algorithms
   * General Transcription Problem: You can delete notes, move notes, but not add new notes.
   
2. (New) Issues to be Investigated
   * Graph and Path Finding Search Algorithms: The playability problem is a form of combinatorial search. While genetic algorithms can be used, are they the best for solving this type of problem?
   * Minimal Instruments: If an original score is too complex, what's the minimal number of instruments needed to play it?
   * Musical Transposition: Most popular classical guitar pieces transcribed from other instruments are oftentimes transposed to different keys before transcription. This is typically done to fit original scores written in sharp and flat keys that are unnatural and uncommon to the guitar (like Bb) to more common ones (like Amaj, Emaj, Cmaj, GMaj, DMaj, Amin, and Emin). The idea behind this is that it would increase our chances of finding a good and playable solution.
   * Alternate Tunings: The normal guitar tuning is E-A-D-G-B-E, which is why scores written in flat and sharp keys are very uncommon to the guitar. For many classical pieces written in D, it is very common to change the normal guitar tuning to D-A-D-G-B-E or D-A-D-G-B-D instead. The question here is, what alternate tuning is optimal (generates the highest playable fitness)?
3. Literature Review
   *Musical Analysis:
   [2001] Feature Selection for Automatic Classification of Sounds
   *Genetic algorithms:
   [2006] Genetic Algorithm for Combinatorial Search Problems
   *Transcription:
   [2004] Arranging Music for Guitar with GAs and ANNs
   [2006] GA-based Music Arranging for Guitar
   *Playability:
   [2004] Path Difference Learning for Guitar Fingering Problem
   [2004] A Segmentation-Based Prototype to Compute Fingering
   [2005] Automatic Fingering System
   
4. Anticipated Challenges
   *Genetic Algorithms: Finding which ones work best and making them fast enough to be practical and suitable for commercial applications.
   *Graph and Path Finding: Can these techniques even be used?
   *Minimal Instruments: How does one divide the music so that they are all playing something most of the time?
   *Musical Transposition: Out of all the most common keys used for the guitar, which one do you choose and in what order do we test keys? Is there an optimal order of which key to test?
   *Alternate Tunings: Which tunings do you choose, and in what order do you test them? There's no research on this, and for each alternate tuning you choose, you double your search space (because you have to solve the problem again). Also, can we somehow test different alternate tunings at the same time during playability testing to save time?
   *Mixing Transposition and Alternate Tunings: Now our search space is SUPER HUMONGOUS! Can we even effectively and efficiently search this space?

For next week I'm preparing a demonstration for all the topics I plan to cover in the thesis.

[edit] Mar 16 (finals week)

Finished up working on that thesis prospectus. Everybody have a nice one-week vacation! See ya next quarter!