CSC 200 Course Description
This course is intended to provide students with a hands-on feel for
research in computer science.
A significant component of the course will revolve around a set of
semester-long “impossible projects”.
These are team system building efforts consisting
of the following:
- researching, understanding, and presenting the state of the art in
a specified semi-open problem;
- grounding and solidifing this understanding by
implementing a solution that approaches the state of the art; and
- attempting to identify areas where the state of the art
might be pushed and pushing on it.
Team members will present status reports to the rest of the class on a
regular basis, via semi-formal discussion sessions in which team
understanding, approaches, and progress will be critiqued and
potentially modified. Teams will also prepare weekly written reports.
Several different projects will be pursued in parallel by teams of
3–5 members.
Teams and topics will be selected by the instructor and TA a
couple of weeks into the course on the basis of survey information,
class discussion, and some preliminary projects.
Our hope is that most students who are going to drop the course will
have done so by that time, so we can have stable teams.
Depending on class size, we may have more than one team on a project,
in semi-competition.
Since both the instructor and the TA have Systems backgrounds, the projects
are likely to have an “Systems-y” flavor: although we will
not be providing specific instruction, we need to be able to tell if teams
are really off track or heading up a blind alley.
A second component of the course consists of guest lectures by
researchers (faculty and/or senior graduate students) in the computer
science department.
The course may also address
- proposal writing and evaluation
- literature searches, using library resources and bibliographic tools
- technical writing and reviewing
Attendance is mandatory. Participation in critique sessions is an
essential part of the experience, as is attendance at guest lectures.
There may be 5-minute quizzes on material occuring in the previous
class as a means of documenting attendance and attention.
This could include the content of unscripted discussions.
NOTE THAT CSC 200 IS NO LONGER REQUIRED FOR THE CS DEGREE.
Students should not undertake this course lightly.
It is expected to be a significant amount of work. Research is that way.
It is also likely to be the first course where the professor is not
providing material and answers, or even detailed instructions.
That is also how research is.
If you are not interested in this sort of experience, don't take the course.
If it's your bag however, it could be a bit of fun,
and you will certainly learn a lot (not all of it technical).
Lectures:
Tuesday and Thursday, 3:25 to 4:40 p.m., in CSB 601.
Prerequisites
The course requires extensive programming, so 173 is required.
The projects will require the use of multiple source files and
libraries, so experience with programming utilities such as
make and
rcs/cvs/bitkeeper is desireable.
Efficiency is an issue in the projects, so ability to program in
a relatively efficient language such as C or C++ (though not assembly)
is required; Java may not cut it.
Grading
Grading will be based on a mix of
attendance, quizzes, and class participation (~20%); the final semester
project (~25%); other projects, presentations, and reports (~35%); and
summaries of guest lectures (~20%). These numbers are subject to
(modest) change. I do not anticipate giving any exams.
Upper-Level Writing in CS
There will be a large number of writing assignments in this course.
Students who wish to use 200 to satisfy an upper-level writing
requirement in Computer Science should send the professor an email note
to that effect no
later than class time on January 22. In addition to the
regular course requirements, students electing this option will be
required to revise all written assignments based on instructor feedback
and resubmit for a second evaluation.
I will evaluate second drafts on the basis of writing (organization,
grammar, style, cogency of arguments), rather than technical content per
se. You'll need to average a “B” on these to satisfy the
writing requirement.
No Late Assignments
It is my strict policy not to accept late assignments.
Exceptions will be made only under the most dire of circumstances.
Note, however, that I am extremely generous with partial credit, so
turn in what you have.
On traditional programming assignments I have been known to award as
much as 40% of the total points for reasonable preliminary thoughts on
how one might have done the assignment — without a single line of
code. This can easily mean the difference between letter grades at the
end of the semester.
So if it looks like you aren't going to make a due date, don't keep
hacking down to the wire. Stop a couple hours early and take the time
to organize what you have and put together a write-up that presents it
in the best possible light. Your transcript will love you for it.
Academic Honesty
Student conduct in CSC 200 is governed by the College
Academic Honesty Policy, the
Undergraduate Laboratory Policies
of the Computer Science Department, and the
Acceptable Use Policy of Academic Technology Services.
I helped to write two of these policies personally. I believe in them
strongly, and will enforce them aggressively.
As in all intellectual endeavors, proper attribution of work is crucial
to research. Be sure to attribute any work that is not your own,
including software off the web, text cribbed from other sources, etc.
You are encouraged to look for resources, but not to the extent that it
negates the point of the assignment. This is sometimes a fine line,
especially in programming assignments. I will try to be specific as to
what I expect you to write as a minimum. If in doubt, ask. In any case,
use of unattributed material is plagiarism.
You are encouraged to discuss general techniques and specific approaches
to general problems with your fellow students, or anyone else.
Unless specifically directed in an assignment, however, you are not to
share code you have written, or your written solutions to specific
problems. If you discuss ideas with anyone not on your team, you are
required to leave the discussion with no notes whatsoever.
Everything you subsequently write down must come out of your own
head.
Last Change:
05 January 2005 /
