Comp210 01.fall exam3 grading key

Preliminary

#5
- Look for close correspondence between the imperative
  version and the assembly version
- make sure they use "mov" rather than "ld" to move things
  between registers.
  (They hadn't used "mov" before this problem; part of
  the point was needing to figure out how to use it,
  from the sheet.)

#3, append!
- they can use the regular ol' "append", if they want:
     (define (append! a b)
          (set-cdr! a (rest (append a b))))
   Note that set-car! of a is *not* needed
   (and should be some points off).

- Their contract should have "cons" instead of "list", for the first arg.
  Also, if their contract includes empty, OR they
  handle the empty list in their code, they should include
  a big warning "does NOT change the first argument if
  empty list provided", or else lose soem points.
  Realizing this limitation is part of understanding the prob.

That's all i can think of, off the top of my head!
--ian

• a (alpha): Your solution is overly complicated. See soln.
  You might wonder, "but my answer works; why does it matter if it's a bit roundabout?" Imagine hiring a contracter to convert your bed into a loft, and they do so correctly ... but they have huge extra beams, hanging wires, etc. Would you say that they are a top-notch contracter?
  Providing simple, clear solutions (where they exist) demonstrates additional understanding.

  (Note that an alpha in quotes might refer to a contract -- saying you should have used something generic like an alpha, since "num" is more restrictive than the actual contract.)

• b (beta): Re-use previously-defined functions and test cases.

• g (gamma): Use better test cases.
  In particular, be sure to include base/degenerate cases (0 for natnums, empty for lists, 'unknown for FamTrees).
  It may be appropriate to try 1 (or, lists of length 1), for certain functions. In relative->absolute, some people had functions which failed for lists of length 0 and 1 for separate reasons, but worked for length 2 or more.
  With FamTrees, it helps you and readers to define small family trees (a child with no known parents, only one known parent), and use these smaller trees to build a bigger one.

  problem #2:

  • -1/2 if not testing on a length-1 list.
  • -2 if not testing empty nor a length-1 list.
  • -2 if code doesn't work for empty; -2 if doesn't work for length1 lists.

• d (delta): Not following the template. Have a separate function to handle lists, rather than doing further case analysis inside a cond-branch; leave this function as the place where individual waterways are processed.
• e (epsilon) (-4): (problem #2) You can't use a placeholder that has not yet been given a value with define. Thus for circular structures, first make a new actor with a dummy value for its co-stars, then after all actors have been defined you can go back and fill in all the co-star relations properly. (Cf. hw08's connect-caves.)
• z (zeta): -2 if the field KB# is set to be 0 initally for everybody (and this results in incorrect code); -4 if the field KB# is magically set to the correct answer for the test input.
• h (eta): -1 for consing on to (void) rather than a list; -1 for building up some big list and then throwing it away w/o ever using it.
• f (theta): (#5b: Jam; -1/2) Printing is not the same as returning a value (or, storing a value in memory, as requested for the function). -1 for not storing. -1/2 if no halt instruction.
• i (iota): In hand-evaluations, use "=" if you mean to say two things are equal. Just a matter of having grammatical (mathematical) sentences (rather: no sentence fragments). Also, the theme of the first 10 weeks of the class is how computing is just the same principle as high school algebra, with the addition of cond; as in algebra, you use "=" to assert that two expressions have an equal value. (As discussed on example hand eval and homework laws.)
  -1 for nothing or weird notation joining expressions; -2 for not having full expressions carried along.
  
• k (kappa): Include contract and purpose for helper functions. Your purpose should be informative, and not just repeat the header:
  • Useless: "This function takes in a list-of-number and a number, and returns a list-of-number"
  • Only marginally helpful: "This is a helper for r2a, which uses an accumulator."
  • Good: Return the cumulated list as described for r2a, but with "elapsed" time already passed before the first time.
  -1 for no contract, -1 for no useful purpose, -1/2 for marginally useful purpose.
• l (lambda): Avoid having the same lines of code doing the exact same thing. Using local is one solution. (This is not a question of efficiency -- negligible to do one extra multiplication, plus the compiler probably optimizes that for use -- but rather of having a central point of control, and ease of understanding.)
  Typically, -1 per occurrence.
• m (mu): (#3a/append!; -1/2) Checking for the second argument being empty is unnecessary -- it falls out of the rest of the code.

margin note	Meaning				text markup
	delete
	insert (caret)
	insert a space
	transpose
	align vertically
	begin a new paragraph
	close up
	let stand