PROPOSAL DUE: 11:59pm, Friday 3/16
IN-CLASS PRESENTATION: Wednesday 4/18
FINAL PROJECT DUE: 11:59pm, Wednesday 4/18
Grading: 30% of your final grade
The course policies page outlines academic honesty as applied to this course, including policies for working with other students on assignments. It also gives the rules for on-time homework submission.
There are two possible types of course projects, depending on your definition of a primary deliverable: software systems and written documents. If you choose to build a software system (and only in that case), you may work in a pair.
There are two possible types of course projects: software systems and written documents. You will choose the type at the time you submit your project proposal, which must define a primary deliverable, which will either be a piece of software or a conference-quality research paper.
In all cases the topic of your project must be broadly related to geometric computation, and must require you to work in detail with at least one of the topic areas we study in the course.
Your project for this course must be novel, i.e., it must be a project that you have not already done for any other purpose. Also, to avoid plagiarism, you of course cannot submit a project which is simply a copy of any existing work.
In some cases it will be acceptable to define a project that is a significant extension of work that either you or others have previously done. If you choose to do this, you must clearly state so in your proposal, and you must delineate what new aspects are contributed by your project.
If you choose to build a software system, you must define the primary deliverable to be that system, in source form. You will be graded on the content of the source code you develop, its functionality, and its documentation.
Programming Environment: In general, you may use a programming environment of your choice (Java, C/C++, Matlab, etc). Please state in your proposal which environment you intend to use. The only limitation on programming environment is that the course staff needs to be able to compile (if applicable) and run your program for grading purposes (note that it is not sufficient to simply supply both the source code and a pre-compiled executable—if you use a compiled language, we need to be able to re-compile your code). This mainly limits you to using freely-available programming environments, though we do have Matlab. Please resolve any questions you may have about this requirement with the course staff prior to beginning your work.
Scope: You will have until the last day of class to complete the project. The scope of your work should be set accordingly. A wide variety of project types will be acceptable. In general, we expect you to put in significant work, however, you must also consider the limitations of what you can produce in the available time.
A major aspect of the project proposal phase is to define the scope of your project and to get feedback on it from the course staff. We will help you adjust your ideas, if necessary, to fit the appropriate scope.
Your system must include some sort of comprehensive end-user interactive application and/or test suite; i.e. it must not be just a library.
Documentation: Just because you are writing code does not excuse you from writing English documentation (and, in many cases, you will also need to produce supporting figures and graphics). This must cover (a) end-user instructions, and (b) the architecture and detailed design of your system.
If you choose to build a software system, then you may work in a team of up to two students. Team projects should have a somewhat larger scope than single-student projects (to be determined qualitatively by the instructor). Each member of the team should have a clear and roughly equal contribution to (a) the source code, (b) the documentation, and (c) the in-class presentation. In particular, your documentation should include at least a one-paragraph summary of the division of labor between the team members, and each source file should list the primary authors of the included code.
If you choose to write a document, your final product should be a conference-quality paper. In general this means
We are reading a number of conference papers in the course, so the overall structure should be familiar to you.
If you choose to write a paper, then you must work alone.
The project proposal must be a written document of no less than one and no more than two standard single-spaced typewritten pages, plus at least one drawing or other graphical figure showing the high-level concept of your proposed system or research problem.
Your proposal should start by defining the primary deliverable of your project: whether it will be a software system or a written document, and what the primary functionality or research topic will be, respectively.
You should further discuss
If you are working on in a pair on a software system, you may submit one proposal for the team. You must define the specific roles and responsibilities of each team member.
The main purpose of the project proposal is to define your project as a reference for yourself and for the course staff. We will contact you with feedback on your proposal, including any suggestions we may have regarding related work, possibly useful materials, and any potential issues with the project’s scope.
During the last class meeting each student or team will present their term project for 10–15 minutes. The presentation can be informal, and is mainly for you to demonstrate and/or describe your work to your classmates and to the course staff.
If your project is a software system, your final submission must include all source code and documentation. You may also optionally submit executable binaries, if applicable in your programming environment.
If your project is a written document, your final submission must be the complete document in printable PDF format.
Both the proposal document and your final submission must be submitted electronically. Please follow the instructions on the assignments page.
Both the proposal and the in-class presentation will be graded pass/fail.
Grading of the final submission will depend on whether your primary deliverable was a software system or a written document.
For software systems the grading breakdown will be: 40% completeness of advertised functionality, 20% correctness, 10% efficiency, 20% documentation, 10% appearance.
For written documents the grading breakdown will be: 20% introduction and research context (including relevant related work); 20% technical problem statement; 30% description of technical approach(es) to solving the problem; 10% figures and graphics; 20% analysis, results, and conclusions.