CSC151 2007S, Class 22: Pause for Breath (1): A Review Admin: * Don't forget Monday's talk on Mourning in the Civil War. 4:15 ARH 102. * DON'T REDEFINE STANDARD PROCEDURES, LIKE list (define list (cons 5 null)) (list 1 2 3) BOOM * Today will be a lecture/recitation day. * No reading for Monday * No homework for Tuesday Overview: * A different kind of problem * rgb-list.brightest, revisited * The need for documentation. * The Six P's - a strategy for documenting procedures. * Practice. /A Different Kind of Problem/ * Recent observations (not just my own) * About half of you are getting through most of this material pretty smoothly * About half of you are having significant difficulties * The other class also has a split, but with a smaller percentage having difficulty (more than we traditionally have, but still fewer than in this class) * Emily tells me that she thinks there are students having difficulties in both classes, but that they seem to show up in the labs at different times. * We're using the same materials (most of which I'm writing) * I apologize: I've seen the difficulties, and haven't had the time to think about how best to address them. * As a class, I'd like us to discuss what to do. * Step one: Please classify yourselves (eyes closed) * Having Significant Difficulties - Consistently having problems; rarely get more than a few problems done on lab or homework (5) * Somewhere in the Middle - Many things make sense, but still encountering regular problems (11) * Going Okay - Most things make sense, with the occasional problem (10) * Some solutions * More time going over examples in class ** * Don't make the homework much different than the other work we've been doing * Don't be so insulting * Problem of sequencing in homework and labs - If you don't get one thing done, you won't be able to do the next * More time for labs ** * Give us answers * First implemented solution: Two or three days of review * For this to work, you must be willing to say "Stop! I don't understand" * The more I talk, the more bad jokes I will make. * If you are confident in how things are going, you may email me for permission to miss class. * Next solutions: Shorter labs, with introductory comments and the occasional solution appearing in the lab. Computer science is the study of algorithms + data * How to represnt information * How to process information * Expressed in an unnatural language: Scheme As we write these instructions, we need some basic tools: * "Built in" data types, e.g., numbers * Operations on those types * Ways of building new types * Taught it about "spots" * Ways to name things * Ways to sequence operations * Put 'em in order * The compose operation: * Nesting: When operations to compute appear within each other, the computer can figure out which to do first * Ways to choose between operations/activities * Ways to repeat operations on collections of information * Ways to define our own operations (procedures, functions) These tools need concrete expression in a language (in this case, Scheme) * Basics of Scheme: A language used to express programs that solve problems * Scheme is a langauge in which you must write and match parentheses * Most of the time you want to apply a function to some parameters write open-paren function parameters close-paren (+ 1 2) (sqrt 123) (map rgb.redder my-list-of-favorite-colors) * Conversely, almost every time Scheme sees an open paren, it assumes that you're writing a function * "Built in" data types, * numbers with a host of mathematical operations * +, -, *, /, the evil and confusing mod * some special values, like pi (and maybe e) * colors * Many kinds * rgb colors * color names * ... * Values: color.red, color.green, color.puce, color.ultra-violet-wicked-cool-blue * Operations * booleans - * Two values, true (#t), false (#f) * Three? operations: and, or, not * strings (not studied explicitly) * positions * images * Ways of building new types * Lists * Types we've built: spots, lists of spots * Vectors * Ways to name things (values) (define NAME EXPRESSION_THAT_COMPUTES_VALUE) * Ways to sequence operations * Put 'em in order * The compose operation: * Nesting: When operations to compute appear within each other, the computer can figure out which to do first * Ways to choose between operations/activities (if TEST CONSEQUENT ALTERNATE) * If one thing happens, use one answer, if another thing happens, use the alternate * Evaluate the test. If the test returns true, evaluates the consequent. If the test returns false, evaluates the alternate * If the test is neither true nor false, we would hope to get an error message Instead, we see that it behaves as if the non-boolean value is TRUE (cond (test1 result1) ... (testn resultn) (else alternative)) * Goes through a number of tests. If none of them are true, it gives back the value of the alternative. Stops at the first true test (that is, doesn't check any subsequent tests) AND returns the corresopnding result. Emily also notes that the tests are done in order. In addition to cond and if, we can use "ungodly amounts of ands and ors" * Ways to repeat operations on collections of information * Most general technique: Recursion * image.map, image.map!, region.compute-pixels! * Why would you use image.map instead of image.map! (or vice versa) * If we want to compare the original and modified, we should use image.map * If we want to create a number of variants of the original, we should use image.map * Sometimes you don't want to make more images (e.g., if you're worried about running out of memory on the computer), use image.map! * map, foreach! * Ways to define our own operations (procedures, functions) NEXT CLASS EMAIL ME THINGS (OTHER THAN RECURSION) THAT YOU'D LIKE ME TO GO OVER ON MONDAY * If there's time to do recursion on Monday, we'll do it automatically. * Otherwise, we'll do it on Tuesday.