Design, analyze, & use fast algorithms for managing big data.
- Learning Cooperatively
- Receiving Help
- Academic Honesty
- Effort, Participation, and Altruism
- Midterm Clobber
- Access and Accommodations
- Extenuating Circumstances and Inclusiveness
The study of data structures and algorithms is more fundamentally about the process of iteratively refining our mental representations of problems. We learn this process by studying existing approaches for solving problems.
- First, we identify the sources of their limitations.
- Second, we evaluate their insights for opportunities to improve.
- Third, we combine small ideas to create solutions for big problems.
In this course, we will study several examples of this iterative refinement process and learn how they can be applied to solve important problems in computer science. By the end of the course, students should be able to:1
- Analyze runtime efficiency of algorithms related to data structure design.
- Select appropriate abstract data types for use in a given application.
- Compare data structure tradeoffs to select the appropriate implementation for an abstract data type.
- Design and modify data structures capable of insertion, deletion, search, and related operations.
- Trace through and predict the behavior of algorithms (including code) designed to implement data structure operations.
- Identify and remedy flaws in a data structure implementation that may cause its behavior to differ from the intended design.
A complete list of topics appears in the calendar.
Learning these ideas is challenging. With the obvious exception of exams, we encourage you to discuss course activities with your friends and classmates as you are working on them. You will definitely learn more in this class if you work with others than if you do not. Ask questions, answer questions, and share ideas liberally.
The philosophy of this course is that “there is no such thing as a free lunch.” In the real world, the problems we solve will not have clearly marked answers. Sometimes, there won’t even be any known solutions at all. Learning occurs through solving problems and reflecting on your problem solving process. Problems, oftentimes even more than solutions, are opportunities for learning.
As a result, learning cooperatively is different from sharing answers. If you are helping another student, don’t just tell them the answer; they will learn very little and run into trouble on exams. Instead, try to guide them toward discovering the solution on their own.
Campuswire is our one-stop shop for course help. For most questions about the course, the Campuswire Class Feed is the right place to ask them. The course staff monitor the class feed to ensure that questions are being answered in a timely fashion. Furthermore, by posting online as opposed to emailing us directly, other students benefit by seeing the question and the answer. Use the Campuswire Chatrooms to quickly connect with peers and contact the course staff.
The teaching assistant leading your quiz section is your academic mentor. Their responsibilities do not stop at teaching quiz section. Treat your TA like you would a manager: while they won’t solve your problems for you, it’s their job to make sure that you’re working and learning as efficiently as possible. As in the real-world, it’s important to recognize when it’s necessary to work through a problem on your own vs. when you should talk to a peer vs. when you should escalate to your TA.
To meet with us, the best way is to come to office hours. In office hours, you can ask questions about the material, receive guidance on assignments, and work with peers and course staff in a small group setting. You can also meet one-on-one with a TA or the instructor outside of office hours. Each staff member is allocated a few hours per week to meet with students outside of office hours to discuss anything on your mind. In the past, students have found it helpful to discuss their course performance and how to improve their learning efficiency.
The golden rule of academic honesty is that you should not claim to be responsible for work that is not yours.
This is open to some interpretation, and you’ll be getting some help from instructors, the internet, and other students throughout the course. This is permitted, and we hope that the class is an open, welcoming, collaborative environment where we can help each other build the highest possible understanding of the course material. To help (but not entirely define) the bounds of acceptable behavior, we have three important rules:
- By You Alone. All code that you submit (other than skeleton code) should be written by you alone, except for small snippets that solve tiny subproblems.
- Do Not Possess or Share Code. Before you’ve submitted your final work for a homework assignment, you should never be in possession of solution code that you did not write.
- Cite Your Sources. When you receive significant assistance from someone else, you should cite that assistance somewhere in your source code with a comment.
For clarity, examples of specific activities are listed below.
- Discussion of approaches for solving a problem.
- Giving away or receiving significant conceptual ideas towards a problem solution. Such help should be cited as comments in your code. For the sake of others’ learning experience, we ask that you try not to give away anything juicy, and instead try to lead people to such solutions.
- Discussion of specific syntax issues and bugs in your code.
- Using small snippets of code that you find online for solving tiny problems. For example, searching for “uppercase string java” may lead you to some sample code that you copy and paste into your solution. Such usages should be cited as comments!
- Looking at someone else’s homework code to assist with debugging. Typing or dictating code into someone else’s computer is a violation of the “By You Alone” rule.
- Looking at someone else’s homework code to understand a particular idea or part of a homework assignment. This is strongly discouraged due to the danger of plagiarism, but not absolutely forbidden. We are very serious about the “By You Alone” rule!
- Working on homework in close collaboration with another person or group of people. Your code should not substantially resemble anyone else’s!
- Possessing another student’s homework code in any form before a final deadline, be it electronic or on paper. This includes the situation where you’re trying to help someone debug. Distributing such code is equally forbidden.
- Possessing homework solution code that you did not write yourself before a final deadline. Distributing such code is equally forbidden.
- Posting solution code to any assignment in a public place. This applies even after the course is over.
- Working in lock-step with other students. Your workflow should not involve a group of people identifying, tackling, and effectively identically solving a sequence of subproblems.
Your course grade is computed using a point system with a total of 300 points. All point-graded work will be scored on Gradescope.
Activities include pre-lecture reading quizzes and weekly peer charrettes.
There is no curve. Your final score will be rounded to the nearest integer before being converted to a grade based on the following point bins.
For each category, earning more than the graded points will not directly impact your final grade. Instead, your effort is recorded under Effort, Participation, and Altruism.
To encourage cooperative learning, you earn extra credit for effort, participation, and altruism (EPA).
- Attending office hours, making progress on every assignment, above and beyond
- Participating in quiz section and asking questions on Campuswire
- Helping other students, answering questions on Campuswire
EPA was created to encourage people to be good academic citizens in a way that traditional grades could not capture. This can help boost you over a grade boundary if you’re close to one. Scoring is confidential and decided by the course staff: we’ll never tell you your EPA score and you shouldn’t ask.
The expected deadline for each homework is posted on the calendar.
Each programming homework assignment has a 24-hour grace period before lateness applies. Each hour of lateness thereafter incurs a penalty of 10/24 percent (0.417%), rounded off in some unspecified fashion. This means that you will lose roughly 10% of the points for each day late. Most assignments will be worth 15 points so each day of lateness effectively deducts 1.5 points from an otherwise correct implementation.
For extenuating circumstances not covered by the above lateness policy, we allow for 1 end-of-the-quarter programming homework extension.
The late submission deadline for written exercises will be shown on Gradescope after the regular deadline has passed. The late submission deadline will depend on the exercise grading schedule, but we can guarantee that it will be at least 24 hours long. There is no penalty for submitting written exercises late so long as it is received before the Gradescope late deadline. No written exercises will be accepted after grading has begun.
The clobber policy allows you to override your Midterm Exam score with the score of the Midterm subsection of the Final Exam by computing a potential replacement score. We will only replace your Midterm Exam score with the potential replacement score if it is better than your original score. In other words, this policy can only benefit you.
To account for differences in exam difficulty, the potential replacement score is standardized by the z-score.
/* Your score for the Midterm subsection of the Final. */ double subScore; /* The class-wide mean for the Midterm subsection. */ double subMean; /* The class-wide standard deviation for the Midterm subsection. */ double subStdDev; /* Your standardized score for the Midterm subsection. */ double subZScore = (subScore - subMean) / subStdDev; /* The class-wide mean for the Midterm Exam. */ double midMean; /* The class-wide standard deviation for the Midterm Exam. */ double midStdDev; /* Your potential replacement score. */ double potential = midMean + (midStdDev * subZScore);
Your experience in this class is important to me. If you have already established accommodations with Disability Resources for Students (DRS), please communicate your approved accommodations to me at your earliest convenience so we can discuss your needs in this course.
If you have not yet established services through DRS, but have a temporary health condition or permanent disability that requires accommodations (conditions include but not limited to; mental health, attention-related, learning, vision, hearing, physical or health impacts), you are welcome to contact DRS. DRS offers resources and coordinates reasonable accommodations for students with disabilities and/or temporary health conditions. Reasonable accommodations are established through an interactive process between you, your instructor(s) and DRS. It is the policy and practice of the University of Washington to create inclusive and accessible learning environments consistent with federal and state law.
We recognize that our students come from varied backgrounds and can have widely-varying circumstances. If you have any unforeseen or extenuating circumstance that arise during the course, please do not hesitate to contact the instructor in office hours, via email, or private post to discuss your situation. The sooner we are made aware, the more easily these situations can be resolved. Extenuating circumstances include work-school balance, familial responsibilities, religious observations, military duties, unexpected travel, or anything else beyond your control that may negatively impact your performance in the class.
Washington state law requires that UW develop a policy for accommodation of student absences or significant hardship due to reasons of faith or conscience, or for organized religious activities. The UW’s policy, including more information about how to request an accommodation, is available at Religious Accommodations Policy. Accommodations must be requested within the first two weeks of this course using the Religious Accommodations Request form.
Additionally, if at any point you are made to feel uncomfortable, disrespected, or excluded by a staff member or fellow student, please report the incident so that we may address the issue and maintain a supportive and inclusive learning environment. Should you feel uncomfortable bringing up an issue with a staff member directly, you may consider submitting anonymous feedback or contacting the Office of the Ombud.
Leo Porter, Daniel Zingaro, Cynthia Lee, Cynthia Taylor, Kevin C. Webb, and Michael Clancy. 2018. Developing Course-Level Learning Goals for Basic Data Structures in CS2. In Proceedings of the 49th ACM Technical Symposium on Computer Science Education (SIGCSE ‘18). ACM, New York, NY, USA, 858-863. DOI: https://doi.org/10.1145/3159450.3159457 ↩
The number of possible points is an approximation. ↩