Questions? Ask them on Piazzza.
Welcome to the Spring 2011 session of Grinnell College's CSC 161,
Imperative Problem Solving and Data Structures. The course
is described, in part, in the official blurb. From my
perspective, this course
serves many purposes: It teaches you a new approach to algorithm design
imperative paradigm); it introduces a number of tools you
will use in your career, including Linux, Emacs, and Make; it further
grounds your study of important data structures and algorithms; it introduces
an imprortant programming language, C; and it gives you a particularly
hands-on perspective on computer science.
In an attempt to provide up-to-date information, and to spare a few
trees, I am making this as much of a
paperless course as I can.
Hence, materials will be in a course web.
Warning! Computers are sentient, stupid, and malicious. When things go wrong, don't blame yourself. Ask me for help.
Very rough draft!
By the time you complete this course, you should be able to
Meets: MTuWF, 11:00-11:50, Science 3813
Instructor: Samuel A. Rebelsky (email@example.com), Science 3824. Office hours: MWF 1:15-3:00. I tend to follow an open door policy: Feel free to stop by when my door is open or to make an appointment for another time. Check my schedule for more details.
Mentor: Andrew Hirakawa. Office hours TBD.
Grading (subject to change):
Late Assignments: My experience shows that students who turn in work late learn significantly less than students who turn material in on time. (I'm not sure about cause and effect.) Hence, I strongly discourage late assignments. Late assignments are penalized one letter grade (or equivalent) per day (or fraction thereof) late.
Because I am concerned about your health and well being, I will waive the late penalty if (1) you start the assignment at least three days in advance of the due date; (2) you get to sleep by midnight the night before the assignment is due; (3) you expend a reasonable amount of effort to complete the assignment by midnight; (4) you turn in a form attesting to facts (1), (2), and (3) when the assignment is due; and (5) you talk to me ASAP about any problems you've had on the assignment.
In addition, every student will be granted two grace days that can be used for any homework assignment, for any reason. A grace day is an automatic extension until the next class period. Please use your grace days wisely: you may need them more later than you do now! I would appreciate hearing in advance by email if you intend to use a grace day on a particular assignment since this makes my bookkeeping easier. However, any assignment submitted late will automatically use a grace day, if you still have one to use. (This policy applies only to homework assignments and not to examinations or readings.)
Attendance Policy: Because this is a lab-based class and because I know students benefit from the presence of their colleagues, I expect you to attend every class period. In my experience, students who do not regularly attend class cause significant difficulties not only for themselves, but also for their classmates and for me. Hence, I have a strict attendance policy: Students with more than two unexecused absences will fail the class (or will be withdrawn from the class).
Of course, I realize that there a variety of legitimate reasons that you will be unable to attend class, including, but not limited to, academic events, athletic events, illness, and family emergencies. Whenever possible, you should contact me in advance if you will be unable to attend class. Otherwise, you should notify me as soon as possible after class. If you must miss a class because of illness, I want you, rather than Health Services, to notify me.
Extra Credit: Multiple kinds of extra credit are available.
immersion styleapproach. That is, you'll work with large chunks of the language starting with the first day, and then go back and look at more details of each chunk.
Good-Faith Grade Guarantee:
Students who make a
good faith effort in this class will pass
the class, with at least a C. A good-faith effort includes missing no
more than two classes, turning in every homework assignment and reflections
on at least 90% of the readings, and spending the requisite time on each
I've tried to choose books that you'll want to keep on your bookshelf long after the class is done.
Kernighan, Brian W. & Ritchie, Dennis, M. (1988). The C Programming Language, 2nd Edition: ANSI C. Upper Saddle River, NJ: Prentice-Hall.
The classic book on C, by the designers of the language. A bit denser than most books, but has very little cruft. I particuarly appreciate that the book helps you think like a real C programmer. The book, like the course, takes an immersion approach.
Mecklenburg, Robert (2004). Managing Projects with GNU Make, Third
Edition. Sebastapol, CA: O'Reilly and Associates. Also available online
Make is one of the key tools Unix programmers use. This is an excellent introduction to the tool. We will focus on introductory chapters.
Raymond, Eric S. (2003). The Art of UNIX Programming.
Addison-Wesley, Professional. Also available online at
This book has very little detail on the standard Unix commands, but helps you think about why Unix variants have continued to exist for three decades. We will probably only skim this book.
Harbison III, Samuel P. & Steele Jr., Guy L. (2002). C: A Reference Manual, Fifth Edition. Upper Saddle River, NJ: Prentice-Hall.
A more formal and more comprehensive definition of the language than is available in K&R.
Plauger, P. J. (1991). The Standard C Library. Upper Saddle River, NJ: Prentice-Hall.
More information than you'll ever need about the various library commands available to you. Clearer and better than the corresponding man pages.
Saturday, 14 August 2010 [Samuel A. Rebelsky]
Wednesday, 1 September 2010 [Samuel A. Rebelsky]
Wednesday, 5 January 2011 [Samuel A. Rebelsky]
Thursday, 20 January 2011 [Samuel A. Rebelsky]
Monday, 24 January 2011 [Samuel A. Rebelsky]
Tuesday, 25 January 2011 [Samuel A. Rebelsky]
Tuesday, 5 April 2011 [Samuel A. Rebelsky]
I usually create these pages
on the fly, which means that I rarely
proofread them and they may contain bad grammar and incorrect details.
It also means that I tend to update them regularly (see the history for
more details). Feel free to contact me with any suggestions for changes.
This document was generated by
Siteweaver on Tue May 10 10:34:13 2011.
The source to the document was last modified on Tue Apr 5 08:09:41 2011.
This document may be found at