August 2024 | ||||||
---|---|---|---|---|---|---|
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 |
Lectures: | TR, | 09:30-10:50 ET | (DH 2210) |
---|---|---|---|
or | TR, | 11:00-12:20 ET | (DH 2315) |
Check-ins: | T, | 7:00pm or 7:45pm ET | (DH 2210 or DH 2315 — varies by section) |
Precepts: | F, | between 9:00am and 5:50pm 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.
Homework Percentage Focus learn. obj | PP0 0% Lec.0 1-3,11 | PP1 0.5% Lec.1-2 1-3 | PP2 0.5% Lec.3-4 1,2,4,12 | PP3 0.5% Lec.5-6 1-4,21,27 | PP4 0.5% Lec.7-8 6-10,15-17 | PP5 0.5% Lec.9-10 6-8,12,17 | PP6 0.5% Lec.11-12 9,17,24,27 | PP7 0.5% Lec.13-14 12,24,27 | PP8 0.5% Lec.15-16 9,10,25-27 | PP9 0.5% Lec.17-18 2,13,25,27 | PP10 0.5% Lec.19-20 18-20 | PP11 0.5% Lec.21-22 19,20 | PP12 0.5% Lec.23-24 5,20,27 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Posted | 22 Aug | 29 Aug | 5 Sep | 12 Sep | 19 Sep | 26 Sep | 3 Oct | 10 Oct | 24 Oct | 31 Oct | 7 Nov | 14 Nov | 21 Nov |
Due (6pm) | Thu 29 Aug | Thu 5 Sep | Thu 12 Sep | Thu 19 Sep | Thu 26 Sep | Thu 3 Oct | Thu 10 Oct | Thu 24 Oct | Thu 31 Oct | Thu 7 Nov | Thu 14 Nov | Thu 21 Nov | Mon 2 Dec |
Corrected | 30 Aug | 6 Sep | 13 Sep | 20 Sep | 27 Sep | 4 Oct | 11 Oct | 25 Oct | 1 Nov | 8 Nov | 15 Nov | 22 Nov | 3 Dec |
Homework Percentage Focus learn. obj | PG1 2.5% C0 1,12 | PG2 2.5% ints 12,15,16 | PG3 2.5% arrays 1,12-16 | PG4 2.5% sorting 1,18,17 | PG5 2.5% stacks 5,12,27 | PG6 1.6% lists 10 | PG7 3.4% lists 1,12-18 | PG8 2.5% trees 8,10-18 | PG9 2.5% C 9,12-18 | PG10 2.5% C 10,15-20 | PG11 2.5% c0vm 5,15-20 | PG12 2.5% c0vm 5,15-20 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Posted | 1 Sep | 8 Sep | 15 Sep | 22 Sep | 29 Sep | 6 Oct | 6 Oct | 27 Oct | 3 Nov | 10 Nov | 17 Nov | 17 Nov |
Due (9pm) | Sun 8 Sep | Sun 15 Sep | Sun 22 Sep | Sun 29 Sep | Sun 6 Oct | Sun 20 Oct | Sun 27 Oct | Sun 3 Nov | Sun 10 Nov | Sun 17 Nov | Sun 24 Nov | Thu 5 Dec |
Corrected | 10 Sep | 17 Sep | 24 Sep | 1 Oct | 8 Oct | 22 Oct | 29 Oct | 5 Nov | 15 Nov | 19 Nov | 26 Nov | 7 Dec |
Test Percentage Focus learn. obj | CH1 3% Lec.0-1 1-3 | CH2 3% Lec.1-2 1,2,4,12 | CH3 3% Lec.3-4 1-4,21,27 | CH4 3% Lec.5-6 6-10,15-17 | CH5 3% Lec.7-8 6-8,12,17 | CH6 3% Lec.9-10 9,17,24,27 | CH7 3% Lec.11-12 12,24,27 | CH8 3% Lec.13-14 9,10,25-27 | CH9 3% Lec.15-16 2,13,25,27 | CH10 3% Lec.17-18 18-20 | CH11 3% Lec.19-20 19,20 | CH12 3% Lec.21-22 5,20,27 | CH13 -- Lec.0-24 5,20,27 |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Date | Tue 3 Sep | Tue 10 Sep | Tue 17 Sep | Tue 24 Sep | Tue 1 Oct | Tue 8 Oct | Tue 22 Oct | Tue 29 Oct | Tue 5 Nov | Tue 12 Nov | Tue 19 Nov | Tue 26 Nov | Tue 3 Dec |
Corrected | 5 Sep | 12 Sep | 19 Sep | 26 Sep | 3 Oct | 10 Oct | 24 Oct | 31 Oct | 7 Nov | 14 Nov | 21 Nov | 2 Dec | 5 Dec |
Test Percentage learn. obj | Final 25% 1-27 |
---|---|
Date | Mon 9 Dec (1-4pm) |
Corrected | 16 Dec |
Office hour rules:
2024 | '23 | '22 | '21 | '20 | '19 | '18 | '17 | '16 | '15 | '14 | '13 | '12 | '11 | '10 | |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Fall | F24 | F23 | F22 | F21 | F20 | F19 | F18 | F17 | F16 | F15 | F14 | F13 | F12 | F11 | F10 |
Summer | N24 | N23 | M22 | N21 | N20 | N19 | N18 | N17 | N16 | M15 | M14 | M13 | M12 | S11 | |
Spring | S24 | S23 | S22 | S21 | S20 | S19 | S18 | S17 | S16 | S15 | S14 | S13 | S12 | S11 |
valgrind
tool to
test proper memory management.
You are welcome to use any programming environment that suits you to write your programming assignments. However, all programming homework will be graded by running them on a Unix system using Autolab — you may want to make sure they work on Andrew Unix. Popular environment choices include VSCode, emacs and vim, but you should use what works for you: an environment that allows you to write code quickly and efficiently. Here are some useful links:
vimtutor
at the terminalEach precept is worth 2.5 points given out based on effort and rough correctness.
There will be one activity worth 0.5
points during or after each lecture. Use
the activities page to test your
configuration and do the current activity (when there is one).
The precepts and activities grade is calculated based on the bucket
system: All you need to earn the full 3% grade for this
portion of the course is to accumulate 30
points overall. There are many more points than that
for grabs, so no sweat if you miss a precept or a lecture. Do the
math: the course has
Your assignments and exams are evaluated on the basis of:
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 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 Ed 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 or something else's work or a collaboration between yourself and other(s).
Many students who copy code or other work do so in the heat of the moment and regret their actions later on, when more clear-headed. You may contact the instructors by 2pm the day after a deadline and ask to delete your submission for an assignment, no questions asked. Deleted submissions are not considered when running academic integrity checks and receive a grade of 0. Contact us before we contact you.Practice problems are intended to be collaborative but submissions are individual.
Specifically, you are welcome to work on any aspects of a practice problem with other students. However, in order to ensure that the work you submit reflects your learning, we insist that you adhere to a whiteboard policy regarding these discussions: you are not allowed to take any notes, files, pictures or other records away from the discussion, nor shall you memorize answers. For example, you may work on practice problems at the whiteboard with another student, but then you must erase the whiteboard, stop discussing the problem, wait some time (15 minutes is a safe heuristic) and write up your solution individually. We take your ability to recreate the solution independently as proof that you understand the work that you submit.
Programming assignments are strictly individual.
You may ask other students clarifications on the writeup (e.g., "What does this sentence mean?", "Can you explain this notation?") but you may not discusses approaches to solving any aspect of the assignment (e.g., "How would you do this?", "Can you walk me through an example?").
You are not allowed to refer to solutions and/or code written by past or present students, ChatGPT or other AI-based tools, 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).
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 it.
Check-ins and the final exam are strictly individual.
You are welcome to freely discuss course material (lecture notes/slides, practice exams, precept handouts), as well as to review graded assignments or check-ins 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 use any materials from previous iterations of the course, including your own. You may not discuss or receive any help on homework assignments with students who have previously taken the course (excluding current TAs).
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 obtaining all or part of a program or homework solution from another student or tool, 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 (practice problem, programming assignment, check-in 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. For programming assignments, working on code together, showing code to another student and looking at another student's code are considered cheating. If you need help debugging, make a post on Ed or go to office hours. 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 instructors reserve the right to determine an appropriate penalty based on the violation of academic dishonesty that occurs. Penalties go from negative points in an assignmnent 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.
If you took this course in full or in part in a past semester, we ask that you delete all your previous work so you won't look at it. In particular, copying or referencing one's own solutions from an earlier semester is a violation of the academic integrity policy and will be handled as such. Doing so may save time close to a deadline but it will not have the effect of learning the material, which will be a serious handicap in exams and in follow-up courses.
Active participation by you and other students will ensure that everyone has the best learning experience in this class. We may take participation in lecture and precepts into account when setting final grades. Fire safety rules require that we never exceed the stated capacity of a classroom. For this reason, we require that you attend the lecture, check-in slot, and precept you are registered for.
As research on learning shows, unexpected noises and movement automatically divert and capture people's attention, which means you are affecting everyone's learning experience if your cell phone, laptop, etc, makes noise or is visually distracting during class. Therefore, please silence all mobile devices during class. You may use laptops for note-taking only, but please do so from the back of the classroom. Do not work on assignments for this or any other class while attending lecture or precept.
If you wish to request an accommodation due to a documented disability, please inform your instructor and contact Disability Resources as soon as possible (access@andrew.cmu.edu). Once your accommodation has been approved, you will be able to request extra-time for each exam separately by filling this form a week in advance.
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:
The Student Academic Success Center is providing various services aimed at helping students master the contents of this course. These optional services are free and voluntary. They are led by trained personnel who have successfully completed the course. Leaders are not members of the course staff. These services are are designed to supplement — not replace — class lectures and precepts. They do not cover homework.
We ask that students do not seek help from upperclassmates who have successfully completed the course. Doing so often leads to violations of the academic integrity policy of the course. In particular, upper-classmates found to violate this policy will be reported and will incur a grade penalty.
while
and for
),void
pointers and casts between pointer types,void
and function pointers,make
, gcc
, and valgrind
.![]() ![]() Office hours:
| ![]() ![]() Office hours:
|
Tue 27 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 29 Aug 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 30 Aug precept 1 |
Title
Brief description.
|
Tue 3 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 5 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 6 Sep precept 2 |
Title
Brief description.
|
Tue 10 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 12 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 13 Sep precept 3 |
Title
Brief description.
|
Tue 17 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 19 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 20 Sep precept 4 |
Title
Brief description.
|
Tue 24 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 26 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 27 Sep precept 5 |
Title
Brief description.
|
Tue 1 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 3 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.
|
Fri 4 Oct precept 6 |
Title
Brief description.
|
Tue 8 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.
|
Thu 10 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.
|
Fri 11 Oct precept 7 |
Title
Brief description.
|
Tue 15 Oct |
No class (Fall break)
|
Thu 17 Oct | |
Fri 18 Oct |
Tue 22 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.
|
Thu 24 Oct Lecture 15 |
Binary Search Trees
We discuss trees as an approach to representing a collection, and
binary search trees as an effective data structure to store and
operate on sorted data. In particular, most operations on balanced
binary search trees have a logarithm cost on the number of contained
data. Binary search trees can however become unbalanced over time.
|
Fri 25 Oct precept 8 |
Title
Brief description.
|
Tue 5 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.
|
Thu 7 Nov Lecture 19 |
Types in C
In this lecture, we examine how C implements basic types, and what
we as programmers need to be aware of as we use them. We begin with
strings, that in C are just arrays of characters with
the null character playing a special role. A variety of
number types are available in C, but some of their characteristics
are not defined by the language, most notably their size and what
happens in case of overflow. As a consequence, different compilers
make different choices, which complicates writing code that will
work on generic hardware.
|
Fri 8 Nov precept 10 |
Title
Brief description.
|
Mon 9 Dec (1-4pm) final |
Final
|
2024 Iliano Cervesato |