Course CS 136 Fall 2015
Williams College Department of Computer ScienceInstructor: Prof. Morgan McGuire TAs: Alex Paseltiner, Sam Donow, Kyle Cheng, Jamie Lesser, Nicholas Erikson, and Anna Neufeld Lecture: MWF 9:00-9:50am Room TPL 205 Lab: Wed 1:00*-2:20pm or 2:30-3:50* TCL 216
(* 10 minutes shorter than the registrar's period)Office Hours: Fri 11:00am-12:00pm, and by appointment TCL 308 TA Hours: Mon 7-10pm (TCL 216), Tue 10am-12pm (CS lounge), Tue 7-9pm (TCL 216), Wed 5-9pm (TCL 216), Thu 7-11pm (TCL 216), Fri 11am-12pm (CS lounge), Sun 1-5pm,7-11pm (TCL 216)
Description
Textbooks
Grading
Policies
Honor Code
Disabilities
The course is currently over-enrolled for F15. Students who cannot register through Peoplesoft should sign up on the wait list.Students who are absent from the first class session without prior consent will be dropped from the course and the wait list.
Description
What makes for a good computer program? How should one go about writing one? In this course we will investigate aspects of software construction: careful computational analysis of a problem, choice of data structures, design of efficient algorithms for manipulating those structures, and organization of the program as small reusable abstractions.
Students enter CS136 knowing how to make a computer do almost anything that they wish by programming. They learn to hone that skill to program elegantly and efficiently and gain a deep understanding of how computers and algorithms work. Though readings, lab exercises, and lectures, you will learn a specific set of data structures, programming languages, and development tools (...and how to learn new ones), and as a programmer become: become:
- Independent, by learning to find information yourself and structure your own programs with minimal guidance
- Effective, by designing routines that scale up to large data sets and adopting efficient workflow
- Professional, by working from specifications, programming with partners, and reading and writing technical documentation
Everyone is welcome in the course and will learn a lot about computer science from taking it. This semester's theme is clever algorithms for scientific and engineering programming, which should especially appeal to two groups.
Prospective math and computer science majors in the class will appreciate the lab topics because they are all on inherently interesting algorithms: elegant mathematical machines chosen as assignments because the TAs and I ourselves wanted to take them apart and put them back together to see how they worked. Science and economics majors will appreciate that the lab assignments address core issues that they'll tackle in their own disciplines, such as large data sets, modeling complex systems, and optimization problems. They'll also value learning C/C++ and Python, two of the most popular programming languages, particularly for scientific computing.
CS136 is not a first computer science course; an introduction to programming or computer science course heavily features tutorials guiding students down good paths for solving specific problems and hides a lot of confusing detail from them. That's a good way to start, but computer science isn't about a single right answer or following a tutorial.
Comptuer Science about interesting details, design, and creativity within a rigorous and quantitative discipline. This course embraces detail to give a holistic understanding of programming and the machine model, and is about choice: choice of data structure, choice of program design, choice of resource allocation, and choice of programming language.
The most important skills that you should bring to the course to then develop further are:
- Quantitative Reasoning: Analyze of the emergent properties of systems. How fast? How large?
- Attention to Detail: Read and construct good algorithms, specifications, and programs. These are like poetry, in that every character carries weight. CS136 is about thought and "fine print," not broad strokes.
- Programming: Design, implement, and maintain mathematical machines
Textbooks
There are three books for the course, which will collectively cost about $30:
- Kernighan and Ritchie, The C Programming Language 2nd Edition, 1988 (Amazon: $17 rent, $39 used, $49 new)
- Lutz, Python Pocket Reference (Amazon: $9 new; Water St.: $15)
- Bailey, Python Structures: Structured Python for the Principled Programmer, 2015
The first two books are reference materials for two of the programming languages that we'll be using. You could get by using only free online materials instead of buying these. However, with the books you'll get trustworthy information right away and save time. They also provide high-quality supplemental material on the languages to what is taught in class, which is particularly helpful if you have trouble adjusting to the new syntax.
The third book covers the computer science algorithms aspect of the course. I'm intentionally starting the lab assignments in programming language that is different than the one used by the textbook. One goal of this cource is to help you think about computer science independent of a particular language or machine. If you can translate programs from the book's example language into the lab assignment language, then you probably understand both the computer science and programming language portion of the assignment.
How to Read
Do not read a CS or math book like a novel. You have to be an active participant to read college level mathematical material. For many people (including me), it is generally hard and a bit unpleasant, although there is joy in finally grasping something. Read some text, pause, ask yourself a question about it, and try and figure out the next step on your own. If you're not quite sure what is going on, don't keep reading--backtrack and read that section again. Maybe out loud. When there are inline exercises or ones at the end of the chapter, actually do (many of) them. Be prepared to skip around, look up material in the index, and re-read critical passages many, many times.
I often have to stop and write a little program to test the ideas from the text or fully grasp them. I expect that you will too. Don't look at equations or code lisings and just say, "yes, that looks about right." Ensure that you could reproduce them. Run through the execution of algorithms by hand as if you were a computer.
Also, use a debugger or a lot of output statements to trace the execution of the program on the same data and see how it aligns with what you did by hand. I often skim an entire chapter to get a sense for how much material it will cover and to know which concepts are going to become really important, and then read it carefully through a few times while implementing the really confusing or clever parts.
Remember that you have separate Python and C books, which you'll need in order to implement the ideas in your data structures book. Plan to flip through those a lot, and use the table of contents and index. I don't assign sections from those books because they are for reference. Part of what you're learning is how to find resources and use them to solve a computer science task, and that means taking responsibility for this piece of the reading on your own. Don't shy away from online resources either, but remember to take them with a hefty grain of skepticism. Just because someone said something on the web doesn't mean that it is correct, or a good idea.
I could have assigned a single textbook and a single programming language for the course and gone through them linearly. That would have been easier for you. But I'm not trying to make it easy for you. I believe that you learn the most by adapting and actively engaging the material and having a lot of pieces to figure out on your own, just as in real life. I've curated the content and constructed a series of exercises designed to have you encounter the rough spots and your role is to power through them.
I made the lab assignment documents short so that you can read them completely and study them in detail. Read the specifications closely and literally, as a lawyer would. That's how I'll evaluate them, and how future teachers, graduate advisors, managers, and clients will evaluate your work.
The specification is the contract between me and you for the assignment. In many cases, your evaluation may hinge on a technicality of the specification that was very significant to me and the TAs but seems insignificant to you. By the end of the course you'll have learned the significant phrases for a CS specification, but early on you have to assume that everything has hidden significance. You can choose whether to read the informal advice section. That is me speaking to you in plain language about how to get the most out of the material.
Grading
Your final grade is based on:
Time Limit Component Topic Submission Deadline Weight 5 hrs Projects* Programming Mon Night Turnin Folder 0.45 20 min Quizzes Theory & Reading Tues Night Glow 0.30 - Prelab Homeworks Design Wed Afternoon Turnin Folder 0.15 4.5 hrs Engagement** Questions, comments, attendance Lab and Lecture 0.10
* Lowest non-pair programming grade dropped, "midterm" and "final" project count as two projects
** Each unexcused absence from lab will drop your final grade by 0.5/4.0You will receive in-person feedback from me and the TAs during lab and in office hours, writen comments on your assignments, and numerical grades. Although only a single numerical grade will appear on your transcript, I consider the other forms more valuable for increasing your skills. Of course, the best way to improve your numerical grade is to heed the qualitative feedback and seek more when it is insufficient.
A program's source code is a form of written communication between two humans that happens to also be evaluable by a machine. In CS136, I evaluate your programs based on many factors, including:
- Satisfaction of the specification
- Effective communication (via abstraction mechanisms, formatting, names, comments, spelling, and grammar)
- Design (algorithms, extensibility, flexibility, features)
- Elegance (conciseness and suitability of the solution to the problem at hand)
If you have discovered errors in your solution but do not have sufficient time to fix them, document what you know. What is the symptom? How did you approach correcting it? Where in your program do you believe the problem lies? You will receive almost as much credit for knowing the flaws in your solution and document an effective approach to them as you would for a fully correct solution.
For team projects, both team members usually receive the same grade because part of the point of such projects is to learn to balance workload and to take responsibility for shared work.
When determining final grades, I rank students according to numerical weighted average. I then group students within the ranking to assign letter grades. In rare cases when the ranking does not match my holistic evaluation of a student's ability or engagement with the material, I adjust that student's final grade slightly (this is responsible and standard practice, I'm just making it explicit).
There is no pre-set threshold for a given letter grade, although I calibrate assignment grading so that it is usually very close to 60 = 1.0 = D, 70 = 2.0 = C, 80 = 3.0 = B, 90 = 4.0 = A, with modified grades mapping accordingly. A+ final grades are very rare in CS136 and are typicaly granted only to students who have received 100% on every assignment.
Note that all work in this course has a time limit except for the "homework" lab preparation exercises. My goal with these limits is to prevent you from overworking by holding yourself to an unreasonably high standard for perfection. I don't want you to spend 20 hours on an assignment that you're struggling with. If you're having trouble, then I want you to stop after a few hours, talk to me or a TA about your approach, and spend the rest of your week on other courses and activities.
These limits are based on the average durations required for students in previous semesters to reach B+ quality solutions. You should rarely feel time pressure. If you're structuring your workflow well, then at the point where you hit the limit there is likely little that more time would do to help you improve your grade substantially.
Time spent in office hours, preparing for a laboratory assignment before your scheduled lab, or during your scheduled lab does not count towards the time limit for a lab. It is therefore greatly to your advantage to prepare well for assignments. For example, I recommend that you read each assignment and sketch your solution in comments or pseudocode before the lab. The "homework" assignments are a thinly-veiled, pass/fail attempt to encourage you to do so for points as well as an implicit advantage.
As you look around the lab, you may occasionally see your peers apparently working in a calm and collected fashion as you feel adrift and panic rises. Don't psych yourself out. The calm student next to you is often working just as hard as you but is putting on a good show. Everyone's going to struggle at some point (the "advanced" sections of the assignments are there to ensure that even the strongest students are challenged!) Use this course to become comfortable working in an environment where you are at first unsure of how to proceed, but continue moving forward on the strength of your confidence in your ability to learn and solve problems. You wouldn't be at Williams or in this course if you weren't capable of mastering new computer science skills.
Submission and Attendance Policy
Because of the way that we administer and evaluate assignments, you may only submit programs in this course by the cs136-turnin folder. Out of fairness to your peers and practicality, hardcopy, e-mail, USB disks, and other attempts to submit work by other means without prior agreement will be ignored. This is because we cannot validate the submission time and because doing so requires manual intervention into the system for tracking work which detracts from the time available for evaluating everyone's work.
Likewise, it is extremely important that you follow the specification exactly on file and directory naming conventions. It is solely your responsibility to ensure that work is submitted on time, even in the face of potential computer configuration errors, operator error, and power outages (working right up to the deadline is very risky--plan ahead and submit partial solutions as you go).
This policy is strict about submission conventions and times even in the face of computer downtime because that is an important part of the workflow of professional programmers. Pay attention to specifications and work defensively and conservatively--it will serve you well beyond this course as well.
If something does go wrong with the submission process, e-mail mcguire@cs.williams.edu and mary@cs.williams.edu immediately but do not attempt to submit your work in an alternative way, and do not work past the deadline.
Assignments are due at or before their deadlines. Late work is not accepted. This keeps you from overextending yourself and means that everyone in the class has the same amount of time. If you know that you'll be on a trip, then just start and turn in your work early. Don't worry if you have an emergency or bad week--that's why I drop the lowest lab grade. If you have two emergencies, then please let me know what is going on and talk to the dean's office for support. There will be no individual extensions granted, and class-wide extensions are extremely rare.
Submission deadlines are according to the CS department's Mac server, which may have a clock that differs by a few minutes from other clocks at Williams.
Attendance in lab session is mandatory. Missing a lab session without an excuse approved by a dean or prior arrangement with the professor will reduce your final grade in the course by 0.5 (out of 4.0).
Honor Code
The Honor Code allows professors to create assignments and teaching materials based solely on pedagogial goals, without the need to compromise them to reduce opportunities for unethical behavior. This is a great advantage for Williams students and embodies the mutual trust between teachers and students on our campus.
Students are bound by the CS Department Honor Code and Usage Policy and the College Honor Code. In short: all work should be your own (or that of your assigned project group). Remember, failing an assignment may lower your grade, but cheating will ruin your career! Ask Prof. McGuire if you are unsure about how the Honor Code applies to this course or a specific assignment.
The following is the specific policy for how the Honor Code applies to CS136 assignments. Most students understand the standards of conduct intuitively by the time they've reached CS136, however from experience with the unfortunate exceptional cases I explain it in some detail here to minimize the potential for confusion.
Your work should be your own and performed in accordance with the CS department usage policies. Work by others should be properly identified and attributed via citation. When working on an assigned pair or team project, "you" refers collectively to all members of your team, with whom you are expected to collaborate closely and openly. You may not use deception, including lies by omission, to gain an advantage in the course.
Some implications of this policy:
- You may (and are encouraged to) publicly discuss with anyone language syntax, tools, general programming strategies and algorithms, and code that does not directly satisfy this assignment
- You may share test routines and data sets with other students
- You may not allow any other student in the class to see your implementation code
- You may not look at, possess, or attempt to gain access to the solution code of any other student in the class, a TA, or the instructor
- Attempting to submit work after a deadline as if it were completed beforehand, and offering fraudulent excuses in an attempt to obtain an extension or explain missing a deadline are academically deceptive behaviors that violate the Honor Code
- Soliciting a solution to an assignment from any source (including other professors and in online venues) is a violation of the Honor Code
- You may (and are encouraged to) deconstruct materials such as data sets, programming libraries, and scripts provided to you unless doing so is expressly prohibited by the assignment
- Taking more time than permitted by a time-restricted assignment (factoring in any additional time that you are granted by the dean's office and have notified the professor of) is a violation of the Honor Code
- Using restricted library functions in an assignment (e.g., using the std::string class to complete the String assignment) in a way that is evident in your submitted solution is not a violation of the honor code
- Including parts of a solution to an assignment found on the Internet or in a book with a correct citation is not an Honor Code violation
Generalizing from the last two examples, violating the rules of an assignment in a way that is not academically dishonest is not an Honor Code violation, although it will result in a lower grade on that assignment.
Immediately notify the professor if you are concerned that you may have accidentally violated the Honor Code, to avoid misunderstanding.
Beware that the Honor Code compels professors to report potential Honor Code violations to the Honor and Discipline Committee regardless of the professor's beliefs or feelings about the situation, and that the professor is not permitted to notify the student directly or discuss the case with the student.
Disabilities and Resources
Students with disabilities of any kind who may need disability-related classroom accommodations for this course are encouraged to contact Dr. Joyce Foster at 597-4672. Also, students experiencing mental or physical health challenges that are significantly affecting their academic work are encouraged to contact me and to speak with a dean. The deans can be reached at 597-4171.
The image at the top of this website is derived from a screenshot of the Tomb Raider Underworld video game published by Eidos Interactive