Please read this entire message. Quick Notes: ----------- --Good commenting for the most part --no solutions will be posted for project 2 or later --If you turned in the extra credit, you got 2 points added to your final score. --The average score is 25.1 for my students. Guidelines ---------- --_All_ procedures you write should be commented. Note that this is _especially_ important for problems like #12 where you're given a bit of freedom in creating the procedures. Note that in #12, if you've given good names for your procedures, it's sufficient to do a block comment documenting groups of procedures like get-ccc, get-dcc, ... . --_All_ posed questions must be answered. If the assignment says to observe or explain, do so. --_All_ procedures you are required to implement should be tested. For many problems, this just means you need to run it and show the output that's already required. If you use an assert-like procedure, you don't need to show the output; just make sure the assert doesn't give an error. Things I was nice about: ----------------------- --Especially in problem 6, many people included many extra ifs/conditions that were unnecessary. In general, you should try to compact your code to simplify it and not have lots of extra cases. For problem 6, only a single if is necessary (unless you're error checking for negative or all-zero frequencies). --If you added to the history abstraction (e.g. by writing a history-length procedure), in the future you should put this procedure with the rest of the history abstraction. --On problem 9, I didn't bother marking off points for not documenting. I reserve the right to mark off for not documenting even in cases like this in the future. Type Signatures --------------- Problem 12: If we assume that the (c-count,d-count,total-count) list's type name is "outcome", make-history-summary's type is outcome,outcome,outcome -> history-summary. It is _not_ list,list,list -> list. Global Penalties ---------------- For project 2, I decided to be nice and not massively count off for repeating the same mistake (for some types of mistakes). E.g. if you never documented your code, I didn't want to count of 14-16 points from your grade. Here's the breakdown of the types of comments you'll see in your projects: #| comment |# This is just a note from me to you. No points were deducted (same as in project 1). #|+Ng Points possible: (+PPPpt) +|# Indicates the number of points possible (PPP) for problem number N (same as in project 1). #|-NXXX CCC (-PPPpt) -|# Penalty applied to problem N. PPP points were deducted from the final score. XXX is a special code just for me. Don't worry about it. CCC is an explanation of why the points were deducted (same as in project 1). #|-XXX CCC -|# This one looks like the previous type, except no explicit number of points deducted are given and no problem number is included. These are the "global penalties" applied. For each global penalty code, I counted how many times that code occurs in your project. The total penalty for each code is (sqrt num-occurrences), rounded down to the nearest half-point. So if you had four abstraction violations, you'd lose a total of 2 points on your project. Global Penalties Catalog: ------------------------ Here is a list of all the different global penalty codes I used for project 2. name: Make sure you put your name, recitation section, project number, etc. at the top of your file. exec: All non-executable text should be placed in comments 80: Except for special cases (such as printing out the matrix), all lines should be less than 80 characters wide. It makes it hard to read when I have to scroll sidewise to read your code. I may have manually reflowed some of your code to make it easier to follow. ooo: All procedures should be defined before it they are actually used. More specifically, I must be able to evaluate all expressions in your file in the order given. tc: Tests missing. Test _everything_ we ask you to implement. av: Abstraction violation (usually related to misusing history). so: Unless your tests are assertion-style, show the output. Assertion-style tests are ones where you test the output and automatically generate an error if it is not what you expected. doc: Missing documentation I hope you're enjoying your Spring Break (and having at least a little fun)! --Gerald Dalley dalleyg@mit.edu