CSE 373, Summer 2019: Syllabus

Overview

Teaching staff:

Times:

  • Lecture: PAA A118 from 1:10 to 2:10, MWF
  • Midterm: Friday, July 26 in lecture
  • Final (Two parts): Thursday, August 22 in Section and Friday August 23 in lecture

Other:

Goals

The primary focus of this class is on gaining a strong theoretical and conceptual understanding of common data structures and algorithms as well as how they can be practically applied within larger programming projects.

Specific topics we will cover include:

  • Data structures and ADTs: lists, dictionaries, trees, balanced trees, AVL trees, hash tables, priority queues, binary heaps, disjoint sets
  • Graphs and graph algorithms: graph search, shortest path, and minimum spanning trees
  • Algorithm analysis: asymptotic analysis, P and NP complexity classes
  • Sorting and divide-and-conquer

This course is also designed to have a practical component to help you gain basic familiarity with techniques used within industry. In particular, you'll be asked to:

  • Work on larger projects in pairs
  • Learn how to use an industrial-strength IDE
  • Learn techniques for checking correctness (writing unit tests with JUnit, designing and checking invariants, etc)
  • Gain basic exposure with integrating and using 3rd party libraries
  • Learn how to collaborate on a single code base using source control repositories

And finally, this course also emphasizes the importance of making and justifying effective design decisions. All of the above skills are those that are traditionally a part of any technical interview, thus this course is typically considered an important pre-requisite when applying for development positions.

Assessment

Here is how your grade will be calculated:

  • Written assignments: 20%
  • Programming projects: 35%
  • Midterm exam: 15%
  • Final exam: 30%

Homework

Grading policies for written assignments: Your written work will be graded based on correctness as well as the quality of the justifications and explanations you provide. These assignments will be hand graded by TAs.

Grading policies for programming projects: Your code will be graded by automatic scripts based on the following criteria:

  1. Correctness: Does your code pass the tests we gave you? Does it pass some additional tests we've withheld?
  2. Design: Are there any larger design issues with your code (e.g. inefficiency or gross redundancy)?
  3. Style: Does the automatic style checker we've provided you report no issues with your code?
  4. Test quality: You will sometimes be asked to write tests for your data structures. Do these tests correctly identify problems in buggy implementations?

Grade change requests

Your projects will be graded automatically by tests the staff runs on your code. This means that occasionally small errors are disproportionately penalized. If you feel you incorrectly lost points on an assignment, please fill out the grade change request form. The form will ask for the following:

  • You and your partner's UW Net IDs
  • A link to your team repo
  • Why your code received the points it did
  • Specific explanation about what needs to be changed for you to receive points back

Your submission will be reviewed by the staff hw team at various points throughout the quarter.

Written assignments are scored by hand. If you believe a problem was misgraded, file a regrade request on gradescope, explaining why you believe you incorrectly lost points.

Exams

There will be timed exams in this course: a midterm and a two-part final exam. For the midterm and the second-part of the final you will be allowed a single sheet of 8.5"x11" paper for notes. The first-part of the final will be closed-note.

Make-up exams will only be given in case of a serious emergency. If you might miss an exam, contact Robbie BEFORE the exam (or arrange for someone to do so). You must show evidence that you are physically unable to take the exam. No accommodations will be made for students who arrive late to exams.

Accommodations

If you have established accommodations with Disability Resources for Students (DRS) please communicate your approved accommodations to the instructor at your earliest convenience so we can discuss how they apply in this course. If you have not established accommodations with DRS, but have a temporary or permanent health condition or disability that requires accommodations, you are encouraged to contact DRS at uwdrs@uw.edu or disability.uw.edu to discuss potential accommodations.

Homework

There are two types of homework assignments: solo written assignments and programming projects. Projects will usually be due Wednesday nights, and written assignments will usually be due Friday nights.

Individual written assignments

There will be about 5-6 written assignments throughout the quarter, each span 1 week in length. These MUST be completed INDIVIDUALLY. This will be turned and graded in via GradeScope. Please see the section on academic honesty and collaboration below.

Programming projects

There will be 1 individual programming project and 4 pair programming projects throughout the quarter. The 4 larger projects are meant to be completed in pairs, though you may work on them individually if you so choose. Projects generally span multiple weeks with a checkpoint due once a week. These checkpoints are due at the normal Wednesday night time (each assignment page has the offical due date).

If you lose points during a checkpoint, you may earn back half the points you lost if you fix and resubmit your work for the next project deadline. For example, suppose you earned 60% for your project 1, part 1 submission. If you fix and submit your part 1 code by the part 2 submission deadline, your part 1 score will be retroactively adjusted to 80%.

Note that your final project submission will not be eligible for this regrade policy.

Turn in your code simply by pushing to the GitLab repo that was assigned to you, we will automatically grade whatever code is in your repo at the due date. If you are electing to turn in your assignment late, please make sure to fill out the appropriate late turn in form (found on each homework page) so we know which version of your code to grade.

Late days

Each student receives four late days that may be used for written assignments, checkpoints, and project due dates. If a team submits a project late, both students must use a late day. If you (or your partner) have no late days left, you will be deducted 20% of your overall score per each day late.

We will not accept assignments later than two days after the deadline, whether you use late days or not. Late days will be applied automatically, except for code submissions on GitLab, which will require filling in a late-day-usage form. Leftover late days will have zero impact on your grade.

If unusual circumstances truly beyond your control prevent you from submitting an assignment or attending an exam on time, you should discuss this with the course staff ASAP. If you contact us well in advance of the deadline, we may be able to show more flexibility in some cases.

Academic honesty and collaboration

Our goal is for you to learn as much as possible in this course. Often the best way to learn concepts is to discuss them with your classmates, but we need to ensure that every student (or pair on partner projects) is submitting their own work to properly evaluate your learning.

For this reason, we take academic honesty very seriously. Cheating not only deprives you of practice and understanding, but is also unfair to the rest of your class. Any assignments that has copied or paraphrased content will receive a zero. We will be using the MOSS program to check for code similarities against other student submissions as well as public code available online.

You are, however, strongly encouraged to discuss assignments and concepts at a high level with your classmates so long as you:

  1. Make a serious attempt on each and every problem or coding project before discussing it with others.
  2. Limit cooperation to just group discussion and brainstorming. A good rule of thumb is that you should not take away any written notes, photographs, or other records from your brainstorming session.
    • Do not show your code to another student, nor should you look at another student's code directly. This includes current and former students, tutors, friends, paid consultants, people on the internet etc...
    • Do not post your homework solution code publicly online for any reason.
  3. Write up each and every problem in your own writing, using your own words. (Similarly, you must write code on your own).
  4. List each person you collaborated with at the top of your written homework or in your project writeup.

Naturally, when working on a partner projects, you're free to share your code and collaborate in full detail with your partner. (In fact, we strongly encourage pair-programming, where you are working simulatneously on one computer) However, you must not share your code with other groups.

If you have a specific question about your code or written work, the only person you may show your work is a member of the course staff.

Cheating: If you do not follow these rules, you will be considered to have cheated. If you are caught cheating, the course instructor will initiate a cheating case in the University system. If you feel that you are having a problem with the material, or do not have time to finish an assignment, or have any number of other reasons to cheat, we have many mechanisms for getting help.

For more details, see this Academic Misconduct page. If you're not sure if something constitutes cheating, send the instructor an email describing the situation.

Getting help

There are two main ways of getting help:

  • Piazza:

    Our class piazza can be found here. We use Piazza as an online Q&A forum where you may ask questions (both publicly and privately). If you have a question, this should be the first place to check & it's often the case that other students may have had the same question.

    We also strongly recommend you monitor new questions asked on Piazza semi-regularly: seeing questions other students ask can often be surprisingly enlightening.

  • Office hours:

    Please visit office hours! Answering questions during office hours is often one of the best parts of teaching, so please do us a favor and make use of them.

One additional resource to keep in mind is the resources page on the class website. This page contains links to a variety of guides, tips, and tricks on material we don't have time to fully cover during lecture or section. The resources there might not always be relevant, but they're checking from time to time.

Software and textbooks

We will use Java 12 on all programming assignments.

Our officially supported IDE is IntelliJ. You may use other IDEs like Eclipse or Netbeans if you wish, though the course staff may not necessarily be able to help you with any setup-related questions you may have.

However, you MAY NOT USE jGrasp. (Well, you can try, but it's very likely that jGrasp will not be able to correctly load or run our class projects.)

The textbook for this course is Data Structures and Algorithm Analysis in Java (3rd edition) by Mark A. Weiss. This textbook is OPTIONAL: you should not need it to succeed in this course.

Acknowledgements

Many of the materials posted here and used in this course have been shared and refined by many other instructors and TAs in previous offerings of CSE 373, CSE 332, and CSE 326. This version of the course closely follows versions by Kasey Champion, and was significantly influenced by previous offerings by Shrirang Mare, Michael Lee, Riley Porter, Ruth Anderson, Dan Grossman, Kevin Quinn, Hunter Zahn, Evan McCarty, and Adam Blank.