www.cs.amherst/~ccm/cs341/firstassignment.html
CS341
First Assignment
This assignment has two parts: the group project and your
individual work. Your grade for this assignment will be the
average of your group project and your paper.
The Group Project due Thursday October 3rd
Here's what you need to turn in for the group project. Everyone in the group will get the same
grade. If it turned out that you contributed less to coding in this round, you can make it up
by taking over the bulk of the manual-writing responsibilities outlined below.
I will let you know if I think there is a large imbalance in the overall level of
contribution/engagement of individuals within a group.
Slackers will not get points off on this project grade,
but I will expect you to contribute more to your next project, to balance things out.
Here's what you turn in.
- The code for your beat-autocorrect program. It should be reasonably efficient,
robust, and show excellent java coding style. Also,
could you please include comments in the code indicating who
wrote (or co-wrote) the individual modules.
- A Maintainer's Manual that a future programmer could use
to modify or fix your code. This manual should contain
- An overview of the main components of the system and how they
work together. Call them by name (i.e. readLexicon
instead of the Lexicon Input component), so the manual-reader can figure out what code
section to look at.
- For each major component, a description of the interface: what values
are provided and what values are returned, by name.
- For each major component, a description of how it works, what assumptions
are made, what exceptions and failures can arise, and so forth. Ideally this
part would have a guide to troubleshooting.
- A User Manual that tells the user how to use it, what to expect, what might go
wrong, etc. It doesn't have to be very big, but it should be useful.
- Your group will also make a (30 minute or so) presentation in class
on Thursday, October 3. Describe, for the other teams, your
solution strategy, what features you decided to emphasize, maybe a summary
of your benchmark tests, and other things that might interest the class.
Powerpoint would be excellent! We can hold class in 007 if you would
prefer.
Individual Paper due Tuesday, October 8th
Your paper will be graded on both content and writing style.
Your assignment is to carry out some type of experimental evaluation of the code
developed by your group, and to write a paper describing your results. The results should
be based on numerical data that you collect, not just qualitative observations. I'm thinking
lots of graphs and charts. Here are some ideas for paper topics.
- Characterize what types of inputs make your code succeed and what make it fail.
You can define success and failure according to measures like percent of errors identified;
number of times a correct substitution is made; number of times the correct suggestion
appears in the top 5 list; or whatever. Your characterization of inputs should be as numerate
as you can make it: maybe in terms of an error scale (number of wrong characters, or distance
of wrong characters from correct ones). Do your best to find a quantitative relationship between
input properties and success rates, but if you can't find one, say so.
- Describe the results of an algorithm/code tuning experiment: start with the basic code,
explain how you profiled it to learn where the hot spots are; what alterations you tried; and
what worked or didn't work. Report results for counters that describe performance in
the code, as well as runtime statistics.
- Take a piece of the overall project and get a clear understanding of
what ``typical'' data looks like and how it affect performance of that piece. For example,
how many words does a typical input have? How many candidate words are returned in a typical
lookup of something misspelled? What is the cost (nxm) of the edit distance computation
per word? Stuff like that.
What I Hope You Learned From this Project
Lessons to be carried into the next project.
- Real world problems are messy. They don't fit exactly into our abstract
algorithm categories, and often involve ill-defined objectives.
So it's not always about knowing which algorithm from your repertoire to apply; its
about cobbling together algorithmic ideas into something that might work.
- Instead of implementing one program, you (a group)
have to implement a set of modules using different languages and tools. Clarity about interface
design is important.
- All those noises we professors make about well-designed (maintainable),
correct, robust code are important here.