Project.md

Guidelines for Projects

The projects consists of picking up a research problem related to the course and working on its solution for the duration of this term. Any topic that is covered in the course is acceptable as the domain from which a problem can be selected.

What I expect in the project is a good understanding of the problem, insight into its solution, and a well defined strategy for its solution. You should treat the term project as if you were doing the initial background study for further in-depth research. In other words, the final paper should demonstrate an understanding of and an insight into the problem such that given enough time, you could carry it to its logical conclusion and complete the research. This normally means that you have found at least one way to tackle the problem and have done some preliminary evaluation to test its effectiveness and efficiency. What may remain to turn it into a full solution (perhaps publishable somewhere) would be further analysis/evaluation and fine-tuning the solution. How far you go into the solution together with the difficulty of the problem will determine your final mark.

The research part of the projects will be done in teams of two. Normally, both members of a group will get the same mark.

Project Deliverables

The primary deliverable of the project is a final report (paper). The guidelines for what I expect are the following:

• 8-9 page paper typeset using ACM conference format. The references are extra.

• Again read Tips for writing technical papers by J. Widom to understand what a technical paper should look like.

• In general the paper should have the following sections:

  1. Introduction
     • What is the problem you are solving? This should be clearly and precisely stated early in the introduction. You would be amazed at the number of papers that do not specify what the problem is.
     • Why are you solving this problem? Why should the world care? The issue here is convincing the reader that the problem is of importance, so deserving of your (and the readers') attention.
     • Why is there a need for yet another solution? Quite often, we work on problems that have been studied before. Therefore, you need to provide, in an highlight form, why another solution is needed. If you find a problem that no one thought of before, you are lucky and this is not an important question to address (but then the importance of the previous question is higher).
     • What is the novel aspect of your solution? Novelty is considered very highly in evaluating computer science papers and this is your chance to make your point.
  2. Related Work
     • This is the survey of what has been done on the topic. This is where you show your scholarship and understanding of the problem area. Sometimes it makes sense to include it right after Introduction, other times it may make more sense to include it right before Conclusions. The latter is usually done if you are planning to provide a comparison of your approach with earlier work -- you can't do that until you present your own solution.
  3. Technical body of the paper
     • This can be as many sections as would be require. In many cases, I write an "Overview of Solution" section that highlights the overall approach and identifies the technical problems that need to be solved. Then I have one section for each of those technical problems.
  4. Evaluation
     • Most of the projects in this course are likely to require experimental validation to test both effectiveness and efficiency. This is that section.
     • Given the time constraints, you are unlikely to complete a full evaluation. So, this section should have the preliminary tests you have done to convince you that your approach would work.
     • More importantly, this section should carefully explain your experimental setup, what each experiment is expected to test, and how you would conduct them. This is the basis of your "additional work" after the course (if you wanted to). It should convince me that you know how to validate and test your solution(s).
  5. Conclusions
     • I would like to see a reasoned discussion of what your analysis is of the problem and your solution given the results of initial evaluation. This is also your opportunity to remind the reviewer (me!) of the importance of the problem and the novelty of the solution.
     • Given that you may not have performed all the experiments, this section is also going to be preliminary and subject to change when full experiments are conducted.

• A second deliverable is your project source code: Please put your source code into github and include a link in your project writeup. On the github page, please document exactly how to run your source code.

Project Schedule

The following is the schedule that we will follow. We may have to change these a bit based on the number of people in the class (which will determine the presentation schedule). When I expect something, the time of day will be midnight.

January 29:

• You should have formed a team and choosen a topic by now. I will schedule meetings this week to help you focus. By the end of the day February 6, I expect to get a 1-2 page description of your project

February 6:

• I expect to get a 1-2 page description of your project

February 23:

• You should have finished reading the related literature and should have some initial thoughts on a solution

March 11 (week of):

• I'll schedule meetings with each group to see how things are going.

April 15:

• Deadline for handing in final reports.