From kiringai@cs.toronto.edu Tue Jun 18 12:40:13 2002 Date: 17 Jun 2002 23:30:44 GMT From: Iluju Kiringa Newsgroups: ut.cdf.csc270h Subject: MARKING SCHEME FOR A0 AND MORE ... MARKING SCHEME FOR A0 --------------------- --------------------- Note: this is the marking scheme used for marking A0. AT the end, I mention the most commonly encountered mistakes that you should correct for the next assignment. As it appears, I will not finish marking before the office hour tonight. :-) So, please take this notice into account to know the kind of things we markers are looking for and what to do for the upcoming assignments. I have added "etc etc" at the end of most points below, indicating hat the list of things given here is NOT exhaustive, but is mostly what you've been penalized for. Watch the newsgroup tomorrow for the marks, and where to pick the A0 copies during the day. Thanks, Iluju ============================================================================= I. THE SCHEME ------------- distance.c /15 marks ---------- Documentation: /3 marks * 1 mark for file header (must include filename, student name, student number, and file description) * 1 mark for function header (must state purpose of function and role of arguments) * -1 mark for poor indentation (any style is OK as long as it's readable) Correctness: /6 marks * 1 mark for #include * 5 marks for correctness (penalized as necessary) * etc etc Style: /6 marks * 1 mark for using "const" in the function header * 5 marks for elegance, efficiency * etc etc palindrome.c /15 marks ------------ Documentation: /3 marks * 1 mark for file header (as above) * 1 mark for function header (as above) * 1 mark for good commenting * -1 mark for poor indentation (as above) Correctness: /6 marks * 1 mark for proper handling of 1-character palindromes * 1 mark for proper handling of 2-character palindromes * 1 mark for proper handling of 2-character non-palindromes * 1 mark for proper handling of 3-character palindromes * 1 mark for proper handling of 3-character non-palindromes * 1 mark for proper handling of null string ("") (should return TRUE) * -6 marks if you used array subscripting ([]) instead of pointer arithmetic Style: /6 marks * 1 mark for #defining TRUE and FALSE (or using something like enum bool {false, true};) and having the function return it * 1 mark for having the function return int (or bool if they've typedefed it as int) * 1 mark for "const" in function header * 3 marks for elegance/efficiency (penalized as necessary) * etc etc anagram.c /30 marks --------- Documentation: /6 marks * 1 mark for file header (as above) * 1 mark for function header (as above) * 1 mark for good commenting * -1 mark for poor indentation (as above) * etc etc Correctness: /14 marks * 1 mark for handling 1-character anagrams (e.g. "a", "a") * 1 mark for handling 1-character non-anagrams (e.g. "a", "b") * 1 mark for handling 2-character anagrams (e.g. "ab", "ba") * 1 mark for handling 2-character non-anagrams (e.g. "ab", "bc") * 1 mark for correctly rejecting strings of different length (e.g. "a", "bc") * 9 marks for whether the function does what it should really do * etc etc Style: /10 marks * 1 mark for #defining TRUE and FALSE (or using something like enum bool {false, true};) and having the function return it * 1 mark for having the function return int (or bool if they've typedefed it as int) * 1 mark for "const" in function header * 1 mark for no magic numbers (if they use the numbers 127 or 128 in the code they should be #defined) * 5 marks for elegance/efficiency (penalized as necessary -- the algorithm should be linear in space and time; to get a 5 you should do at least as well as the sample solution) polynomial.c /40 marks ------------ Documentation: /7 marks * 1 mark for file header (as above) * 3 marks for function headers (as above) * 3 marks for good commenting * -1 mark for poor indentation (as above) Correctness: /22 marks * 1 mark for #include * 2 marks for aborting with error message on EOF when asking for degree * 1 mark for reprompting if degree is < 0 or > MAX_DEGREE * 2 marks for aborting with error message on EOF when asking for coefficients * 2 marks for disallowing a coefficient of 0 unless the polynomial is of degree 0 * 2 marks for finding the degree of the sum polynomial in add_polynomial() (because p(x)=x^2+x and q(x)=-x^2+x are both degree two, but p(x)+q(x) is degree one!) * 1 mark for using 3 digits of precision in print_polynomial() * 1 mark for suppressing + in leading term in print_polynomial() * 1 mark for not printing the variable x for the constant term in print_polynomial() * 1 mark for not printing the exponent for the linear or constant terms in print_polynomial() * 1 mark for not printing terms with a coefficient of 0 unless the whole polynomial is of degree 0 (in print_polynomial()) * 1 mark for having "int main(void)" as main()'s header -- no others are acceptable; "main()", "int main()", "void main()", etc. are all wrong * 1 mark for having the "Enter a value for x" prompt loop until EOF * 1 mark for allocating enough room for the polynomials (they need MAX_DEGREE + 1) * 1 mark for having main() return EXIT_SUCCESS (or 0) on successful termination and EXIT_FAILURE (or nonzero) on error. * 3 marks for other correctness issues (penalize as necessary) * etc etc Style: /11 marks * 1 mark for all function prototypes at top of file * 1 mark for "const" in add_polynomial() header * 1 mark for "const" in eval_polynomial() and print_polynomial() headers * 3 marks for modularization (should have separate functions for reading in a polynomial, printing a polynomial, adding two polynomials, evaluating a polynomial, plus others as necessary) * 2 marks for #define MAX_DEGREE 30 (or equivalent) and using it * 3 marks for elegance/efficiency (penalize as necessary) * +1 bonus for using Horner's rule in eval_polynomial() II. COMMONLY ENCOUNTERED MISTAKES --------------------------------- * "const" has not been used. Though this may not prevent your program from working, it is considered good practice when programming for safety. * Do comment the critical parts of your code. Of course, you do not have to comment evrything; but when I get, e.g., the anagram.c piece of code using some kind of 3-levels nested while loop without any explanation, this is not acceptable. * Spend a bit of effort looking for algorithms that are not naive. Comming up with a naive algrithm that works fine is OK, but won't earn you the top marks. As an example, many people solved the anagram problem either by sorting both strings before comparing them, or by comparing one string with all the permutations of the other string. Though this works, it's naive and not efficient. * Modularization is encouraged and should be done. When modularizing, try to choose appropriate names that really reflect what the function does. If, for example, a function does more than just adding the coefficients of 2 polynomilas, please do reflect this in the name you choose. * Also, have all the function prototypes written at the beginning of a program. * When test runs are required, do submit them using the Typescript utility, and don't edit the Typescript file ! Failure to do so casts a big doubt on whether your program really works. Of course, there were many good points in your submissions, which is why you'll get good marks for A0. Iluju