Fall 2018
Please note that the syllabus and course website are still being updated as the quarter begins.
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, November 2nd and will test material covered through Monday, October 29th. If you have an unavoidable conflict and cannot attend class the day of the midterm, you must email the instructor by Saturday, October 6th.
The final exam is scheduled for Tuesday, December 11th from 3:30pm to 5:30pm in our usual lecture room, AW 304. 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. If you have a legitimate reason for missing lab, contact me ahead of time. Attending a lab section other than the one you ar 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.
This tentative schedule is subject to change without notice. Slides, assignments, readings, etc. will be posted here throughout the quarter.
| Date | Topics | Lab | Assignments | References |
|---|---|---|---|---|
| 9/26 | Intro, ADT, runtime analysis. slides | RS 11.1 | ||
| 9/28 | Runtime analysis continued slides | RS 13.2 | ||
| 10/1 | Loop invariants, InsertionSort, SelectionSort slides | 1: Git | CLRS 2.1-2.2, RS 13.3 | |
| 10/3 | Recursion slides | Sort out | Tutorial: Method execution, RS 12.3 | |
| 10/5 | Mergesort slides | RS 13.4, CLRS 2.3.1 | ||
| 10/8 | Quicksort, in-place, stability slides, homework | 2: Testing | CLRS 7.1 | |
| 10/10 | Radix sort (vs comparison sorts) slides | CLRS 8.3 | ||
| 10/12 | Intro to trees, Tree traversals, Recursion on trees slides | RS 17.1-17.3 | ||
| 10/15 | Binary Search Trees slides | 3: Recursion | Sort due | CLRS 12.1-3 |
| 10/17 | BST remove, BST rotations slides | CLRS 12.3, 13.2 | ||
| 10/19 | AVL Trees I slides | Eric Alexander’s AVL Tree Notes | ||
| 10/22 | AVL Trees II slides | 4: Start A2 | Tree out | |
| 10/24 | Set, Priority Queue ADT slides | |||
| 10/26 | Heaps I slides | RS 18.2; CLRS 6.1-6.3 | ||
| 10/29 | Heaps II slides | 5: Midterm Review | Tree due | |
| 10/31 | Inheritance, Generics, Exceptions, Review slides, code | |||
| 11/2 | Midterm Exam study guide wiki | |||
| 11/5 | Hashing I slides | 6: AList | RS 18.1, CLRS 11.1-3 | |
| 11/7 | Hashing II slides | |||
| 11/9 | A3 Overview, Intro Graphs slides | Hash/heap out | CLRS 22.1 | |
| 11/12 | Veterans Day - No class | 7: Work on A3 | ||
| 11/14 | More graphs, toposort slides | CLRS 22.4 | ||
| 11/16 | Graph traversals slides | CLRS 22.2-3 | ||
| 11/19 | Dijkstra’s Shortest Paths I slides, algorithm, graphs | No Lab | Hash/heap due | CLRS 24.3 |
| 11/21 | No class - Thanksgiving break | |||
| 11/23 | No class - Thanksgiving break | |||
| 11/26 | Dijkstra’s Shortest Paths II slides | 8: Work on A4 | Graph out | CLRS 24.4-5 |
| 11/28 | Minimum Spanning Trees I slides | CLRS 23.1-2 | ||
| 11/30 | Minimum Spanning Trees II slides, prim.zip | |||
| 12/3 | Review: Runtime Analysis slides, prim.pdf, questions.pdf | 9: Connected Components | Graph due (Sunday 12/2) | |
| 12/5 | Recurrences, Graph cuts and applications; greaest hits, slides | |||
| 12/7 | Course evals; Coding Trees; slides, interview questions, huffman.zip | CLRS 16.3 | ||
| 12/11 | Final Exam: Tuesday, 11th 3:30 - 5:30 PM; study guide wiki |
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:
