|6||Traveling Salesperson Problem||4/4||checklist|
|8||Cracking the Genetic Code||4/25||checklist|
|9||Bouncing ball warmup||checklist|
With the exception of Assignment 0, all assignments are due Wednesday night at 11:59 PM by electronic submission. Before you turn in the assignment, be sure to read the Assignment checklist and carefully follow all instructions.
Any changes or corrections to the assignments will be noted in the course announcements. You are responsible for the information in the (most up to date) electronic version of each assignment. Feel free to look ahead at any future assignments that appear online, but be warned that some changes are possible.
The CS101 lab is public lab containing Unix machines on the arizona network. It is always open, and is staffed by lab assistants most evenings and weekend afternoons. Here is the lab assistant schedule. The lab assistants should only be asked general computer-related questions (e.g., basics of Unix, PostScript, and C). They will also assist you in debugging your code, assuming you have first made a reasonable effort to identify the bug and isolate the problem. If you have questions regarding the course material or programming assignments, see your preceptor or instructor.
Submit your solutions to the programming assignments electronically using the command
number is the assignment number and files is the list of files for that assignment. For example,
/u/cs126/bin/submit126 0 readme hello.c
submits the files
for assignment 0.
submit command copies your files to the directory
and lists all the files that you have submitted for assignment
number. If you execute
submit after the
assignment deadline, you will receive a warning message verifying
your actions. If you proceed, your assignment will be marked as
late. You can run
submit more than once, and you
can submit partial lists of files.
Submit the C source code file, e.g.,
and written documentation in a file named
Be sure to include your name and precept number in every file
The purpose of the documentation is to help the graders determine
how well your code solves the assigned problem. Your grade depends
on both the code and its documentation. Computer programs can
be incomprehensible, even to the person who wrote it (wait until
this happens to you). Your documentation should be a brief narrative
(no more than 2 pages) that explains what the various parts of
the program do, and how.
is an example. Preparing this documentation needn't take a lot
of time, but it should be done with care. Writing good documentation
is an acquired skill, whose usefulness you will appreciate more
and more as you write and maintain large programs.
In addition, your code should contain comments and be indented consistently for easy reading, but don't get carried away commenting your code. Don't comment the trivial or obvious; for example,
i = i + 1; /* increment variable i by 1 */
isn't much help. If you use code from elsewhere, identify it
and acknowledge its source in your
readme file or
in comments. Also describe whatever help (if any) that you received
in completing the assignment.
Programming assignments are due at 11:59pm on the date specified.
Assignments submitted late will be graded according to the following
formula: S = .9 R exp(-t/3), where S is the grade given, R is
the grade the work would have gotten if turned in on time and
t is the amount of time (in days) the work was late. Thus, the
value of a late assignment decays exponentially, with a half-life
of just over two days. Examples: work turned in five minutes late
gets 89.9% credit, one hour late gets 88.7% credit, six hours
late gets 82.8% credit, one day late gets 71.7% credit, three
days late gets 33.1%, and one week late gets 8.7%. The date and
time of the most recently submitted file is taken as the date
and time of the entire program. This includes non-program files,
readme file. Programs that are submitted
late may not be graded in a timely fashion. Penalties are waived
only for unforeseen circumstances, like illness, and then only
with an appropriate written excuse.
It is better to submit an incomplete program than to submit nothing. No additional time will be given for unannounced interruptions in computer service. Don't wait until the last minute to write your programs!
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 friends are encouraged. However, when the time comes to write code that solves the problem, such discussions are no longer appropriate - the program must be your own work. If you have a question about how to use some feature of C, UNIX, etc., you can certainly ask your friends or the teaching assistants, but do not, under any circumstances, copy another person's program. Writing code for use by another or using someone else's code in any form is a violation of academic regulations. "Using someone else's code" includes using solutions or partial solutions to assignments provided by commercial web sites, instructors, preceptors, teaching assistants, friends, or students from any previous offering of this course or any other course.
You may, however, use any code from the COS 126
precepts, or course texts, providing that you explain what code you use,
and cite its source in your
readme file or in comments. An
example citation appears in
For each assignment, you must also specifically
describe whatever help (if any) that you received from others in
your readme file, and write the names of any
individuals with whom you collaborated.
This includes help from friends,
classmates, lab TA's, and COS 126 staff members.
If you have a question about what is fair and what is not, please consult a staff member. Violators will be referred to the disciplinary committee for review. Page 71 of Rights, Rules, Responsibilities 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.Also, be warned that it is very easy to identify plagiarism of source code. We use Alex Aiken's renowned MOSS (Measure of Software Similarity) software for this purpose.
Do Yalies need to plagiarise our Collaboration Policy? You be the judge. :)
Every student enrolled in COS 126 has a computer account on the CIT
machines, known collectively as
arizona. This account enables
to use of the computers in Rooms 101 in the Computer Science Bldg., and
those in other public computing clusters around campus. Your
identification is in the campus telephone directory; your password is your
(Phone Access Code) or the last eight digits of your social security
can change your password by typing
passwd and following
instructions. Change it regularly.
You are responsible for
keeping your solutions to the COS 126 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. Read pages 615-623 in Hahn's Student
Guide to UNIX to learn about file permissions.
If the line "
umask 077" is in your
.login file (as it is by default),
only you will be able to access the files that you create.