Exam1 scores (comp210 98.fall) range N histogram ----- -- --------- [ 0,45) 3 XXX [45,55) 10 XXXXXXXXXX [55,65) 9 XXXXXXXXX [65,75) 21 XXXXXXXXXXXXXXXXXXXXX [75,85) 32 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [85,95) 33 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX [95,100] 8 XXXXXXXX median: 81 If i had to give out grades right now, [85,95) would be an A, [75,85) a B, [65,75) a C, [55,65) a D, [45,55) ... - If you are in the 45-55 range, PLEASE COME SEE ME! You can still do okay in the course, but it will take us working together. - If you are in the 55-65 range, please come see me (lower case) or john greiner. The time to clear up any confusions is now. If your score is lower than you'd like, be sure to avail yourself of labbie hours, therapy sessions, etc (listed on the web page, as always). ------------------- comments / common problems --------------------- Here are comments by the graders on some of the particular problems: ----- #1 (tax-rate): -5 no constants named -2 "210" constant not named -3 no contract(s) -1 contract on helper(s), but not main function -1 poor placeholder names -1 excessively complicated functions -1 using natnum template's zero? test ----- Problem #2 (insert-sort): Here are the common mistakes I wrote down on the papers as "*n"; (a). *1: Not saying what "num" and "lon" are. (c) *1: Not following the template and using a helper function *2: Switching insert and insert-sort, hence resulting in a non-terminating function. ----- Problem #4 the approximate splitup, in order of commonplaceness: -0 contract in template forgotten (nearly everyone did that) -1 contract in function missing (after it being said so on the cover) -3/4 no data extraction whatsoever -3 no natural recursion -1/2 data extraction with no mention of sub1 in args to recursion -1 stupid naming of functions and templates (someone called it junk) -2ish said something wrong about whether the order matters -lots used the forbidden - etc. in part b. -lots function wrong, very few that way though etc. and clarifications: and/or were usable in part B as they are special forms and not functions ----- Problem #5 (hand-evaluation) -3 sum & sum-accum give same answer -1 no "=" or other marker between steps -1 (lambda (list ...) ...) for application -1,-2 (lambda (list ...) ...) in other evaluation steps -1 (define sum ...) for application -1 (define sum ...) in other evaluation steps -2 no application step shown -2 not evaluating function body in step after application -1 not simplifying subexpressions before recursive calls -1 only showing recursive steps embedded within conditionals -1 not showing all of expression left to be evaluated -1 applying numbers -1 no "list" in constant lists of numbers ----- Problem #3 (secretaries & managers), and general notes [lengthy] For the most part, people had their list templates do list-processing, and the employee-template to employee-processing, and this general approach got you most of the points. A few notes that usually resulted in zero or one point off, but were widespread: Note I: Remember that the fields of a structure each have a name (say "loe"), and the value stored is of some certain type ("List-of-Employee"). As long as you give both pieces of info it's fine, but you may not have paid attention to how it's been done in class: In the data definition, there is always a distinction between what is typed in literally, and what is replaced with a value of a given type: (define-struct manager (salary loe)) ; An Employee is ; - (make-manager ) ; - ... Note how you literally type in "(make-manager", but the parts in angle brackets (different colors, in lecture) are replaced with a *particular* number List-of-Employees. (Really, the things in angle-brackets are placeholders, at the meta-level of our discussion.) The notes make this same distinction, in a slightly different way: ; An Employee is ; - (make-manager ) ; - .... ; where is a number and is a List-of-Employee. (where and happen to coincide with the names used in the define-struct.) Note II: Many people overlooked one of the obvious test cases: a manager with an empty List-of-Employee. Some people had neary-redundant test cases: e.g. two secretaries, differing only in name and salary. A good habit, when writing your programs, is to try to write some more comprehensive test cases: a secretary, an manager with no underlings, a manager with a couple secretretaries, and finally a manager whose underlins include another manager-with-underlings. Note III: If you are saying two expressions have an equal value, it's only grammatical to use "=". Good: (cost-to-company (make-secretary 500 'jeeves)) = 500 Bad: (cost-to-company (make-secretary 500 'jeeves)) ---> 500 Worse: (make-secretary 500 'jeeves) ---> 500 Evil: (make-secretary 500 'jeeves) = 500 For comparison, consider your 6th-grade math class talking about square-root: Good: sqrt(4) = 2 Bad: sqrt(4) ---> 2 Worse: 4 ---> 2 Evil: 4 = 2 Note IV: There is confusion about when you need to have one definition before another, in drscheme. The rule is simple: when you *evaluate* a placeholder, it had better have been defined. Note that when you write a lambda-expression, you don't evaluate its innards until the moment you *apply* the function. So inside the lambda you can have a placeholder defined later-on. In fact, for mutually recursive functions, this *must* happen. Note V: What do parentheses mean in scheme? One thing: function application. Okay, that's a *mild* lie, because some of the special forms use parentheses themselves: - lambda delimits its argument-list with parens, - define-struct has an extra set of parens, and - cond has parens around each question/answer pairs as well as around the entire list of q/a pairs, and - local uses parens to delimit its list of "define" statements. Besides these uses, *every* paren means apply-a-function, period. Two distressingly common mistakes: ; A List-of-Hottentots is ; - (empty) ; - ... and (make-employee ('jeebs 7)) --------------------------------------------------------------