Final Deliverables



Due: Saturday, December 12th 2020 at 12:00 PM (noon) EST

Submission Instructions

Your project should be available in your GitHub organization through your project repo.

Your submission should be in the following format:

project_repo/
             README.md
             docs/  
                  documentation
                  milestone1
                  milestone2
             code/
                 ...

Note that code should be named something informative.

Software Requirements

Here are the main requirements for the final project:

  1. Working forward mode implementation
    • See the sections below for more specific details
  2. Test suite
  3. Updated / extended documentation
    • Your updated documentation will be the final package documentation.
    • Please name it documentation. Do not name it milestone3.
  4. New features

Working Forward Mode Implementation

You must have a working forward mode implementation.

Minimum Package Requirements

Minimum Implementation Requirements

The following is a description of a typical use case.

What Kinds of Functions should be Implemented?

All basic operations and elementary functions should be implemented.

Basic Operations
Comparison Operators

It is up to you which comparison operators to implement. Here are some options:

At the very least, it makes sense to have __eq__ and __ne__. We will be interested to see what (if any) uses you find for the other operators.

Elementary Functions

Note that the hyperbolic functions and the logistic function are arguably not elemental functions since they can be formed from the natural exponential. On the other hand, they do form a key ingredient in some algorithms (e.g. neural networks) and can therefore be considered as elemental functions. You should implement these functions.

Test Suite

You should have a test suite that runs with pytest or unittest. Your test suite should run automatically on Travis CI. The project GitHub repo should contain a badge showing the pass/fail status of your build. The badge should show that your build is passing all tests.

You should also have your project connected to CodeCov. Once again, the project repo should have a badge reporting on the coverage of your code from CodeCov. Remember: Your code coverage should be at least 90%.

Documentation

Your documentation must be complete, easy to navigate, and clear. Remember to update the Background and How to Use sections of your documentation as you add more functionality to your package, so that the user has a good understanding of what they can do. Call the final form of your documentation documentation.

Please update and consolidate all relevant documentation from milestone1 and milestone2 and make any changes suggested by the teaching staff.

Your documentation should be a mix of text and hands-on demos. As always, it is up to you and your group to determine the best way to accomplish this (e.g. Jupyter notebook, GitHub README, Sphinx/Read the Docs).

You will receive full points as long as you have a docs/ directory and your documentation is complete. However, you may want to consider alternative ways of hosting your documentation. For example: Read the Docs or Sphinx.

Documentation Sections

The following sections should be present:

Broader Impact and Inclusivity Statement

Include a section in your documentation and in your Github README on Broader Impact and Inclusivity. This section should be around a half page in length and it can be the same between your documentation and your README. It should address two points:

  1. The potential broader impacts and implications of your software.
  2. How is your software inclusive to the broader community?

Broader Impact

Regarding the broader impact portion, try to think about the ways people will use or misuse your software. What are the consequences? How should people use it responsibly? Are there any ethical implications? The NeurIPS website has a number of references to get you started on thinking about this:

Software Inclusivity

In principle, there should be no barrier whatsoever for other developers to contribute to your code base. In practice, these barriers do exist and can be rather subtle. For example, are there any subtle barriers to underrepresented groups? What about working parents? What about people from different countries or non-native English speakers? Do people from rural communities feel they have something to offer? Carefully think about the code contribution process for your software project. How are pull requests being reviewed and approved? Who is reviewing and approving these requests? Python has a Diversity Statement, but it is fairly generic and contains a lot of boiler plate. Different Python groups may have more concrete policies. Can you do better?

How this will be graded

Both topics in this section are subjective and there is no perfectly correct answer. I am looking for effort and honest attempts to address these issues.

Final Deliverables

The deliverable for the project is a video that describes all of the work done on your project throughout the semester. You are free to decide upon the format of the video yourself (with some restrictions - see below).

Some ideas include:

You may want to consider tools such as asciinema.

We won't be judging you on the quality of your camera or your video editing ability so don't worry about that. We will judge you only on the content you present. However, if the quality of the video is so poor as to prevent us from judging the quality of the work, then we will unfortunately need to deduct points.

Video Requirements

Section Minimum Length
Introduction/background 2 minutes
Implementation details/Software srganization/How to use 4 minutes
Your additional feature(s) and extension 5 minutes
Future work/possible extensions 2 minutes

Video Submission instructions

Things to keep in mind

Grading Breakdown

Points Task
20 Complete forward mode functionality (see above)
15 Documentation & Test Suite (see above)
4 Broader Impact Statement
20 Video Presentation
30 New Feature (see above)
15 Code quality