CSE 373 Data Structures and Algorithms, Summer 2015

Overall course grade

Grades will be computed approximately as follows (weights may be modified):

  • 60% Assignments (Written Exercises and Programming Projects)
  • 15% Midterm Exam
  • 25% Final Exam

We will have 6 assignments. If you find an error in our grading, please bring it to our attention within one week of that item being returned.

Late policy

ALL parts of an assignment must be received by the stated deadline in order for the assignment to be counted as on time. Each student in the class will be given a total of two "late days" (a late day is 24 hours of lateness) for the quarter. There are no partial days, so assignments are either on time, 1 day late, 2 days late, etc. Once a student has used up all of his or her late days, each successive late day will result in a loss of 20% on the assignment. You may not submit any portion of any assignment more than 3 days after its original due date.
  • All assignments will be turned in electronically (at a time announced for each assignment). If you choose to handwrite the paper assignments, please scan them so they can be turned in electronically.
  • We may have a few written assignments that we will submit only on paper (not electronically). These are due promptly at the beginning of lecture. If you cannot attend lecture please arrange to turn in your homework earlier to the instructor or have a classmate turn it in for you during lecture.
Occasionally exceptional circumstances occur. If you contact the instructor well in advance of the deadline, we may be able to show more flexibility in some cases.

Re-grade Policy

If you have a question about an assignment or exam that was returned to you, please don't hesitate to ask a TA or the instructor about it during their office hours. Learning from our mistakes is often one of the most memorable ways of learning!

If after discussing your question with a TA or the instructor you feel that your work was misunderstood or otherwise should be looked at again to see if an appropriate grade was given we ask that you submit a written re-grade request as follows:

Note that when a written assignment, programming assignment, or test is re-graded, the entire work will be re-graded. This means that while it is possible to regain some points, it is also possible to lose points.
 

Programming Assignment Grading

Guidelines

Robustness: Your primary task is to create a working, robust program. This means that your program should produce correct answers on all legal input and produce comprehensible error messages on invalid input. Keep in mind that (unless otherwise mentioned) unreasonably long running time is probably an error. How should you ensure robustness? Well, at the least, try to complete these steps without problems before submitting your code:

  • Compile without warnings or errors. (Notify us of errors in our code.)
  • Run correctly on all test data we give you. (Tell us if you find our test data in error!)
  • Run correctly on test data of your own which has:
    • difficult cases
    • boundary cases (both sides)
    • minorly and egregiously incorrect input
    • the empty file
  • Run correctly on the test data of another group. You must credit this group in your writeup.

This doesn't guarantee robustness, but it's a good start!

Coding clearly: You should always make an effort to write code that is easy for other people to read. In the real world, this is an important skill that is valued higher than cleverness or using the least number of lines/characters possible. In this class, it is important so that we can understand your program and grade it fairly. By reading through your code and comments, we should be able to figure out how your code is organized and why it works (or fails). If we can't, we reserve the right to deduct points.

Commenting: One aspect of writing clear code involves commenting your code so that it is clear what it does without reading it line by line (nothing is more boring). Comments should be used: (a) at the top of each file to tell what code it contains, (b) at the top of each function to tell what it does, (c) at the declaration point of important variables, (d) on any lines whose purpose is non-obvious.

Coding simply: Although Java allows it, there is no benefit to writing overly complicated statements such as: 

 if ((i = myfunc(counter++)) < num_iterations) {
 ...
 }
when they could easily be rewritten in a clearer manner: 
 i = myfunc(counter);
 counter++;
 if (i < num_iterations) {
 ...
 }
Coding should not be a macho activity. It should be like writing English sentences that you truly want someone to understand (including yourself, a few months later).

Speed: As long as your program takes a reasonable amount of time, we will neither dock points nor give bonus points on the basis of speed. In other words, all of your data structures should have the expected asymptotic time and space complexity, but the constants will not generally matter. Robustness and clarity come first!

Using Java Class Libraries: Unless specifically approved or directed to, you should not use Java class libraries in your programming assignments. In otherwords, we should not see the words "import" in your code.

Grading

While the exact breakdown will vary from project to project, the approximate grade breakdown is:

The reason why "so few" points are allocated towards program correctness and error-free compilation is because students who have gotten past 143 are smart enough to know how to get their code to compile and run against the general input (although testing "boundary conditions" is a skill which students should aim for), so program correctness and error-free compilation is neither a fair nor discriminating measurement of project quality.

The two biggest discriminating factors among 373 students are program design (such as style and architecture) and analysis (the README/writeup), which is why these factors are weighed a little heavily. Also, 373 is a course about data structures and the tradeoffs made during algorithm/data structure design, so putting additional weight on program design, and questions about program analysis and weighing tradeoffs is more in keeping with the course goals.

Putting weight on the design and writeup aspects for projects is also useful because it doesn't penalize students who "have the right idea" but couldn't get their code to compile because of a last-minute code change.

Extra Credit: We will keep track of any extra features you implement (the Above and Beyond parts). You won't see these affecting your grades for individual projects, but they will be accumulated over all projects and used to bump up borderline grades at the end of the quarter.

Written Homework Guidelines

For our written homework assignments, typed assignments are preferred. Handwritten will be accepted, but note that if the TA has a hard time reading your work, the TA will also have a hard time giving you a good grade. Writeups for programming projects must be turned in electronically, which means those must be typed anyway.

Some problems on the written assignments ask you to give an algorithm to solve a problem. Unless the assignment specifically tells you to implement the code and run it, pseudocode is acceptable. Pseudocode means that you don't have to write every line in Java with correct syntax; English explanations of operations are acceptable. Note that the general rule you should follow is that you can substitute English for any O(1) operation, but not for more complex steps. Thus, the following would not be acceptable:

  scan the list and count all elements greater than x

while the following would be OK

  int counter  // keeps track of total num > 0
  for each element in the list:
     if current element is greater than x
        increment counter

The idea is that you don't have to give all the nitty-gritty coding details (that's what the programming assignments are for), but you should demonstrate a clear understanding of what your algorithm does and where those nitty-gritty details would have to go.

For the purposes of our homework, when in doubt, MORE detail is probably better than less detail. Another way of thinking of this is to say you should write your answer in code, but we won't be taking off any points for syntax. A common mistake for students to make is to use a phrase in a pseudocode answer that is too vague without realizing it. In the example above, actually defining a pseudo-variable is one way of being sure the reader (grader) can tell what you are incrementing - AND that your algorithm will compute the correct result!