Final project

This course will finish with each of you completing a final project. Projects should be done in small groups (3-4 students) but this is a guideline. We will switch over to working on the project nearly full time in the last month or so of the semester, so the scope of the project should be appropriate for that time line.


The goal of the project is for you to create (or extend) a project utilizing the techniques you have learned in this class. In particular, the project should involve:

  • Version control (with Git or otherwise)

  • Unit testing for all new features

  • Documentation for public APIs

  • HTML visualization of the project

  • Attention to performance, where relevant.

    This doesn’t mean you need to extensively performance tune your project; rather, you should make informed decisions about the kind of data structures you choose in the core routines.

Your project should (hopefully) involve your research. This project doesn’t need to be started from scratch; if there is a problem you’ve been working on and it needs a computational study, do it! Likewise if you’ve previously created a library or program to solve a certain problem, you can extend that project with new functionality, improved performance, updated documentation, and more complete unit tests.

Semester Checkpoints

You do not need to know exactly what you want to build on day one. There will be certain checkpoints throughout the semester to solidify concrete goals and scope for each of the groups. These include brief write-ups for a project proposal and a midpoint status update, or even meetings with myself. I will keep the course calendar updated with due dates for these checkpoints.

What to turn in

  • A document explaining the project, including

    • Motivation
    • Implementation details
    • Explanation of how to use the project
    • Computational results – timing tests, solved problems, etc.
    • What was accomplished, and what could be accomplished in the future
  • Documentation

    The details are largely language-dependent, but there should be a set of documentation that is separate from the source code. Note that it is fine for the documentation to be generated from the source code, it just needs to be available separately.

  • Source code

    This can be an archive of the entire project, or a link to a repository that the project can be cloned from. Should include:

    • Source files
    • Test files
    • A README explaining how to get started (which could just direct you to the documentation from above)
  • Final Presentation

    At the end of the semester, your group will be asked to give a brief (10-15 minute) presentation to the rest of the class, talking about the problem you are tackling, a brief overview of your implementation, and a visual demo using a web framework of your choice.

  • (Optional) A brief description of the project with links to the documentation (in HTML).

    This will be hosted on the course web page for future courses to reference.

Past Projects

The following are some notable projects from previous iterations of the course.

  • RandomStreams.jl (Spring 2015)

    Patrick Steele, Stephen Pallone, James Dong

    A Julia implementation of the MRG32k3a random number generator proposed by Pierre L’Ecuyer. Allows creation of multiple statistically independent random number streams and substreams.

  • Fast Fourier Transform (Spring 2015)

    Emily Fischer, Dave Lingenbrink, David Eckman, Venus Lo, Wei Qian

    Implementation of inverse Laplace transform, Fast Fourier Transform, and inverse Fast Fourier Transform.

  • Support Vector Machine with Rejection (Spring 2016)

    Matthew Zalesak, Andrew Daw, Samuel Gutekunst

    Implementation of a support vector machine (SVM) that allows rejection of outliers, applied to 2016 Presidential Primary Election data.