Submission Information

1. Your code.
2. Your identification data.
3. Your writeup.

1. It should all be in a single file named octree.c or octree.cc; for example, if you made a local copy of octree.h and modified it, make sure you cut-and-paste the modifications into octree.c or octree.cc before submitting. The octree.c or octree.cc file should reside in your cs161_project directory.

2. It should be written in C or C++.

3. It should compile on an epic, using the do compile command.

4. It should run correctly on an epic, using the do test command.

5. Outside commented text, it should only contain code potentially invoked by our code. So, if you defined any auxiliary functions for debugging purposes, or if you have interspersed assertion statements in your code, please remove them or comment them out before submitting.

6. It should be documented well, with in-line comments and well-picked identifiers.

   Comments should not point out the obvious, as in

     i=j;   /* Set i to have the same value as j. */
   

   Nor should they cover high-level material discussed in the writeup. Instead, they should provide the conceptual bridge between algorithm and code.

   Picking good names for identifiers is just as important. While i, j, and k are acceptable as loop iterators, you should choose variable names, struct fields, and names of auxiliary functions in a manner such that their relevance to your algorithm is apparent.

1. The names of all the members of your group, each on a separate line.
2. An empty line.
3. The SUNet IDs (Sweet Hall logins) of the members of your group, each on a separate line.

Here is a sample README file; there are no empty lines before the first name:

Apostolos "Toli" Lerios
Aristides Gionis

tolis
gionis

• A complete description of the algorithms you implemented for tasks 3, 4, 5, 7, 9, 10 (optional). Describe how you build and print your octree, how you retrieve the volume value at a given point, and how you trace a ray in the presence of floating point pitfalls.
• Your answers to tasks 1, 2, 6, 8.
• References/credits: if you used any papers, books, WWW pages, public domain code, etc. that we did not provide to you, please give credit where credit is due. Acknowledgments to people who helped you (aside from project partners and the teaching staff) are also welcome.

• HTML. Since basic HTML can be very easily learned following an on-line tutorial, we encourage you to turn in your writeup as a collection of HTML files, images, and other multimedia aides.

  Why HTML? Not only does HTML allow you better formatting than mere text, easy inclusion of images, facilities for building tables, and other niceties, but it also makes it easy to provide hyperlinks to on-line descriptions of related work. More importantly, you may incorporate your writeup in your personal WWW pages; then, when you get the interview question "So, what were your class projects like at Stanford?", you can smile smugly, walk over to the interviewer's workstation, and point-and-click. (If they don't have a WWW browser, you may want to think again whether you want to work there.)

  If you decide to turn in your writeup in HTML, please create a subdirectory named doc_html within your cs161_project directory, and place within doc_html all your HTML files and other multimedia aides. Also, if your documentation comprises multiple HTML files, please make sure that the first page we should read is in a file named index.html, residing in your doc_html directory.

• PostScript. If you choose this format, please place your complete writeup in a file named documentation.ps, residing in your cs161_project directory.

  If you use a Mac/PC to produce your PostScript file (usually, by printing to a file), make sure you instruct your word-processor to include all fonts in your file (if applicable); also, use Fetch in raw mode (or FTP in binary mode) to transfer your file onto an epic.

• Mere text (just ASCII). If you choose this format, please place your complete writeup in a file named documentation.txt, residing in your cs161_project directory.

1. Log on an epic.

2. Make sure that all the required project files/subdirectories are in your cs161_project directory, as discussed above.

3. cd to your cs161_project directory, i.e. cd within your cs161_project directory.

4. Execute do submit and follow the instructions on the screen.

5. If do submit does not cooperate, please call the instructor.

1. Does each group member have to submit their common project separately?

   There should be only one submission per group. Individual group members need not (and must not) each submit the same project individually.

2. My group made a few last-minute changes. Can we submit again?

   You should normally execute do submit just once, after you are 100% sure you are done with your project. If there is a catastrophe, and you end up submitting twice (by executing do submit again), all your previous submissions will be automatically deleted.

   If your group comprises more than just one person, then all submissions must be made by the same person, and from a cs161_project directory created by that person.

3. How do I know whether do submit completed successfully?

   Unlike other submission programs you may have used, do submit does not send out an email message notifying you of successful completion of the submission process. do submit has done its job if it has executed without any errors, and if it lists all the required project files before it exits.

4. What does do submit do to my account?

   do submit just copies the relevant contents of your cs161_project directory into the class directory. It doesn't change any file or directory permissions in your account.

5. Do I need to keep around my personal copy of the cs161_project directory after submitting?

   You may clean up your account, and eliminate all project-related files, anytime after submitting your work. However, we strongly suggest that you do not do so before the end of the quarter.