Class 42: Notes on exam 2

Held Monday, November 13, 2000

Summary

Today we discuss exam 2.

Notes

• Exam 2 returned.
  • I've written up some notes on that exam. Please read those notes!
  • We'll spend much of today's class going over the exam.
  • Yes, I'll give you time to read over my comments.
  • Please don't discuss your grade with others.
• I'm still working on exam 1.
  • I was up until midnight on Saturday and 1am on Sunday/Monday grading exam 2.
  • I'm guessing that it will take until Wednesday or Friday for exam 1.
• I've written a contract guaranteeing a minimum grade.
• I will create two forms of exam 3. You may take only one.
  • One will be a closed book test held in class. You will have class time (and, if necessary, lunch time) to complete the exam.
  • The other will be one of my standard take-home exam.
• We should think about when the next take-home exam (and in-class exam) occur.
  • I'll be gone Nov. 30 through December 3.
  • My temptation is to distribute the take-home on Wednesday, Nov. 29 and give the in-class exam on Friday, Dec. 1. The take-home would be due on Friday, Dec. 8.
  • Short calendar:

    Su Mo Tu We Th Fr Sa
    12 13 14 15 16 17 18   November
    19 20 21 22 23 24 25   Turkey week
    26 27 28 29 30  1  2   December
     3  4  5  6  7  8  9   Last week of classes
    10 11 12 13 14 15 16   Finals week
    

• Many of you have asked what to do next semester, particularly as its preregistration time.
  • I encourage those of you who did well on this exam to go on to 152.
  • I encourage first and second years who did well on the exam to consider CS majors. (We have a surprising number of dual majors.)
  • I encourage first-year women in the first category to consider doing summer research with me. I'll try to contact you individually.
  • I encourage all of you to come talk to me if you want to talk about any of this stuff.
• Our grader, Greg Fuller, would like the URLs of your homework 4s. Send email to fuller@grinnell.edu

Overview

• Exams returned. Pause for reading.
• General notes.
• Individual problems
  • For each: Why did I write the problem?

Introductory Notes

• Basically four categories:
  • Gets it and works incredibly quickly (a few)
  • Gets it but needs some time (many)
  • Having some trouble (more than I'd like) = Didn't turn anything in
• I don't think poorly of those of you in the third category
  • Not everyone can get this stuff (example: My wife)
  • Perhaps we need to work together to resolve your problems
• My goal for every exam is that you learn.
  • I hope you learn some things by doing the exam (including the realization that you can actually do some of this stuff.)
  • I hope that you learn some things from my comments (even when I don't take off points).
  • I hope that you learn some things from our discussion of the exam.
  • I hope that you learn some things from the notes on the exam.
• Some general comments:
  • Learn to use load. I didn't need to see the databases included in your files.
  • Format your code for readability. It's a pain in the whatever to read code that is all left-justified or that wraps around.
  • Comment your code. See below for more.
  • Input is not a verb. Inputted is not a verb form. Imputted is certainly not a verb form. A user enters input.
  • Scheme is a proper noun and should be capitalized.
  • I expect you to write well.
• Most of your procedures need the six Ps (and also require that you think about the seventh P: problems).
  • Procedure. The name. Try to use clear names.
  • Parameters. Direct input to the procedure. Should correspond to the values in your lambda. (Also called Given.)
  • Purpose. A short summary of what the procedure does. You don't need to tell me how it does it; I can read code. (Of course, an explanation of your code is also nice.)
  • Produces. The value your procedure produces (the return value). (Also called Result.)
  • Preconditions. Things that have to hold in order for your procedure to work. Typically, preconditions describe the form of the parameters, the existance of other procedures or variables, or behaviours of the user. (I suppose this could also be called Requirements.)
  • Postconditions. Things that you can guarantee when your procedure is done and all the preconditions hold. Typically, postconditions say something detailed about the value produces. They may also say something about what happens to parameters (since every procedure is potentially a mutator) and about input/output. (I suppose this could be called Guarantees [sp?].)
• I only counted the first five problems, and made them worth 20 each. I gave extra credit for the last problem.
• I wanted to see sample output!
• There were some very similar very strange answers. Please be careful not to use other people's work on your take-hom exams.
• UGH means that your code was pretty damn ugly at the point I noted.

Problem One: Prompting for Desires

• Goals
• Needed better error checking.

Problem Two: Arguments

• Goals
• I expected to see good argumentation strategy (including predicting counter-arguments).
• Many of you could have used some careful editing.

Problem Three: If

• Goals
• I found it interesting that some of you described the purpose of the procedure using if, as in ``If the two people are the same, returns true.''
• I was trying to compare the given code to

  (if (equal? ...) #t #f)
  

  which I see much too often.
• Yes, you could write too much for this problem.
• I found it amusing that even after this problem, some of you wrote things like

  (if (test? x) #t #f)
  

Problem Four: Likes

• Goals
• Generally good

Problem Five: Count

• Goals
• I wasn't thrilled with the number of calls to string->list or substring.
• Notes on member.

Problem Six: Split

• Goals
• I'm not sure why you found this so hard.
• We'll go through it step by step and then discuss key issues.