Guidelines for final reports:
Be sure that your writeup contains:
- Team and member names (one report per group).
- Your goals for the project
- Your system design and algorithmic choices
- Sample screens of typical usage scenarios (if applicable)
- Experiments and results that show how effective your system
is, and where it could be improved. See the discussion at the bottom of
this page.
- Anything you considered suprising or that you learned. What would
you do differently if you could?
- Conclusions and ideas for future work
- Appendices:
- Which people did what parts of the work? Were there problematic
dynamics in your group?
- What externally-written code (if any) was used in your project?
- Instructions on how to start and use your project (including OS
or browser requirements, pointer to a README file (or include that
inline). Is there a website to visit?
There is no limit on length, but we appreciate good organization and tight,
precise writing. Points off for rambling and repetition.
What to Hand In
- Please give Dan a stapled, double-sided, hard-copy of your
report as well as an electronic version of both the report and the
code using class turnin.
- We also need an electronic (.pdf) copy of your in-class presentation
so please submit that at the same time.
- Late submissions for the final project and writeup will not be
accepted, as it will be the end of the quarter and the registrar applies
a hard deadline for grade submission. Sorry! (But happy
holidays).
Experiments
No matter what you do, start by clearly stating the question you are trying to answer.
There are three main ways you can
evaluate your system: two pertain to the system as a whole (including the
UI) and the other looks at the performance of one or more submodules.
(Since non of the 454 projects have a UI component, I'm cutting two of my
bullets)
- Module performance study.
Most (if not all) groups should include at least one experiment of this
form. Fortunately, with advance planning, these don't take very
long. Indeed, you did something of this form with HW1 and your evaluation
of the naive Byaes classifier. The
trick is to plan what you will measure before you write your code.
Pick a performance measure that is relevant to the system you have built:
precision? recall? speed? accuracy? throughput? latency? In the simplest
case, just measure this aspect of your system. Ideally, however, you will
measure two versions of your system and compare the two. For example,
classifier accuracy using a bag of words representation vs bag of words
augmented with part of speech tags. Or throughput with and without your
snazzy caching scheme. This is why it is important to plan such an
experiment before you have implemented the caching mechanism - so you can
easily turn it on and off. Here's one example of a paper which include
results of this form:
Information
Extraction from WIkipedia: Moving Down the Long Tail by Fei Wu, Raphael
Hoffmann, and Daniel S. Weld, KDD 2008.
In all cases try to present your results graphically (instead of a big
table). When creating such a graph, beware of Microsoft Office
default templates which include
gratuitous chart
junk. Instead maximize the data/ink ration. See this discussion of data presentation principles.
CSE Home 
About Us