Winter 2019
Design and implementation of hash tables, general trees, search trees, balanced trees and graphs. Comparison of sorting algorithms. Demonstration of the use of data structures in various applications. Evaluation of the best data structure for a particular task. Programming is required in implementation of concepts.
At the end of this course, students will have:
The goal of this course is to round out your knowledge of the fundamental data structures and algorithms that comprise the basic toolbox of a computer scientist or software developer. Along the way, we’ll encounter and develop the following big ideas that permeate many more advanced subfields of computer science:
By the end of this course, students should be able to:
The following texts may serve as useful references, but are not required:
Grades will be calculated as a weighted average of scores on the following course components, each of which is described in more detail below:
In this class we will follow the notational convention that a range of integers denoted a..b describes the range beginning at (and including) a up to but not including b. For example, 1..4 describes the range including 1, 2, and 3 but not 4. The floor function truncates the decimal part of a floating-point value (that is, rounds down to the nearest smaller integer). Final letter grades will be assigned as follows.
| floor(%) | Grade |
|---|---|
| ≥ 90 | A range |
| 80..90 | B range |
| 70..80 | C range |
| 60..70 | D range |
| 0..60 | F |
The calculated raw percentages may be curved nonlinearly at the instructor’s discretion, but any such curve used will not reduce anyone’s grade. “+” or “-” cutoffs will be decided at the instructor’s discretion. Students who demonstrate mastery of the material will get grades in the A range, and it is my goal to give as many A’s as possible.
Four programming assignments will be given to provide practice implementing the major concepts covered in the course:
The midterm exam will be in-class on Friday, February 15th and will test material covered through Monday, February 11th.
The final exam is scheduled for Monday, March 18th from 10:30am to 12:30pm in our usual lecture classroom, AW 203. The final exam will be cumulative, but more emphasis will be placed on material covered since the midterm. Per the University Academic Policies, a student who fails to take a final examination without making prior arrangements acceptable to the instructor receives a failing grade for the course.
Quizzes will be given in the first 10 minutes of some lectures to provide an opportunity to check in on your understanding of recently covered topics. Any topics covered in prior lectures may be on quizzes. No make-up quizzes will be given, but your lowest quiz grade will be dropped.
Other in-class assessment activities may be used, and will given binary grades based on whether a reasonable effort was made. These low-stakes assessments provide both students and instructor with quick and actionable feedback about student learning, allowing both to make adjustments to teaching and learning strategies. For example, students may be asked to answer sporadic poll questions or hand in a short answer to a question at the end of class.
Labs will provide hands-on experience with auxiliary topics as well as time for work on programming assignments with the TA available to answer questions. To get full credit for a lab activity, you must both attend lab and hand in the deliverable by the deadline, which will typically be 11:59pm on Tuesday the week following after lab period. If you have a legitimate reason for missing lab, contact me ahead of time. Attending a lab section other than the one you are registered for requires permission of the instructor. Barring case-by-case exceptions, if you miss lab but submit the deliverable on time you will receive half credit (i.e., your score will be multiplied by 0.5). No late labs will be accepted.
We will use Canvas for announcements, assignment invitation links, grades, and some other logistics. Lab and assignment writeups, lecture slides, readings, etc. will all be linked from the course webpage. Numerical grades will be entered into Canvas to track your overall score in the course, but feedback on your assignments will be provided via Gradescope (quizzes and exams) or Git (assignments and labs), as described in the sections below.
Quizzes and exams will be graded and returned to you via an online tool called GradeScope. You will receive an email when the first graded quiz is released inviting you to log into an account that has been created for you and set a password. Thereafter, you will access your graded assignments and exams by logging into your account on http://www.gradescope.com.
Labs and assignments will be completed using Git repositories hosted by GitHub and orchestrated by GitHub classroom. You will receive an invitation link to create a repository for each assignment, complete the assignment in a local copy of the repo, and submit by pushing your final changes to GitHub. To grade your assignments (and in some cases, labs) we will create a new branch in your repository called grading. This branch will contain the output of any automated tests we run, as well as a file (usually called grade.txt) containing detailed feedback on your score and any deductions you may have received. To access the grading branch, fetch the branches from the remote repo on github then check out the grading branch as follows:
git fetch
git checkout gradingThis tentative schedule is subject to change without notice. Slides, assignments, readings, etc. will be posted here throughout the quarter.
| Date | Topics | Lab | Assignments | References |
|---|---|---|---|---|
| 1/9 | Intro, insertion and selection sort slides | 1: Git, Gradle | CLRS 2.1, RS 13.3 | |
| 1/11 | Insertion and selection, intro runtime analysis slides | RS 13.4, CLRS 2.2 - 2.3.1 | ||
| 1/14 | Recursion, Mergesort slides | Tutorial: Method execution, RS 12.3 RS 13.4 | ||
| 1/16 | Mergesort, Quicksort slides | 2: Testing | A1 out | CLRS 7.1 |
| 1/18 | Stability, Comparison Sorting, Radix Sort slides | CLRS 8.2-8.4 | ||
| 1/21 | No class (MLK day) | |||
| 1/23 | Radix sort; Runtime analysis slides | 3: Debugging | RS 13.4, CLRS 2.2 - 2.3.1 | |
| 1/25 | Runtime analysis slides | RS 13.4, CLRS 2.2 - 2.3.1 | ||
| 1/28 | ADTs, Trees, Traversals, Recursion on trees slides | A1 due | RS 17.1-17.3 | |
| 1/30 | Binary Search Trees slides, notes | 4: Recursion | CLRS 12.1-3 | |
| 2/1 | BST removal slides | A2 out | CLRS 12.3 | |
| 2/4 | ❄ Snow Day ❄ | |||
| 2/6 | Generics, Set ADT, AVL I: Rotations slides | 5: AList | CLRS 13.2 | |
| 2/8 | AVL Trees II: Rebalancing slides, video recording | Eric Alexander’s AVL Tree Notes | ||
| 2/11 | ||||
| 2/13 | ❄ Snow Day ❄ AVL Insert Examples | 6: Canceled | ||
| 2/15 | Heaps I preview, slides | RS 18.2; CLRS 6.1-6.3 | ||
| 2/18 | No class: President’s day | A2 Due (2/19) | ||
| 2/20 | Heaps II slides | 7: Midterm review | RS 18.1, CLRS 11.1-3 | |
| 2/22 | Midterm Exam | |||
| 2/25 | Hashing I slides, worksheet | A3 out | ||
| 2/27 | A3 Overview, Hashing II slides | 8: HashMaps | ||
| 3/1 | Hashing III slides | |||
| 3/4 | Intro graphs; Graph traversals slides (1) slides (2) | CLRS 22.1-3 | ||
| 3/6 | Traversals slides; Dijkstra’s Shortest Paths I slides | 9: Connected components | A3 due, A4 out | CLRS 24.3 |
| 3/8 | Dijkstra’s Shortest Paths II slides; algorithm; graphs | CLRS 24.4-5 | ||
| 3/11 | Dijkstra: Proof slides | |||
| 3/13 | Misc: Graph Planarity, In-Place Sorting, Heapsort, Review slides, exercises | 10: review | A4 due | |
| 3/15 | Review slides exercises | |||
| 3/18 | Final Exam: Monday, 3/18 10:30AM - 12:30 PM |
It is expected that everyone will promote a friendly, supportive, and respectful environment in the classroom, labs, and project groups. Everyone’s participation will be equally welcomed and valued.
Strictly speaking, attendance at lectures is not mandatory and not explicitly tracked. That said, no credit will be given for missed quizzes and other in-class assessment activities.
You have three “slip days” that you may use at your discretion to submit programming assignments late. Slip days apply only to programming assignments and can not be applied to any other deadline. You may use slip days one at a time or together - for example, you might submit each of three assignments one day late, or submit one assignment three days late. A slip day moves the deadline by exactly 24 hours from the original deadline; if you go beyond this, you will need to use a second slip day, if available.
After your slip days are exhausted, a penalty of 10% * floor(hours_late/24 + 1) - that is, 10% per day late.
To submit your work late, you must push your changes via git (as usual) then send me an email stating that you have submitted the assignment late. The timestamp of the email, which must be sent after your final changes are pushed to git, will be used as the submission time. It is your responsibility to keep track of your slip day balance - no exceptions will be made for accounting errors on your part.
Your programs will be graded on correctness, clarity, and efficiency (in that order).
A correct program is one that always produces the correct output for a given input. Also, a correct program does not produce unintended side-effects. The most effective way to ensure that your program is correct is to test, test, test. Test each component as you introduce it; once you are confident that a component works you can use it in other routines. Try to break your program in testing, and if you succeed, locate the bug and fix it. The better you test your program, the more likely it is to be correct - the more likely it is to be correct, the more likely you’ll earn a good score. Most of your grade will depend on the correctness of your code.
The easier it is to read and maintain your code, the easier it is to locate and remove bugs. Your program should be well organized, appropriately commented, and easy to maintain. To have a well-organized program, design your program thoughtfully and modularly. Think before you code: hacking away blindly leads to ugly, difficult-to-read code. If you do hack away, producing a functional but ugly wall of code, try to clean it up a bit. Make sure that your cleaning does not introduce new bugs.
As for comments, please follow these simple guidelines proposed by Emeritus Professor Osborne:
Your programs should be asymptotically efficient, e.g. checking graph reflexivity should be O(N), insertion into a balanced tree should be O(lgN), etc. Do not optimize your code beyond the asymptotic level, as such tweaks are often at the expense of clarity, correctness, or both.
Individual programming assignments are to be completed independently. Students are welcome to discuss assignments with each other on a conceptual level, but each student should be writing their code independently and without direct help from fellow students. Sharing your code with others or looking at someone else’s code is an explicit violation of this collaboration policy. To make sure you are collaborating appropriately, follow these two rules:
Automated tools will be used to check your code for plagiarism at the push of a button. They are not fooled by tricks such as changing variable naming and whitespace: in fact, hiding plagiarism is harder than doing the assignment.
For pair programming assignments, the above policy applies to any collaborations with people outside your group. In addition, the following pair programming best practices must be followed:
Please review the University policies outlined at http://syllabi.wwu.edu regarding: