CSCI 104 - Spring 2018 Data Structures and Object Oriented Design


Homework will be assigned roughly once every 1.5 weeks. It will be graded, and require substantial work. The average student should expect to spend more than 15 hours per homework. Homework will typically contain a mix of programming exercises and "theory" questions about data structures and their implementation. Roughly 2 assignments will contain pieces that contribute toward a class project; the different parts of the project will build on each other. As the project progresses, students may find it necessary to revisit and improve their earlier solutions, so good coding practices and documentation are strongly encouraged.

Each student will receive a private code repository on the course's GitHub Organization to use for the development and submission of all assignments. You will be using the git source code management tool to maintain your homework code.

HW Schedule

HW Topic Due Date Submit
HW01 Course Overview and Recursion Fri. Jan. 19, 2018 @ 11:59PM (PST) Submit
HW02 Linked Lists and Recursion Wed. Jan. 31, 2018 @ 11:59PM (PST) Submit
HW03 Runtime, Queues, and Stacks Tues. Feb. 13, 2018 @ 11:59PM (PST) Submit
HW04 Search Engine Project Mon. Feb. 26, 2018 @ 11:59PM (PST) Submit
HW05 Sorting, Search, Templates Tues. Mar. 20, 2018 @ 11:59PM (PST) Submit
HW06 Search Project, Part 2 Thurs. Apr. 5, 2018 @ 11:59PM (PST) Submit
HW07 Balanced Search Trees Tues. Apr. 17, 2018 @ 11:59PM (PST) Submit
HW08 Hashing and Splay Trees Fri. Apr. 27, 2018 @ 11:59PM (PST) Submit

Submission Instructions

In order to properly submit your assignment, please follow the course submission instructions.

Grading Weights and Scale

Grade Weights

The following point structure will be used in determining the grade for the course. Your final grade will depend solely on your own performance, graded according to the scale given below.

Pct. Item
40% Homework
5% Lab Exercises
22% Midterm Exam
33% Final Exam

Class participation and attendance is strongly encouraged, but will not be enforced or affect grades directly. (Experience shows, however, that attendance and participation correlate highly with success in classes.)

Grading Scale

The class will be curved. We guarantee that earning a 50% in the class will get you a C or better. At the end of the semester, we may decide to lower the C cutoff if the exams were more difficult than intended.

Homework Policies

For each assignment, a precise time will be specified (usually at 11:59.59pm) on the due date. Submission must be made correctly via your github account. Each student has 3 grace days they can use over the course of the semester. A maximum of 1 grace day can be used on a single assignment. Once you have used your grace days, any late submission will not be accepted; thus, it will be graded as a 0.

To use a late day you MUST follow the submission policy outlined in our late submission instructions to alert the course staff to fetch your late submission. Following instructions is critical, and failure to follow the submission policies may result in a score of 0.

Grade Disputes

We will work hard to post HW scores and feedback within 2 weeks of the homework's due date. Exams will typically be graded within at most a few days of the exam date. If you have not received your score on a particular HW even though most other students in the class have (say, 24 hours after the score release date), contact Brandon Cen, who will then follow up with your grader.

Any disputes with posted grades must be raised within 7 days of the score posting. (If your schedule does not permit a detailed request within 7 days, you should register a short note that you plan to dispute, and then submit the dispute when you are ready.) Notice that any regrade request will result in us trying to give the fairest possible grade to you, which could be higher or lower than the one you received originally.

To raise an issue with your exam score, you should come to the office hours of the professor teaching your section. If you cannot make posted office hours, schedule one by e-mail. The TAs will not be allowed to grant regrades on exams.

Since we want to address all of your homework-related concerns as easily as possible, please follow the policy given below for creating homework regrade requests:

  1. You will receive a grade report for your homework or project on GitHub.
  2. If you have questions, you should assign your grader to the issue within 7 days of the post date, and then describe your questions in the comments for this issue.
  3. If the grader and you cannot resolve the issue, the you should reassign the issue to one of the regrade TAs and attend their regrade office hours. The TA will attempt to solve the issue within an additional 7 days. See People and Office Hours for regrade TAs and their office hours.
  4. The TA will then review your homework and make any necessary adjustments, up or down.

Final settlement will, if necessary, be decided by the professors.

Homework Grading Policies

For each assignment, a precise time will be specified (usually at 11:59.59pm) on the due date. Submission must be made correctly via your github account. After you believe you have submitted, you should always clone your repo into a new folder and make sure everything you think you submitted was cloned into this new folder. Then compile your code in this new folder and run it to ensure we will also be able to compile and run your code.

Grading Environment

We will grade your assignments using gcc/g++ at the command line in the virtual machine we provide for the course. You are free to use other compilers or IDEs to develop your code, but in the end, it has to work with g++ in the virtual machine. You probably want to test that it does before submitting.

Assignment Rubric

Each homework assignment generally asks for a set of features to be implemented in C++. It also usually asks students to specifically either use or not use some STL classes. Based on these requirements, each assignment is going to have its own grading rubric. We also have a general rubric which you need to consider for all assignments; this captures issues that will be common to most of your assignments, like quality of your code.

This is meant as a general guideline for you to understand how we grade homework, and what things you need to watch out for to avoid losing points. The actual deduction can vary from question to question depending on the nature of the problem. For example, if a homework problem is meant to test your understanding of pointers, memory leak will be worth more points.

General Rubric

Submission Deductions in this category are per homework; they are capped so that you do not get below a score of 0 on any homework, though 0 is possible.

Multiple choice problems

Coding Problems

Deductions for coding problems are by question; they are capped so that you do not get a score below zero on any question, though 0 is possible.

Test Cases:

Code Review:

Academic Integrity

The official language on academic integrity is on the syllabus . Here is a little more clarification.

Practically speaking, it is important to be able to seek out helpful information and collaborate, yet it is clearly wrong to pass off work done (even just in part) by others as your own. Navigating these two principles can be tricky. However, notice that only you are responsible for understanding what is allowed, and what is not. Cheating can and does occur which is neither malicious nor intentional. Knowledge is power!

When in doubt whether some behavior you are considering is appropriate, feel free to consult with us (course staff) before engaging in it. As a general guideline, imagine that your professor is looking over your shoulder, but can't read your mind. Would it look to him/her like you're legitimately seeking to understand things, or trying to get a better grade than your own work warrants? That should guide your behavior. Here is a list of some particularly common things, with an explanation:

We run MOSS on all homework submissions to catch inappropriate collaboration and plagiarism. If we catch you cheating, you will be reported to SJACS, no exceptions. Follow the above guidelines to make sure this doesn't happen to you.

Again, most importantly, you should never send your code or test cases to anyone other than course staff, for any reason. As soon as you send it, you have no control over it; it could get shared with a lot of students. (Yes, we have had cases when 10+ submissions used the same code that one trusting student shared with a classmate.) When code or test cases are shared, both students are culpable! Remember: friends that pressure you for unreasonable help are not really friends. There are plenty of course staff and instructors who are here to help!

So suppose that you were kind of working next to a friend, helping each other out a bit, and along the way, you really saw too much of your friend's code. You didn't mean to cheat, but you kind of have your friend's code in your mind, and you're worried that the code you write yourself will resemble it too closely. And given that your instructors seem to be such hardasses ...

The "emergency" rule is to follow what Aaron likes to call the "Hearthstone Rule": erase all writen notes/photos/records from inappropriate collaboration. Then take a break (at least 30 minutes or an hour) during which you do something completely unrelated to the course. (Aaron recomends a few games of Hearthstone.) Afterwards, you return to your work, and you'll probably be fine.

The Hearthstone Rule is a failsafe to help you recover when you accidentally engage in inappropriate collaboration. Flouting the spirit of the Hearthstone Rule while following its letter does not excuse cases of cheating which arise. For example, it is clearly not ok to study and memorize your friend's code, play 30 minutes of Hearthstone, and then write out your friend's code from memory and submit it.

Now you know, and knowing is half the battle!