|2||Deques and randomized queues||Tuesday, 2/19||checklist|
|3||Pattern recognition||Tuesday, 2/26||checklist|
|4||8 puzzle||Tuesday, 3/4||checklist|
|5||The Markovian candidate||Thursday, 3/27||checklist|
|8||TSP backtracking||Thursday, 5/8||checklist|
Grading policy. You will write some programs for the programming assignments, run them, and submit the code electronically. Your code will be graded on correctness, efficiency, clarity, and elegance. It is your responsibility to describe how you have completed the assignment in the submission, not ours to glean this information from your code.
Lateness policy. Assignments are due at 11:55pm on the date specified. If you submit an assignment late (more than a few hours), you risk losing a substantial number of points. Assignments submitted more than a week late, or after the Dean's date, will receive no credit. Extensions will be granted automatically only for university-sanctioned excuses such as illness, and then only with the proper documentation. You are responsible for planning ahead and managing your time so that you can complete the assignments on time. You must either finish on time or accept the consequences of doing otherwise. Preceptors can also grant extensions on an individual basis at their discretion.
Collaboration policy. Programming is an individual creative process much like composition. You must reach your own understanding of the problem and discover a path to its solution. During this time, discussions with other people are permitted and encouraged. However, when the time comes to write code that solves the problem, such discussions are no longer appropriate: the code must be your own work. If you have a question about how to use some feature of Java, the operating system, or some other relevant application, you can certainly ask your friends or the teaching assistants, but specific questions about code you have written must be treated more carefully. For each assignment, you must specifically describe in your readme.txt file, whatever help (if any) that you received from others and tell us the names of any individuals with whom you collaborated. This includes help from friends, classmates, lab TAs, and course staff members.
Do not, under any circumstances, copy another person's code. Incorporating someone else's code into your program in any form is a violation of academic regulations. This includes adapting solutions or partial solutions to assignments from any offering of this course or any other course. Abetting plagiarism or unauthorized collaboration by "sharing" your code is also prohibited. Sharing code in digital form is an especially egregious violation: do not e-mail your code or make your source files available to anyone.
Novices often have the misconception that copying and mechanically transforming a program (by rearranging independent code, renaming variables, or similar operations) makes it something different. Actually, identifying plagiarized source code is easier than you might think. Not only does plagiarized code quickly identify itself as part of the grading process, but also we can turn to software packages (such as Alex Aiken's renowned MOSS software) for automatic help.
There is one exception to the code-sharing rule: You may adapt code from the COS 126 or COS 226 course materials provided that you explain what code you use, and cite its source in your comments. An example citation appears in StdGaussian.java.
This policy supplements the University's academic regulations, making explicit what constitutes a violation for this course. Princeton Rights, Rules, Responsibilities handbook asserts:
The only adequate defense for a student accused of an academic violation is that the work in question does not, in fact, constitute a violation. Neither the defense that the student was ignorant of the regulations concerning academic violations nor the defense that the student was under pressure at the time the violation was committed is considered an adequate defense.If you have any questions about these matters, please consult a course staff member. Violators will be referred to the Committee on Discipline for review. You are responsible for keeping your solutions to the COS 226 programming assignments away from prying eyes. If someone else copies your program, we have no way to determine who's the owner and who's the copier; the Discipline Committee gets to decide. If you are working on a public cluster machine, use your H: drive, and be sure that the permissions are set so that they are not world readable.
Pair programming. On designated assignments, you may elect (or be required) to work with a partner. In such cases, both partners are responsible for jointly contributing to and understanding all parts of the completed assignment. In this case, only one partner submits the .java files; each partner submit his or her own readme.txt file with the analysis.
What to submit. Submit all of your source code for each assignment. Your code should conform to reasonable style and commenting guidelines. Be sure to include your name and precept number in every file you submit. You must also submit a text file named readme.txt with each assignment. Besides any problem specific information which is listed in each week's assignment or checklist, you should use this file to give the reader a high-level explanation of your source code and point to anything unusual or notable about your program (such as extra credit or known bugs).
How to submit. Submit your solutions to the programming assignments electronically via the web submission system on the course home page. Be sure to submit all of the required files, and use exactly the (case-sensitive) filenames provided. Once you submit all of the required files, click the Run Script button to make sure that it compiles cleanly. If you do not follow these directions, you risk losing a substantial number of points. You can resubmit and unsubmit files as needed up until the submission deadline.