CS 42: Principles and Practice of Computer Science
Syllabus, Fall 2011

Is This Course for You?

If you are unsure about your placement in this class, please speak with Prof. Stone ASAP. It is possible to switch to CS 5 Black (which meets at the same time on the same days), but the earlier you switch to the right section for you, the better.

Overall Course Aims and Objectives

• Aim 1: To give you a broad understanding of computer science as a discipline. Specifically:
  • Program in many different programming language styles and languages, e.g, Rex, Python, Prolog, JFlap
  • Construct finite state automata and Turing machines, show what they can and cannot compute, and understand the significance of these results
  • Describe how different programming styles lead to different approaches to problems.
• Aim 2: To help you design and develop programs to solve more sophisticated problems than those previously encountered. Specifically:
  • Understand the difference between data structures and abstract data types (ADTs) and build several data structures for a variety of ADTs
  • Design, implement, and test user-interactive programs in various languages.

Course Mission Statement

• Ways of thinking about solving computational problems
• Ways of creating computational solutions to problems relevant to a variety of disciplines
• How to think abstractly about problems, and how problems are solved by development of appropriate abstractions
• Views of information and data, how these are structured in the computer, and how they are manipulated to achieve desired ends
• Structural disciplines appropriate to computational problem solving, such as decomposition into sub-parts, iteration, and recursion
• Basics of logic applied to computation
• How to create a specification for a program and establish its correctness
• How programming languages are chosen for suitability to solving particular problem classes
• How layers of abstraction are developed in both hardware and software to make computational problem solving intellectually manageable

Logistics

• Class Times and Place: Tuesdays and Thursdays, Dartmouth (Modular Classroom) South
• Course Homepage: http://www.cs.hmc.edu/cs42
• Instructor: Chris Stone
  Office: Olin 1251
  Phone: 909 607-8975
  Email: stone@cs.hmc.edu (the best way to contact me individually; but see below!)
  Office Hours:Monday, Tuesday, Wednesday 4&ndash5pm; Thursdays 3–4pm, or by appointment
  
• Graders/Tutors (aka “Grutors”) There are several grutors for this course whose mission in life (at least some of the time) is to help convey the wonder of CS 42! They will be holding regular hours in the Beckman CS labs in B102 and B105 (the link below has specific hours). They will also be grading your assignments (but not the exams). A complete schedule of tutoring hours can be found here.
• Help via E-mail: You can (and should) send short, homework-related questions to cs42help@cs.hmc.edu. Both the intructor and the grutors will get your message, and so this is the fastest way to get your questions answered. For more extensive help, please see Prof. Stone or a grutor in person. In particular, for help with the submission system (a forgotten password, for example), contact Prof. Stone. For help with the computing system you're using (your machine or one of the lab machines) your best bet is to seek out one of the many Mudders who know the system well!

Switching Courses

Attendance

If you are ill and cannot attend or an emergency arises, please contact Dean Jacobsen before the missed class if at all possible (or very shortly thereafter if not). If you need to miss class for any other reason, you must get permission in advance from the Associate Dean for Academic Affairs (Dean Jacobsen).

Your first two unexcused absences will have no impact on your grade.  For each of your next three unexcused absences, you will lose 10% of your participation grade.  Your sixth unexcused absence will result in a grade of "No Credit". There are no exceptions to this rule.

Optional Text

However, some students might find the following textbooks useful:

• The CS 5 textbook: CS for Scientists and Engineers by Christine Alvarado, Zachary Dodds, Geoff Kuenning and Ran Libeskind-Hadas
• The optional CS 60 textbook:  Computer Science: Abstraction to Implementation by Robert M. Keller. 

Assignments and Exams

You have three late days or "CS 42 Euros" that you may use at your discretion -- you don't need to tell us in advance. A late day allows you to turn in an assignment 24 hours late with no penalty. You may not use two late days on the same assignment. Late homeworks will not be accepted once these late days have been used. In cases of illness or emergency, you should contact Dean Jacobsen to arrange an extension and have him contact me.

In addition to weekly assignments, there will be two midterm exams and a final exam. See the exam schedule page for up-to-date details.

Attendance

Optional Text

However, some students might find the following textbooks useful:

• The CS 5 textbook: CS for Scientists and Engineers by Christine Alvarado, Zachary Dodds, Geoff Kuenning and Ran Libeskind-Hadas
• The optional CS 60 textbook:  Computer Science: Abstraction to Implementation by Robert M. Keller

Grading

This course is considered a first-year course, and is graded on a Pass/No Pass scale. There are three graded components of this course, weighted as follows:

• Assignments (~100 points each × 12 = 1200 points)
• Exams (2×150 point midterms + 1×300 point final = 600 points)
• Participation (200 points total)

(define (score p)
 (cond
 ((>= p 0.97) "High Pass")
 ((>= p 0.70) "Pass")
 (else "We hope not to have to use this option"))

IMPORTANT GRADING NOTES:

• You must independently pass each component of this course to pass the course as a whole. This means:
• A score below 70% on the homework or the exams will result in a grade of “No Credit”
• More than 5 unexcused absences will result in a grade of “No Credit”


• Borderline grades may be moved up or down based on exemplary or particularly poor performance in some aspect of the course.


• We will use guidelines in grading the programming assignments which will be approximately as follows:
  • 70% of the points will be given for a program that meets the exact specifications of the assignment.
  • 30% of the points will be given for good design, style, testing and robustness. Good design and style means, for example, that your program is divided into small logical functions, new classes are defined and used when appropriate, and the program uses efficient algorithms and data structures. Your program should also be robust in the sense that it handles minor aberrations in user input, though extensive input error-checking is not required unless so specified. Finally, the code must be readable and well-documented.
  We will try to give you very clear feedback indicating what could be done to improve the program. If the feedback isn't entirely clear to you, please talk to Prof. Stone or one of the grutors.


• Participation includes good-faith effort on our in-class “quizzes.” Actual results on those quizzes do not matter at all. Attendance also counts towards participation, as does answering questions (or asking good questions).

Collaboration Policy/Pair Programming

• Both members of the pair must be at the same computer together while collaborating. One student will be the "driver" who controls the keyboard and mouse. The other is the "navigator" who observes, asks questions, suggests solutinos, and thinks about sligthly longer-term strategies. It is not permissible for one member of the pair to work on the code while his or her partner is not there participating actively.
• The person typing at the keyboard must be swapped every 30 minutes. Please be vigilant about this.
• You must work with the same partner for the entire assignment. You may switch partners between assignments. (Sometimes this is required. See below.)
• Only one partner needs to submit a pair programming file. That file should include a comment on top of each submitted file that indicates that this was a pair effort and should give the names of both members of the pair. This will help ensure that the graders know where all of the files are.
• Periodically, we will announce that its time to switch partners (sort of like in square dancing!). At that point, you may choose a different partner but may never go back to program with an earlier partner.
• To “learn the do's and don'ts” of pair programming and to see pairs in action, view this entertaining video about pair programming from North Carolina State University: An Introduction to Pair Programming for Students

Now that you know the rules, here are some pair programming guidelines to help you get the most out of your experience:

• You should try to choose a partner whose skill level is similar to your own. We realize this may be difficult to judge, but we've found that partnerships are most productive when pairs work at about the same level.
• If you and your partner have different experience levels, it is extremely important that the more experienced partner does not simply take over. Both experienced and inexperienced students will need to draw on their reasoning and problem solving skills. A more experienced partner may sometimes feel frustrated or slowed down by a less experienced partner, but the experienced partner still benefits from the teamwork in many ways. The less experienced partner's requests for clarification often uncover flaws in an approach or solution; the exercise of providing a clear explanation solidifies and deepens the explainer's own understanding and the teamwork and communication skills they gain have great value in both the academic realm and the job market.
  “My partner had never coded anything before so I was able to teach him a little bit about how it worked. The teaching bit helped me a lot with understanding the labs and passing the exams.” —a CS student

  The less experienced partner may feel that questions hold the other partner back or that there is no benefit to participating actively, but pair programming studies show that paired work is consistently better than work the stronger partner does alone. It is each partner's job to understand the whole task; that means asking questions when necessary and answering them when possible.

• Pair programming is shown to help, not hinder, your successful completion of this course, so we strongly encourage you to use it. It is important that you understand the processes and expectations up front so you can gain the most benefit. If you are unsure of any of the aspects of pair programming and how it is implemented in the course, see Prof. Stone right away.

Whether you are programming individually or as a pair, there are a few important rules regarding cooperation. You are always welcome and encouraged to discuss approaches to solving homework problems with any classmate, the grutors, or Prof. Stone. You may not share any written/typed materials of any kind. In particular, you may not send or receive code that is related to this course by e-mail, on the web, from another person's file or printout, or in any other form. This rule applies to two people working as a pair with the following exception: The code may be sent by e-mail from one member of the pair to the other after the code is submitted for grading. Moreover, the pair may print out a copy of their code to work on together.

You may wonder if it is permitted to help a classmate (other than your partner if you are pair programming) debug a program and, in the process, look at their code. This is permitted, assuming that it is done with the intent of helping your classmate learn, and not with intent of gleaning code that might be used in your own program, or with the intent of simply giving away answers. Use your good judgement here. If you're not sure about what's appropriate, please talk to Prof. Stone.

All conduct in this course should be conducted in accordance with the Harvey Mudd Honor Code. If you are an off-campus student and unfamiliar with the honor code, please talk to Prof. Stone.

Students with Disabilities

The college is committed to complying with the Rehabilitation Act of 1973 and the Americans with Disabilities Act of 1990 by providing reasonable accommodations for students who are disabled. Students requiring specific accommodations for a physical, psychological, medical or learning disability should contact the Dean of Students at 909 621-8125. The Dean will review your concerns and determine, with you, what accommodations are necessary and appropriate. All information and documentation of disability is confidential.