Spring 2020
Lectures will be delivered synchronously via Zoom at the scheduled time: MWF 9:00am–9:50am. You will be asked to participate using Socrative (further instructions will be provided) and in break-out groups for peer instruction. Although you should attend the synchronous lectures if at all possible, there will be no penalty for missing the synchronous lectures, and recordings will be made available promptly.
Privacy notice: Zoom lectures will be recorded and posted for viewing only by members of this class. By joining the live lectures you consent to being a part of this recording. To avoid appearing in lecture recordings, you may take any of the following actions:
Labs will be self-paced. Lab assignments will be released on Monday of each week and due Sunday night. Synchronous TA help will be available on Thursday during the regularly scheduled lab periods:
Weekly quizzes will be given on Fridays. They will be in some online format (TBD), with a time limit but available to be taken anytime during the day after lecture. Exams will be similar, though your ability to take them on your own schedule may be somewhat less flexible in the interest of maintaining academic honesty.
Office hours will be held by me and the TAs over Zoom. For security purposes, the Zoom links and passwords are only available on the Syllabus page of Canvas.
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:
In response to the move to online instruction, the University has temporarily implemented Pass/No Pass grading by default for Spring quarter. You have the option to request a letter grade instead. To request a letter grade, you must respond to the Canvas Quiz titled SURVEY: OPT IN for Letter Grade. The deadline for making this request is Friday, June 5th.
There are two important things to know about this policy as pertains to this course:
Please note the following implications of #1, above:
Scores will be tracked as usual throughout the quarter, and your most up-to-date score will be visible on Canvas. Your choice of whether to opt-in for a letter grade only affects whether your final score is translated into a letter grade or into a P or NP grade.
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 (this is consistent with Python’s range function). 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. The boundary between Pass and No Pass is 70.0. 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 delivered online on or about Friday, May 15th. Precise date and format are TBD.
The final exam is scheduled for Wednesday, June 10th from 10:30am - 12:30pm. The format of the final will match the midterm, except that the duration is longer. 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.
Weekly quizzes will be given on Fridays, to be taken any time after class on Friday. They will be in some online format (TBD) and will have a time limit.
Weekly 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 during the lab period. To get full credit for a lab activity you must submit the deliverable by the deadline, which will typically be 10:00pm on Sunday of the week the lab is assigned.
The Schedule section of this page will be updated as the quarter progresses with topics, links to lecture slides and recordings, readings, and links to assignment and lab handouts. I suggest bookmarking this page; if you forget the URL and need to find your way back here, you can use link on the Syllabus page in Canvas.
Access to the Computer Science labs is available using SSH. Here is a set of instructions for how to login, as well as some tips for how to set things up to make this process easy going forward:
https://gitlab.cs.wwu.edu/cs-support/public/-/wikis/Remotely_Accessing_Resource
To make it possible to use graphical applications on the lab computers using X forwarding, there are some instructions on this page: https://gitlab.cs.wwu.edu/cs-support/public/-/wikis/SSH
Also see the Lab 1 handout for a few more tips and links. I encourage you to use mosh or et and possibly tmux to handle slow/interrupted/resumable connections. See here for some helpful advice on this. If you’re using tmux, keep in mind that the tmux server runs on a particular computer, so you’ll want to use labs-last to get back to the computer with your session running. Now is as good a time as any to learn a command-line text editor like vim, emacs, or nano, so you aren’t dependent on a GUI editor to get your work done. You are welcome to work on your own personal hardware, but we can’t promise to provide technical support for everyone’s individual configuration.
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) Github Classroom automatically creates a feedback branch in your repository and a pull request to merge all the commits you’ve made to master into the feedback branch. This allows us to use Github’s code review tools to give you feedback directly in your repository. To access your feedback, go to your repository on github.com click “Pull Requests” from among the tabs across the top, then click “Feedback” in the list on that page. You should see a log of comments and feedback, including line-by-line comments if we’ve left any.
For the assignments with unit tests, we’ve also set up Github Classroom to automatically run your code on those tests every time you push your changes to github. This is a form of continuous integration testing, which is a fancy term for “run all the tests every time you change anything”. You’ll probably get emails telling you the outcome of the checks (which will only be successful if you pass all tests); I think there’s a way to unsubscribe from them, or you can use an email filter to keep your inbox clutter to a minimum.
We will use the online Q&A platform Piazza to ask and answer questions, make clarifications, and discuss supplemental topics outside of class time. You can access our Pizza page here (LINK TBD) or by logging into Piazza. You will receive an email in the first week of classes with information on how to log in.
I will make every effort to make all course-related announcements via Canvas. It is your responsibility to make sure that you promptly become aware of Canvas Announcements as they are posted; Canvas should be configured to send you an email notification by default, but if you are unsure, please come see me in office hours.
In place of ABCD cards, I will use an online service called Socrative to get real-time feedback via in-class polling. The following instructions will be presented in lecture the first time we use Socrative, but they are included here in case you forget any of the steps.
To log into Socrative to answer in-class poll questions:
CSCI241 in the “Room name” fieldI take student feedback seriously, and it will be especially important this quarter as we all navigate new and unfamiliar teaching and learning formats. I appreciate any feedback you’re willing to give, and I will do my best to act on constructive feedback when possible. I will solicit feedback formally partway through the course, but you are welcome and encouraged to provide feedback anytime in my office hours, by email, or if you desire anonymity you can fill out this Google Form.
This tentative schedule is subject to change without notice. Slides, lecture recordings, assignments, readings, etc. will be posted here throughout the quarter.
| Date | Topics | Lab | Assignments | References |
|---|---|---|---|---|
| 4/6 | Intro, logistics slides |
1: Git, Gradle | CLRS 2.1, RS 13.3 | |
| 4/8 | Tools for algorithms slides |
RS 13.4, CLRS 2.2 - 2.3.1 | ||
| 4/10 | Insertion and selection sort Runtime analysis 1 slides |
Tutorial: Method execution RS 12.3 RS 13.4 |
||
| 4/13 | Runtime analysis 2; Recursion 1 slides |
2: Testing | A1 out | CLRS 7.1 |
| 4/15 | Recursion 2; Mergesort, Quicksort slides |
CLRS 8.2-8.4 | ||
| 4/17 | Quicksort Stability, Non-Comparison Sorts slides |
RS 13.4, CLRS 2.2 - 2.3.1 | ||
| 4/20 | Radix Sort slides |
3: Work on A1 | RS 13.4, CLRS 2.2 - 2.3.1 | |
| 4/22 | Runtime analysis 3 slides, practice problems |
RS 17.1-17.3 | ||
| 4/24 | Runtime of sorts slides, exercises |
A1 due | CLRS 12.1-3 | |
| 4/27 | ADTs, Trees, Traversals, Recursion on trees slides |
4: Recursion | CLRS 12.3 | |
| 4/29 | Binary Search Trees slides |
CLRS 13.2 | ||
| 5/1 | BST insertion and removal slides |
A2 out | ||
| 5/4 | Generics, Set ADT; Rotations Videos (on google drive): 13a.mp4, 13b.mp4,13c.mp4Slides: a, b, c, exercises |
5: AList | Eric Alexander’s AVL Tree Notes | |
| 5/6 | AVL Trees II: Rebalancing Videos (on google drive): 14a.mp4, 14b.mp4,14c.mp4Slides: a, b, c, exercises |
|||
| 5/8 | Heaps 1 slides |
RS 18.2; CLRS 6.1-6.3 | ||
| 5/11 | Heaps 2 slides |
6: Review | A2 Due A3 out |
|
| 5/13 | Hashing 1 slides |
RS 18.1; CLRS 11.1-3 | ||
| 5/15 | Midterm Exam | |||
| 5/18 | Hashing 2 slides |
7: Hash functions | ||
| 5/20 | Graphs: definition, representation slides |
CLRS 22.1-3 | ||
| 5/22 | Graph traversals slides, code |
A3 due |
CLRS 24.3 | |
| 5/25 | No Class: Memorial Day |
8: Graphs | ||
| 5/27 | Dijkstra’s Shortest Paths algorithm slides, algorithm, graphs |
A4 out | CLRS 24.4-5 | |
| 5/29 | Dijkstra: Proof, Practice slides |
|||
| 6/1 | Dijkstra: Runtime slides |
9: review | ||
| 6/3 | Review/Buffer word problems |
A4 due | ||
| 6/5 | Graph Planarity, Topological Sort slides |
|||
| 6/10 | Final Exam - Available all day with a 2h time limit |
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.
One reason I am keeping lectures synchronous is to help us all maintain a routine, which is extra important when much of the structure in our lives has been upended by circumstances such as a global pandemic. The synchronous lectures will include exercises and group work that will make your learning experience significantly more interactive and, in my experience, more effective.
However, I am aware of the possiblity that you may have extra constraints imposed by family, work, technology access, or any number of other circumstances. For this reason, lecture recordings will be available and attendance will not be tracked. Participating asynchronously puts more responsibility on you as a student to make sure you’re truly absorbing the material, so if you are able to attend the lectures synchronously, I strongly encourage you to do so.
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 unless you’ve made prior arrangements with me.
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.
You may resubmit any programming assignment (i.e., A1, A2, A3, A4) within two weeks of when grades are released to earn back up to half of the unit test points you lost. When you resubmit, you must send me an email to let me know that you have done so.
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.
Please review the University policies outlined at http://syllabi.wwu.edu regarding: