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 about 15 hours per homework; a few students may require somewhat less, and some students will require even more time. Homework will typically contain a mix of programming exercises and "theory" questions about data structures and their implementation. Roughly 3 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.
|HW01||Course Overview and Recursion||Fri. Sept. 1, 2017 @ 11:59PM (PST)||Submit|
|HW02||Linked Lists||Fri. Sept. 15, 2017 @ 11:59PM (PST)||Submit|
|HW03||Runtime, Queues, and Stacks||Wed. Sept. 27, 2017 @ 11:59PM (PST)||Submit|
|HW04||Interpreter Project||Mon. Oct. 9, 2017 @ 11:59PM (PST)||Submit|
|HW05||Interpreter Project, Part 2||Fri. Oct. 27, 2017 @ 11:59PM (PST)||Submit|
|HW06||Heaps and Backtracking||Mon. Nov. 6, 2017 @ 11:59PM (PST)||Submit|
|HW07||Balanced Search Trees||Fri. Nov. 17, 2017 @ 11:59PM (PST)||Submit|
|HW08||Hashing (Project, Part 3)||Fri. Dec. 1, 2017 @ 11:59PM (PST)||Submit|
In order to properly submit your assignment, please follow the course submission instructions.
Grading Weights and Scale
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.
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.)
The final grading scale is given below. The meaning of this grade scale is the following: if the weighted average (with the weights given above) of your percentages is above or equal to the given one, you will get at least that grade. As an example, if your weighted average is 79.97%, your grade in the class will be B+. Notice that this means that we do not round percentages up.
We will guarantee that you will get at least the grade indicated by the following scale. At the end of the semester, we may decide to lower the scale if the exams were more difficult than intended.
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.
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 your TA Gozde Sahin, 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:
- You will receive a grade report for your homework or project on GitHub.
- 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.
- If the grader and you cannot resolve the issue, the grader will reassign the issue to one of the TAs, specifically Alana Shine or Hannes Leipold. The TA will attempt to solve the issue within an additional 7 days.
- 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.
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.
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.
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.
- 2 points for missing or unclear README.
- 1 Point for each extra garbage file (binary, temporary files, etc.), up to 3 points total. Test files (.in, .out, .txt, etc.) and additional test programs (.h, .cpp, etc.) will not result in deductions.
- 1 Point for each incorrectly named file or incorrect file format, up to 5 points total.
Multiple choice problems
- If you miss one answer on a problem of several possible answers, you get 50%.
- If you miss more than one answer on a problem with multiple correct answers, you get 0.
- If you miss the one right answer (if there is only 1 correct answer), you get 0.
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.
- If we cannot compile your program, either becuase your Makefile does not work or because your code does not compile, you will lose all points for test cases we cannot run.
- Up to 6 points for code that compiles with warnings. The actual deduction depends on the number and type of warnings.
- 4 points deduction for valgrind errors, including memory leaks.
- 2 points deduction for each incorrect input method, output method, and output format.
- 1 point deduction for leaving debug statements in code that do not affect output results (unless the assignment specifies otherwise).
- 2 points deduction for using
using namespace stdin header files.
- 2 points deduction for using global variables, unless the assignment specifies otherwise.
- 3 points deduction for added public functions or for exposing member variables/functions that should be private, unless the assignment specifies otherwise.
- 3 points deduction for writing class definitions and implemention in one file, unless the class is templated or the assignment specifies otherwise.
- Up to 2 points deduction for each code readability problem, including but not limited to lack of comments, poor indentation, and chunks of commented out code.
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:
- Asking other students for hints or discussing high-level ideas. This is clearly OK.
- Having other students look at your code and help you discover mistakes. This is dangerous: if the other student intentionally or accidentally copies from you, there would be negative consequences for both of you.
- Asking course staff (instructor, TAs, CPs) for help, ideas, having them look through code, etc. Clearly no problem; if you are asking for too much help, we will simply not provide that much.
- Copying code or test cases from other students, even if you subsequently edit, improve or change them. Clearly not OK, even if you intend to understand the code or inputs before submitting them as your own. This is most definitely plagiarism! We will run the MOSS software on all submissions in the class to detect instances of copying.
- Copying test cases from other students or Piazza when test cases are not graded. This is OK, since it serves to teach you something, and there is no risk that you will get points for the work of other students.
- Sharing your code or test cases with your classmates. Don't do this! We have had several cases of trusting friends getting into trouble because their "friends" submitted code as their own. If a "friend" pressures you to share code or inputs with them, they are not your friend.
- Looking at other students' code or test cases (before having finished your own). This is dangerous. If your code or test cases ends up resembling the other student's very closely, then it is cheating. To avoid accidentally cheating, we recommend the failsafe measure below.
- Looking up concepts, syntax, and basic instructions on how to deal with the topics online. This is clearly OK, as you are learning.
- Looking online for solutions to specific homework questions, such as copying code from Wikipedia and other sites. Clearly not ok, even if you subsequently edit them. You are trying to use the work of others instead of your own. Clearly cheating, and MOSS does have a lot of code from online sources in its database.
- Posting in online forums asking people to solve homework questions (or parts thereof) for you. Clearly cheating - Duh!
- Unfortunately, we are aware that (1) there are solutions to many homework questions available on the WWW, and (2) even USC students tend to cheat quite frequently on homeworks. Please help us restore faith in the integrity of Trojans by not being those students.
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!