August 2022 | ||||||
---|---|---|---|---|---|---|
U | M | T | W | R | F | S |
1 | 2 | 3 | 4 | 5 | 6 | |
7 | 8 | 9 | 10 | 11 | 12 | 13 |
14 | 15 | 16 | 17 | 18 | 19 | 20 |
21 | 22 | 23 | 24 | 25 | 26 | 27 |
28 | 29 | 30 | 31 | |||
Labs: | M, | between 9:05am and 6:35pm ET | (varies by section) |
---|---|---|---|
Lectures: | TR, | 08:35-9:55am ET | (McConomy) |
or | TR, | 10:10-11:30 ET | (DH 2210) |
Recitations: | F, | between 9:05am and 6:35pm ET | (varies by section) |
Click on a class day to go to that particular lecture or recitation. Due dates for homeworks are set in bold. The due date of the next homework blinks.
Test Percentage learn. obj | Wr1 1.5% 1-3,11 | Pg1 2.5% 1,12 | Wr2 1.5% 1-3 | Pg2 2.5% 12,15,16 | Wr3 1.5% 1,2,4,12 | Pg3 2.5% 1,12-16 | Wr4 1.5% 1-4,21,27 | Pg4 2.5% 1,18,17 | Wr5 1.25% 6-10,15-17 | Midterm1 12.5% 1-8 | Wr6 1.5% 6-8,12,17 | Pg5 2.5% 5,12,27 | Wr7 1.5% 9,17,24,27 | Pg6 2.5% 10 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Posted | 29 Aug | 1 Sep | 5 Sep | 8 Sep | 12 Sep | 15 Sep | 19 Sep | 22 Sep | 26 Sep | Thu 6 Oct | 3 Oct | 6 Oct | 10 Oct | 13 Oct |
Due (9pm) | Mon 5 Sep | Thu 8 Sep | Mon 12 Sep | Thu 15 Sep | Mon 19 Sep | Thu 22 Sep | Mon 26 Sep | Thu 29 Sep | Mon 3 Oct | Mon 10 Oct | Thu 13 Oct | Mon 24 Oct | Thu 27 Oct | |
Corrected | 6 Sep | 10 Sep | 13 Sep | 17 Sep | 20 Sep | 24 Sep | 27 Sep | 1 Oct | 4 Oct | 10 Oct | 11 Oct | 15 Oct | 25 Oct | 29 Oct |
Test Percentage learn. obj | Wr8 1.5% 12,24,27 | Pg7 2.5% 8,10-18 | Wr9 1.5% 9,10,25-27 | Pg8 2.5% 9,12-18 | Wr10 1.25% 2,13,25,27 | Midterm2 12.5% 1-8 | Pg9 2.5% 10,15-20 | Wr11 1.5% 18-20 | Pg10 2.5% 5,15-20 | Wr12 1.5% 19,20 | Pg11 2.5% 5,15-20 | Final 25% 1-27 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Posted | 24 Oct | 27 Oct | 31 Oct | 3 Nov | 7 Nov | Tue 15 Nov | 14 Nov | 14 Nov | 21 Nov | 28 Nov | 21 Nov | Fri 16 Dec (5:30-8:30pm) |
Due (9pm) | Mon 31 Oct | Thu 3 Nov | Mon 7 Nov | Thu 10 Nov | Mon 14 Nov | Mon 21 Nov | Mon 28 Nov | Thu 1 Dec | Mon 5 Dec | Thu 8 Dec | ||
Corrected | 1 Nov | 5 Nov | 8 Nov | 15 Nov | 15 Nov | 19 Nov | 23 Nov | 29 Nov | 3 Dec | 6 Dec | 10 Dec | 23 Dec |
Office hour rules:
If you are experiencing COVID symptoms (e.g., fever, cough, nausea) or came in close contact of somebody who tested positive:
If you test positive for COVID, email the instructors right away so that we can make resources available while you are in quarantine.
2022 | 2021 | 2020 | 2019 | 2018 | 2017 | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Fall | F22 | F21 | F20 | F19 | F18 | F17 | F16 | F15 | F14 | F13 | F12 | F11 | F10 |
Summer | M22 | N21 | N20 | N19 | N18 | N17 | N16 | M15 | M14 | M13 | M12 | M11 | |
Spring | S22 | S21 | S20 | S19 | S18 | S17 | S16 | S15 | S14 | S13 | S12 | S11 |
Unix | Emacs | Vim |
---|---|---|
|
We strongly advise students not to use late days in the first half of the course. Later assignments are more challenging and many courses have lots of deliverables towards the end of the semester. The second half of the semester is where late days are most needed.
Nearly all situations that make you run late on an assignment homework can be avoided with proper planning — often just starting early. Here are some examples:
All regrade requests must be received within 5 days of the work being handed back on Gradescope or Autolab, which we will announce in a Diderot post.
What follows is a rough guide to how course grades will be established, not a precise formula — we will fine-tune cutoffs and other details as we see fit after the end of the course. This is meant to help you set expectations and take action if your trajectory in the class does not take you to the grade you are hoping for (see also the Grades tab on this page). So, here's a rough, very rough heuristics about the correlation between final grades and total scores:
The value of your degree depends on the academic integrity of yourself and your peers in each of your classes. It is expected that, unless otherwise instructed, the work you submit as your own is your own work and not someone else’s work or a collaboration between yourself and other(s).
You are allowed to clarify the writeup of homework assignments with other students, but not work on a solution or brainstorm answers with them.
You are welcome to freely discuss course material (lecture notes/slides, practice exams, lab handouts, recitation handouts, blank writtens and programming writeups) as well as to review graded assignments with students taking the course in the current semester. You may give or receive help with computer systems, compilers, debuggers, profilers, or other facilities (as long as answers and/or code are never visible).
You are not allowed to refer to solutions and/or code written by past or present students, or found on the web, not even to "double-check" your own solution. You may not post code from this course publicly (e.g., to Bitbucket or GitHub).
You are not allowed to use any materials from previous iterations of the course, including your own. You may not discuss or receive help on homework assignments with students who have previously taken the course (excluding current TAs).
We will be using the MOSS system to detect software plagiarism. Whenever a programming assignment is similar to a homework from a previous course edition, we will run MOSS on all submissions from that edition as well. All solutions from the Web are also in MOSS - you should assume that if you were able to find it, we have already found them.
If you are uncertain whether your actions will violate this policy, please reach out to a member of course staff to ask beforehand.
Please read the University Policy on Academic Integrity carefully to understand the penalties associated with academic dishonesty at Carnegie Mellon. In this class, cheating/copying/plagiarism means copying all or part of a program or homework solution from another student or unauthorized source such as the Internet, having someone else do a homework or take an exam for you, knowingly or by negligence giving such information to another student, reusing answers or solutions from previous editions of the course, or giving or receiving unauthorized information during an examination. In general, each solution you submit (written assignment, programming assignment, midterm or final exam) must be your own work. In the event that you use information written by others in your solution, you must cite the source of this information (and receive prior permission if unsure whether this is permitted). It is considered cheating to compare complete or partial answers, copy or adapt others' solutions, or sit near another person who is taking (or has taken) the same course and complete the assignment together. Working on code together, showing code to another student and looking at another student's code are considered cheating. If you need help debugging, go to office hours or make a post on Diderot. It is also considered cheating for a repeating student to reuse one's solutions from a previous semester, or any instructor-provided sample solution. It is a violation of this policy to hand in work for other students.
Your course instructor reserves the right to determine an appropriate penalty based on the violation of academic dishonesty that occurs. Penalties are severe: a typical violation of the university policy results in the student failing this course, but may go all the way to expulsion from Carnegie Mellon University. If you have any questions about this policy and any work you are doing in the course, please feel free to contact the instructors for help.
For this class, we are conducting research on student outcomes. This research will involve your work in this course. You will not be asked to do anything above and beyond the normal learning activities and assignments that are part of this course. You are free not to participate in this research, and your participation will have no influence on your grade for this course or your academic career at CMU. If you do not wish to participate or if you are under 18 years of age, please send an email to Chad Hershock (hershock@cmu.edu) with your name and course number. Participants will not receive any compensation. The data collected as part of this research may include student grades. All analyses of data from participants’ coursework will be conducted after the course is over and final grades are submitted. The Eberly Center may provide support on this research project regarding data analysis and interpretation. The Eberly Center for Teaching Excellence & Educational Innovation is located on the CMU-Pittsburgh Campus and its mission is to support the professional development of all CMU instructors regarding teaching and learning. To minimize the risk of breach of confidentiality, the Eberly Center will never have access to data from this course containing your personal identifiers. All data will be analyzed in de-identified form and presented in the aggregate, without any personal identifiers. If you have questions pertaining to your rights as a research participant, or to report concerns to this study, please contact Chad Hershock (hershock@cmu.edu).
Do your best to maintain a healthy lifestyle this semester by eating well, exercising, avoiding drugs and alcohol, getting enough sleep and taking some time to relax. This will help you achieve your goals and cope with stress.
All of us benefit from support during times of struggle. You are not alone. There are many helpful resources available on campus and an important part of the college experience is learning how to ask for help. Asking for support sooner rather than later is often helpful.
If you or anyone you know experiences any academic stress, difficult life events, or feelings like anxiety or depression, we strongly encourage you to seek support. Counseling and Psychological Services (CaPS) is here to help: call 412-268-2922 and visit their website. Consider reaching out to a friend, faculty or family member you trust for help getting connected to the support that can help.
If you or someone you know is feeling suicidal or in danger of self-harm, call someone immediately, day or night:
![]() ![]() Office hours:
| ![]() ![]() Office hours:
|
Mon 29 Aug Lab 1 |
Setup
This lab practices using Linux and running the C0 interpreter and compiler.
|
Tue 30 Aug Lecture 0 |
Welcome and Course Introduction
We outline the course, its goals, and talk about various administrative
issues.
Readings:
A mysterious function ...
We examine a program we know nothing about, making hypotheses about
what it is supposed to do. We notice that this function has no
meaningful output for some inputs, which leads us to restricting its
valid inputs using preconditions. We use a similar mechanism,
postconditions, to describe the value it returns. Along the way, we
get acquainted to C0 and its support for checking pre- and
post-conditions. We then notice that this function doesn't return
the expected outputs even for some valid inputs ...
Concepts:
|
Thu 1 Sep Lecture 1 |
Contracts
Contracts are program annotations that spell out what the code is
supposed to do. They are the key to connecting algorithmic ideas to
their implementation as a program. In this lecture, we illustrate
the use of contracts by means of a simple C0 program. As we do so,
we learn to verify loop invariants — an important type of
contract, we see how contracts can help us write correct code, and
we get acquainted with C0's automated support to validating contracts.
Concepts:
|
Fri 2 Sep Recitation 1 |
C0 Basics
This recitation reviews elementary C0 constructs and practices
reasoning about code.
|
Mon 5 Sep |
No class (Labor Day)
|
Tue 6 Sep Lecture 2 |
Ints
In this lecture, we explore how number representation interplays
with the the ability to write effective contracts. We focus on
integers and see how the binary representation called two's
complement supports the laws of modular arithmetic, which C0
embraces. We also examine operations that allow exploiting the bit
pattern of a binary number to achieve compact representations of
other entities of interest, and to manipulate them.
|
Thu 8 Sep Lecture 3 |
Arrays
In this lecture, we examine arrays as our first composite data
structure, i.e., a data construction designed to hold multiple
values, together with operations to access them. Accessing an array
element outside of its range is undefined — it is a safety
violation — and we see how to use contracts, in particular
loop invariants, to ensure the safety of array accesses in a
program. Arrays are stored in memory, which means that they are
manipulated through an address. This raises the possibility of
aliasing, a notorious source of bugs in carelessly written programs.
|
Fri 9 Sep Recitation 2 |
A Bit about Bytes
This recitation practices base conversion and writing code
that manipulates bits.
|
Mon 12 Sep Lab 3 |
Loopty-Loopty Loop
This lab practices testing and timing running code to estimate its complexity.
|
Tue 13 Sep Lecture 4 |
Searching Arrays
We practice reasoning about arrays by implementing a function that
searches whether an array contains a given value — this is the
gateway to a whole class of useful operations. We notice that this
function returns its result more quickly when the array is sorted.
We write a specialized variant that assumes that the array is
sorted, and show that it works correctly by reasoning about array
bounds. The first (simpler but less efficient) version acts as a
specification for the the second (slightly more complex but often
faster). Using the specification in the contract for the
implementation is a standard technique to help writing correct code.
|
Thu 15 Sep Lecture 5 |
Big-O
We examine big-O notation as a mathematical tool to describe the
running time of algorithms, especially for the purpose of comparing
two algorithms that solve the same problem. As a case study, we use
the problem of sorting an array, and for now a single sorting
algorithm, selection sort. As we implement selection sort, we see
that starting with contracts gives us high confidence that the
resulting code will work correctly. Along the way, we develop a
useful library of functions about sorted arrays to be used in
contracts.
|
Fri 16 Sep Recitation 3 |
Function Family Reunion
This recitation practices understanding and using big-O notation.
|
Mon 19 Sep Lab 4 |
TA Training
This lab practices testing code.
|
Tue 20 Sep Lecture 6 |
Binary search
When searching for a value in a sorted array, examining the middle
element allows us to discard half of the array in the worst case.
The resulting algorithm, binary search, has logarithmic complexity
which is much better than linear search (which is linear).
Achieving a correct imperative implementation can be tricky however,
and we use once more contracts as a mechanism to reach this goal.
|
Thu 22 Sep Lecture 7 |
Quicksort
We use the key idea underlying binary search to implement two sorting
algorithms with better complexity than selection sort. We examine
one of them, quicksort, in detail, again using contracts to achieve
a correct implementation, this time a recursive implementation. We
observe that the asymptotic complexity of quicksort depends on the
the value of a quantity the algorithm use (the pivot) and discuss
ways to reduce the chances of making a bad choice for it. We
conclude by examining another sorting algorithm, mergesort, which is
immune from this issue.
|
Fri 23 Sep Recitation 4 |
A Strange Sort of Proof
This recitation reviews proving the correctness of functions.
|
Mon 26 Sep Lab 5 |
Fibonacci has Bad Internet
This lab practices working with algorithms with radically different
complexity for the same problem.
|
Tue 27 Sep Lecture 8 |
Libraries
Arrays are homogeneous collections, where all components have the
same type. structs enable building heterogeneous
collections, that allow combining components of different types.
They are key to building pervasively used data structures. In C0,
a struct resides in allocated memory and is accessed
through an address, which brings up a new form of safety violation:
the NULL pointer violation. We extend the language of
contracts to reason about pointers.
Now that we have a two ways to build complex collections, we start exploring the idea of segregating the definition of a data structure and the operations that manipulate it into a library. Code that uses this data structure only needs to be aware of the type, operations and invariants of the data structure, not the way they are implemented. This is the basis of a form of modular programming called abstract data types, in which client code uses a data structure exclusively through an interface without being aware of the underlying implementation.
|
Thu 29 Sep Lecture 9 |
Stacks and Queues
In this lecture, we examine the interface of two fundamental data
structures, stacks and queues. We practice using the exported
functions to write client code that implements operations of stacks
and queues that are not provided by the interface. By relying only
of the interface functions and their contracts, we can write code
that is correct for any implementation of stacks and queues.
|
Fri 30 Sep Recitation 5 |
A queue_t Interface
This recitation practices programming against an interface.
|
Mon 3 Oct Lab 6 |
Misclaculation
This lab practices understanding postfix notation and stack-based machines.
|
Tue 4 Oct Lecture 10 |
Linked Lists
We observe that we can implement array-like collections using
a struct that packages each element with a pointer to the
next element. This idea underlies linked lists, a data structure
pervasively used in computer science. Writing correct code about
linked lists is however tricky as we often rely on stricter
invariants than natively supported, in particular the absence of
cycles. We develop code to be used in contracts to check for common
such properties. We then use linked lists to write code that
implements the stack interface, and similarly for queues. We could
have given an array-based implementation, and we note the advantages
and drawbacks of each choice.
|
Thu 6 Oct Midterm 1 |
Midterm 1
|
Fri 7 Oct Recitation 6 |
Link it All Together
This recitation practices working with linked lists.
|
Mon 10 Oct Lab 7 |
List(en) Up!
This lab practices working with linked lists.
|
Tue 11 Oct Lecture 11 |
Unbounded Arrays
When implementing a data structure for a homogeneous collection,
using an array has the advantage that each element can be accessed
in constant time, but the drawback that we must fix the number of
elements a priori. Linked lists can have arbitrary length but
access takes linear time. Can we have the best of both worlds?
Unbounded arrays rely on an array to store the data, but double it
when we run out of place for new elements. The effect is that
adding an element can be either very cheap or very expensive
depending on how full the array is. However, a series of insertions
will appear as if each one of them takes constant time on average.
Showing that this is the case requires a technique called amortized
analysis, which we explore at length in this lecture.
|
Thu 13 Oct Lecture 12 |
Hashing
Associative arrays are data structures that allow efficiently
retrieving a value on the basis of a key: arrays are the special
case where valid indices into the array are the only possible keys.
One popular way to implement associative arrays is to use a hash
table, which computes an array index out of each key and uses that
index to find the associated value. However, multiple keys can map
to the same index, something called a collision. We discuss several
approaches to dealing with collisions, focusing on one called separate
chaining. The cost of access depends on the contents of the hash
table. While a worst case analysis is useful, it is not typically
representative of normal usage. We compute the average case
complexity of an access relative to a few simple parameters of the
hash table.
|
Fri 14 Oct Recitation 7 |
Array Disarray
This recitation practices coding to achieve amortized cost.
|
Mon 17 Oct |
No class (Fall break)
|
Tue 18 Oct | |
Thu 20 Oct | |
Fri 21 Oct |
Mon 24 Oct Lab 8 |
Hash this!
This lab practices understanding collisions in hash functions.
|
Tue 25 Oct Lecture 13 |
Hash Dictionaries
In this lecture, we look at the interface of modular code at greater
depth, using hash functions as a case study. In this and many
example, it is useful for the client to fill in some parameters used
by the library code so that it delivers the functionalities needed
by the client. One such parameter is the type of some quantities
the library acts upon, keys in our case. It is also often the case
that the client wants to provide some of the operations used by the
library, here how to hash a key and how to compare elements. This
is a first step towards making libraries generic, so that they
implement the general functionalities of a data structure but let
the client choose specific details.
|
Thu 27 Oct Lecture 14 |
Generic Data Structures
In large (and not-so-large) systems, it is common to make multiple
uses of the same library, each instantiated with different
parameters. This is not possible in C0, however. To achieve this
goal, we look at a richer language, called C1. C1 provides two new
features: generic pointers and function pointers. Generic
pointers, void * in C, allow a same library type to be
instantiated with different client types at once, which gives us a
way to use a hash table library with both integers and strings as
keys for example. Function pointers allow a library to be
instantiated with different client-supplied operations in the same
program.
|
Fri 28 Oct |
No class (Tartan Day)
|
Mon 7 Nov Lab 10 |
This One's a Treet
This lab practices using dictionaries to avoid recomputing values.
|
Tue 8 Nov Lecture 17 |
Introduction to C
With this lecture, we are moving from the safety of C0 to the more
open-ended world of C. We introduce some basic concepts of C, in
particular the C preprocessor and how macros written in this
language can simulate some of the effects of C0's contracts. We
also see how to compile C programs and discuss separate compilation.
We conclude with C's primitives to manage memory, in particular the
need to free allocated memory to prevent memory leaks.
|
Thu 10 Nov Lecture 18 |
C's Memory Model
C provides a very flexible view of memory, which allows writing
potentially dangerous code unless one is fully aware of the
consequences of one's decision. This lecture is about building this
awareness. We see that, while C overlays an organization on the
monolithic block of memory the operating systems assigns to a
running program, it also provides primitives that allow violating
this organization. We focus on two such primitives, pointer
arithmetic and address-of. While some uses are legitimate, others
are not. C's approach to many non-legitimate operations is to
declare them undefined, which means that what happens when a program
engages in them is decided by the specific implementation of the C
compiler in use.
|
Fri 11 Nov Recitation 10 |
From C1 to Shining C
This recitation practices the main novelties of C.
|
Fri 16 Dec (5:30-8:30pm) final |
Final
|
2022 Iliano Cervesato |