February 2021 | ||||||
---|---|---|---|---|---|---|
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 | ||||||
Labs: | M, | between 8:20am and 6:40pm EST | (Zoom) |
---|---|---|---|
Lectures: | TR, | 08:20-9:40am EST | (Zoom) |
or | TR, | 10:40-noon EST | (Zoom) |
Recitations: | F, | between 8:20am and 6:40pm EST | (Zoom/in-person) |
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.2% 1-3,11 | Pg1 2.5% 1,12 | Wr2 1.2% 1-3 | Pg2 2.5% 12,15,16 | Wr3 1.2% 1,2,4,12 | Pg3 2.5% 1,12-16 | Wr4 1.2% 1-4,21,27 | Pg4 2.5% 1,18,17 | Wr5 0.9% 6-10,15-17 | Midterm1 12.5% 1-8 | Wr6 1.2% 6-8,12,17 | Pg5 2.5% 5,12,27 | Wr7 1.2% 9,17,24,27 | Pg6 2.5% 10 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Posted | 1 Feb | 5 Feb | 8 Feb | 12 Feb | 15 Feb | 19 Feb | 22 Feb | 26 Feb | 1 Mar | Thu 11 Mar | 7 Mar | 9 Mar | 14 Mar | 16 Mar |
Due (9pm) | Mon 8 Feb | Fri 12 Feb | Mon 15 Feb | Fri 19 Feb | Mon 22 Feb | Fri 26 Feb | Mon 1 Mar | Fri 5 Mar | Mon 8 Mar | Sun 14 Mar | Tue 16 Mar | Sun 21 Mar | Tue 23 Mar | |
Corrected | 9 Feb | 14 Feb | 16 Feb | 21 Feb | 23 Feb | 28 Feb | 2 Mar | 7 Mar | 9 Mar | 15 Mar | 16 Mar | 18 Mar | 23 Mar | 25 Mar |
Test Percentage learn. obj | Wr8 1.2% 12,24,27 | Pg7 2.5% 1,12-18 | Wr9 0.9% 9,10,25-27 | Midterm2 12.5% 1-8 | Pg8 2.5% 8,10-18 | Wr10 1.2% 2,13,25,27 | Pg9 2.5% 9,12-18 | Wr11 1.2% 18-20 | Pg10 2.5% 10,15-20 | Wr12 1.2% 19,20 | Pg11 2.5% 5,15-20 | Wr13 1.2% 5,20,27 | Pg12 2.5% 5,15-20 | Final 25% 1-27 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Posted | 21 Mar | 9 Mar | 28 Mar | Thu 8 Apr | 30 Mar | 6 Apr | 8 Apr | 12 Apr | 16 Apr | 19 Apr | 23 Apr | 26 Apr | 23 Apr | Mon 10 May (8am) |
Due (9pm) | Sun 28 Mar | Tue 30 Mar | Sun 4 Apr | Fri 9 Apr | Sun 11 Apr | Wed 14 Apr | Mon 19 Apr | Fri 23 Apr | Mon 26 Apr | Fri 30 Apr | Mon 3 May | Fri 7 May | ||
Corrected | 30 Mar | 1 Apr | 6 Apr | 12 Apr | 11 Apr | 13 Apr | 19 Apr | 20 Apr | 25 Apr | 27 Apr | 2 May | 4 May | 9 May | 17 May |
Office hour rules:
This semester, 15-122 will be delivered remotely except that students in Pittsburgh will be able to participate in Friday recitations in person. Specifically,
2020 | 2019 | 2018 | 2017 | 2016 | 2015 | 2014 | 2013 | 2012 | 2011 | 2010 | |
---|---|---|---|---|---|---|---|---|---|---|---|
Fall | F'20 | F'19 | F'18 | F'17 | F'16 | F'15 | F'14 | F'13 | F'12 | F'11 | F'10 |
Summer | N'20 | N'19 | N'18 | N'17 | N'16 | M'15 | M'14 | M'13 | M'12 | S'11 | |
Spring | S'20 | S'19 | S'18 | S'17 | S'16 | S'15 | S'14 | S'13 | S'12 | S'11 |
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 verbally discuss homework assignments writeups with other students (i.e., through Zoom audio calls or through safe, socially-distanced in-person discussions) but not answers to them. However, in order to ensure that the work you submit is still your own, we insist that you adhere to the policies described below.
When collaborating on homework assignments, you may:
When collaborating on homework assignments, you may not:
Note that when discussing lectures/lecture notes or studying for exams, there are no restrictions on collaboration with other current students.
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, your instructor is conducting research on student learning. This research will involve surveys and course work. 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, please send an email to Chad Hershock (hershock@cmu.edu). Please include your name and course number. Participants will not receive any compensation. The data collected as part of this research will 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:
Mon 1 Feb Lab 1 |
Setup
This lab practices using Linux and running the C0 interpreter and compiler.
|
Tue 2 Feb 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 4 Feb 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 5 Feb Recitation 1 |
C0 Basics
This recitation reviews elementary C0 constructs and practices
reasoning about code.
|
Mon 8 Feb Lab 2 |
What's the point?
This lab practices point-to reasoning.
|
Tue 9 Feb 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 11 Feb 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 12 Feb Recitation 2 |
A Bit about Bytes
This recitation practices base conversion and writing code
that manipulates bits.
|
Mon 15 Feb Lab 3 |
Loopty-Loopty Loop
This lab practices testing and timing running code to estimate its complexity.
|
Tue 16 Feb 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 18 Feb 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 19 Feb Recitation 3 |
Function Family Reunion
This recitation practices understanding and using big-O notation.
|
Mon 22 Feb Lab 4 |
TA Training
This lab practices testing code.
|
Tue 23 Feb 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 25 Feb 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 26 Feb Recitation 4 |
A Strange Sort of Proof
This recitation reviews proving the correctness of functions.
|
Mon 1 Mar Lab 5 |
Fibonacci has Bad Internet
This lab practices working with algorithms with radically different
complexity for the same problem.
|
Tue 2 Mar Lecture 8 |
Data structures
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 4 Mar 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 5 Mar Recitation 5 |
A queue_t Interface
This recitation practices programming against an interface.
|
Mon 8 Mar Lab 6 |
Misclaculation
This lab practices understanding postfix notation and stack-based machines.
|
Tue 9 Mar 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 11 Mar Midterm 1 |
Midterm 1
|
Fri 12 Mar Recitation 6 |
Link it All Together
This recitation practices working with linked lists.
|
Mon 15 Mar Lab 7 |
List(en) Up!
This lab practices working with linked lists.
|
Tue 16 Mar 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 18 Mar Lecture 12 |
Hash Tables
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 19 Mar |
No class (mid-semester break)
|
Mon 22 Mar Lab 8 |
Hash this!
This lab practices understanding collisions in hash functions.
|
Tue 23 Mar 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 25 Mar 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 26 Mar Recitation 8 |
Array Disarray
This recitation practices coding to achieve amortized cost.
|
Mon 12 Apr Lab 11 |
Once you C1 you C them all
This lab practices using translating C0 code to C and managing
memory leaks.
|
Tue 13 Apr 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.
|
Thu 15 Apr |
No class (Carnival)
|
Fri 16 Apr |
No class (Carnival)
|
Mon 10 May (8am) final |
Final
|
2021 Iliano Cervesato |