General Policy

Homeworks may have two parts: programming files which must be submitted electronically, and written answers which must be turned in on paper to the TA.

Programming files will be due at 11:59pm on their due date. Directions for submitting the homeworks electronically will be given at the end of each problem statement. You may turn in programming files one day late with a 25% penalty. If the assignment is submitted more than one day late, it will not be graded and will receive zero points.

Written problems will be due before class on the due day, and accepted until 5pm subject to a penalty of 25%. No submission of written problems will be accepted after 5pm. You may turn them in just before the lecture on the due day, at Dr. Jia's office (207), drop them into his mailbox in the CS main office (226) or the TA's mailbox in the basement, all in Atanasoff.

All programming assignments must compile and run on a ComSci dept. Red Hat Linux machine using the g++ compiler and the Makefile, if given for that homework. The particular machines that you can use to test your code on are popeye, durango, bahamut, braska, cindy, ixion, jecht, kimahri, mindy, seymour, tidus, and yojimbo. (However, the department asks that you do not do much code testing on popeye, as it tends to get overloaded as the semester goes along. From popeye, telnet to one of the other machines to compile and test, preferrably.)

In case you do not have a CS account, you can create one yourself by visiting http://register.cs.iastate.edu/.

Project Submission Guidelines

1. Submission method

   To submit your project, upload a zip file containing all project files using WebCT. The requirement may differ from project to project. If header files (i.e., .h files) and a test file are provided for a project, you need only submit the corresponding implementation files (i.e., .cpp files), unless one of the following is true: 1) you have made changes to the header files; 2) the project also needs the .h and .cpp files from a previous project. In case 1), you are required to submit the modified header files as well. In case 2), you also need to submit the .h and .cpp files from the previous project.

   Your zip file should be named in the format FamilyName_FirstName_ProjectNum.zip such as Doe_John_project5.zip for Project 5 completed by the student John Doe. Upload by clicking "Add Attachments" toward the bottom of the assignment page in WebCT. Make sure that you submit the complete collection of files required to build and test your projects. Even though you are not submitting your projects from the departments Linux machines, it is still important to make sure that your projects runs propoerly on these machines as grading will take place on similar systems.

2. Files that should be included in your submission

   You need to provide as much information as possible in your submission to tell the TA how to build your programs. Usually, you should include at least one README file that provides your name, your student ID, and detail instructions on how to test your projects from the source files you submitted. Actually, you may wish to include a Makefile as well so the build process can be made easier. If your program has some fancy features that are not immediately noticeable, you may also wish to mention that in your README file. The README file will be like a user manual to the TA, so don't hesitate to write more if you wish to make sure the TA knows how to evaluate your projects. Don't forget to include all supplemental files, header files, or test files with your submission if they are relevant to your projects.

3. Files that should NOT be included in your submission

   Only source files and appropriate auxiliary files for making your executable code should be submitted. Do not send in object or executable files that can be recreated from your source files. They will be ignored. Definitely do not send in coredump files, since they are bulky and take up lots of space. Actually, the submit program will refuse any file bearing the name "core". If you accidentally typed submit 1 * after working hard 24 hours on your computer to beat the deadline, and just realize that you have submitted junk files as well as good files by accident, you should write an email to the TA explaining that you are just being exhausted for doing your projects. I am sure the TA will understand and help you clean up the mess. Please remember, however, there is usually a 10% aesthetic grade regarding each project, which includes the judgment by the TA on how well you manage your files and the submission process.

4. If the TA has problems testing your projects

   The TA will send you emails asking your help to make sense of your files if he fails to make it based on your README directions. You will be given an opportunity to demonstrate how files you have submitted can make a good working program(s) that runs on the TA's machine. You will not be allowed to supplement missing files after the deadline unless you are willing to take the late submission penalty. If the problem is related to the specific platform you have chosen, then as said before, you will need to solve that problem yourself. The TA will not be obliged to port any unavailable software you have chosen to implement your projects to the CS lab machines.

5. If you have a dispute with the TA

   After you tried your best to convince the TA that you have done your project but he still failed to compile your project successfully on his machines, or that you think your projects have not been graded fairly in any aspect and you also failed to convince the TA your belief, you can bring your issues to the Instructor for consideration. The Instructor will try to listen to your story, and also the opinion of the TA. He will make a decision later whether to accept your story or to stand by the TA's decision. This will be the final decision. In any case, you should act professionally, dispute with courtesy and argue with good manners. Both the TA and the Instructor are here to help you, as long as you are reasonable.

6. Copyright issues

   You should grant the Instructor and TA rights to read, demonstrate, modify, compile, execute and archive your code for academic purposes, including but not limited to, distribution and publication for future students. Your identity will be stripped from your code to protect your privacy. Your use of the submit program implies that you agree to these terms. You retain the title of your code for your future uses, except the part that's directly originated from the project descriptions which is copyrighted either by the textbook authors or the Instructor. We will keep an archive of your files indefinitely to compare against future class project submissions in order to prevent academic dishonesty. If you do not agree with this licensing arrangement, you should talk to the Instructor.

   While working on the current project, you are allowed to make use of the posted sample code from the preceding projects in the same semester.

   That's all, folks. If you have any question regarding the project submission guidelines, or you find any bug with the project submission program, you can contact the Instructor.

Code Grading

If your programming assignment does not compile on one of the above machines, no points will be given. The only exceptions to this policy are rare cases where a small change (adding a semi-colon, include directive, etc.) can be made that results in a clean compile. In these rare cases, a maximum of 50% of the points for the programming assignment will be given if the corrected program passes all test cases. Determining whether a no-compile can receive any score other than a zero is at the sole discretion of the instructor(s) and/or grading TA.

If your programming assignment cannot be run and tested automatically by the TAs' grading scripts because you did not follow the directions given in the assignment handout or FAQ, then no points will be given. The only exceptions to this policy are rare cases where a small change can be made that results in a testable program. In these cases, a maximum of 50% of the points for the programming assignment will be given if the corrected program passes all test cases. Determining if a untestable program can receive any score other than a zero is at the sole discretion of the instructor(s) and/or grading TA.

If testing a programming assignment results in any run-time error, you will receive a 10 point penalty on that assignment (in addition to any points you lose for incorrect or missing output.) This includes infinite loops, segmentation faults, bus errors, or any other situation where the program does not halt as expected.

Sample test code may be provided with some assignments. This is a sample only and in no way represents an exhaustive test case. Fully testing your program is part of the assignment.

Clarification, Documentation, Style

Each problem statement for programming assignments may contain design issues that need further clarification. Finding these issues is part of the assignment. (This is much like the real world, where any interesting problem can not be specified exactly ahead of time. Getting clarifications is part of a programmer's job.) There will be a FAQ posted for each HW; the problem assignment will state where to look for the FAQ. When a student finds an issue and sends the question to the instructor, an entry will be added to the FAQ that will clarify that issue. The clarification process may continue until noon on the day the programming assignment is due. Programming assignments that do not adhere to these design clarifications may receive penalties. Making incorrect assumptions without clarification may also result in penalties.

All programming assignments (except for HW0) must include proper documentation and programming style as presented in the first recitations to receive full credit. Documentation will be worth 5-10 points per HW.

Appealing Your Grade

For each programming assignment there will be a limited window of appeal. You will be given one week after the grades have been posted to WebCT to appeal the score. Make appeals for programming assignments directly to your grading TA during his or her office hours, or email the TA to arrange a meeting if you cannot attend his or her office hours. After the appeal period has passed, the score will stand as is.

If your program had a run-time error or any error that prevented the TAs' grading script from running to completion (besides no-compiles/not-following-directions) and you make an appeal within the one week, then you may work with your TA to correct at most one error and have the assignment regraded. Although the TAs will try to give you hints, tracking down and figuring out how to fix the error is your responsibility. The TA judges what constitutes "correcting one error"; you cannot use this regrading opportunity to fix multiple errors, even if you don't find them until after you have gotten back your first result. The TA will regrade the corrected copy, but the maximum grade will now be 40 points, not 50. This type of regrading can happen only if your code did not finish all the test cases the first time it was graded because of a run-time error.