INFORMATICS 41 • DAVID G. KAY • UC IRVINE • FALL 2011

First Homework

This homework assignment is due at the start of lab on Monday, September 26. Your TA will come around and check you off (at 2:00, for the early section).

The second homework assignment will be available on the web by next Friday and will be due the following Monday at the start of lab; we'll follow that pattern all quarter. The URL for the assignments is http://www.ics.uci.edu/~kay/courses/i41/hw; we won't distribute printed copies of the subsequent assignments (unless, after a couple of weeks, there's a great clamor for them).

Our homework assignments will include the reading in the textbook and some exercises for you to try out as you read. People learn best when they apply what they read as they go, so it's best to read the book with a computer at hand so you can type things in and try them out. There's always a big gap between thinking you understand something you read and actually being able to apply it. We expect these exercises to go quickly, but if you find yourself spending more than a couple of minutes on an exercise without making any progress, you should ask us (or a classmate) about it rather than continuing to spin your wheels unproductively. Note that this also means you should get started early, so that you'll have the time to get any questions answered.

The homework asssignments don't carry much weight in the course grade (though the lab assignments do). The point is to get you started with the next week's concepts. Thus, it's not a big deal if you don't have answers to every exercise on the homework, so long as you have questions about the ones you can't answer. In fact, we'd expect that if you run into a problem, you'll ask a classmate or send a question to i41@uci.edu even before Monday's lab.

You should also expect to find, especially after a week or two, that when you have the right answer you'll know that it's right. (Of course, having a computer to check it will help, but you will probably observe this even before you check it on the machine. This makes a contrast from the usual experience with other popular programming languages, where "Click 'Run' and cross your fingers" is the way people often work.)

(1) Do everything on the course syllabus under the heading, "What to do this week to get started in Informatics 41." This includes registering yourself at checkmate.ics.uci.edu, filling out the questionnaire at http://eee.uci.edu/survey/i41.f11.q, and turning in your photo.

(2) Read through Lab Assignment 0 before you come to lab on Friday just to get an idea of what you'll be doing with your partner.

(3) We encourage you to talk with each other and help each other understand how to do the assignments. There are some limits, though; in particular, remember that knowing how to do it (when the quiz comes, for example) is much more important than just putting down the answer. If you haven't already, read the guidelines for collaboration and independent work at http://www.ics.uci.edu/~kay/courses/i41/hw/collab.html. You may also wish to read some general advice (at http://www.ics.uci.edu/~kay/college.html) about how to approach college work; the practices that served you well in secondary school don't all work here.

(4) If you haven't already, read the guidelines for pair programming at http://www.ics.uci.edu/~kay/courses/i41/hw/pair.html. This describes how you will be doing all your work in the lab. Pair programming is not a simple as just working together; there are specific roles and specific things each person needs to do.

(5) Read Chapters 0 through 5 of the Picturing Programs textbook (PP). In most chapters, there are exercises designated "Worked Exercise." The author uses these to introduce some new concepts in the context of an actual problem. Thus, you shouldn't just glance over them quickly; you should try to follow along closely and, at least sometimes, work along with the book, typing and running the solutions in DrRacket. It's not enough just to glance over the solution and say, "Yeah, I guess that makes sense."

(5.1) In Chapter 1, write an answer to exercises 1.5.2, typing it into the definitions window of DrRacket and then running them, of course, to make sure your solution works). Remember that you need to click Run to get DrRacket to evaluate the Picturing Programs teachpack; that happens automatically when you type code in the definitions window, but if you're just typing simple expressions in the interactions window, you still need to click Run that one first time at the start of your session. Also write an answer to exercise 1.8.9, which it's easiest to do on paper.

(5.2) In Chapter 2, answer exercises 2.1.3 and 2.4.3 (which it's easiest to do on paper).

(5.3) In Chapter 3, answer exercise 3.4.4.

(5.4) In English, there's more than one way to say the same thing. "The teacher kicked the chalk" means the same as "The chalk was kicked by the teacher" (even though you can get picky about the stylistic nuances of the passive voice). The ability to paraphrase, to say the same thing in different ways, is common in natural languages (human languages). It's also common in programming languages.

Chapter 4 introduces function definitions—the fundamental way we "teach" the computer new tricks. You'll notice that in class we use one way of defining functions (called "MIT style," with lambda) while the textbook uses another way (called "Indiana style"). They both do the same thing; you'll see both ways in this course; you may use either way (though if you don't have a strong preference, use the MIT style because it will make some things easier later on).

The MIT style looks like this:

(define double    ; Define double as (lambda (n) (* 2 n)), that is, as a function 
  (lambda (n)     ; that takes one argument, n, and returns (* 2 n).
    (* 2 n)))

The Indiana style looks like this:

(define (double n)  ; Define a function double that takes one argument, n,
  (* 2 n))          ; and returns (* 2 n)

The MIT style uses the same define syntax we already know, (define name value); it's just that the value here is a function, a lambda expression. The Indiana style adds a second syntax for define: (define (name parameter1 parameter2 ...) expression) to go along with the original form of define we still use for variables.

Do the two exercises listed below for this chapter; after that, you may skip down to item (5.5), but if you'd like more details about MIT and Indiana style, read the rest of this section.

MIT and the University of Indiana are two places that have done a lot of work on Scheme over the years. Scheme was invented at MIT, in fact (based on the language Lisp, which was also invented at MIT in 1958 by John McCarthy; Lisp, in turn, was based on a kind of logic called the lambda calculus, a logic that described the behavior of functions, invented by the logician Alonzo Church). In Lisp and Scheme, it is much easier to create and manipulate functions than it is in most programming languages. A function can be treated as a piece of data in a Scheme program, just like a number or an image or a string. The Scheme term we use when we're building or describing functions is lambda. (This comes from Alonzo Church. If Greek letters bother you, just think of it as the Greek word for "function." It's not, but it doesn't hurt to think of it that way.)

Do exercise 4.2.1 (in both MIT style and Indiana style, varying the function name in the second case so you can have both definitions in the same file).

On pages 62 and 63, the textbook gives syntax rules that include a description of the Indiana style for defining functions. Rules 4 and 5 each give a different syntax for using define. For the MIT style, Rule 4 remains unchanged as the only rule for define. Rule 5 would would just describe a lambda expression as another kind of legal expression, like this:

Syntax Rule 5-MIT: A left parenthesis followed by the word lambda, a left parenthesis, one or more identifiers, a right parenthesis, a legal expression, and another right parenthesis is a legal expression. Think of it as matching the pattern (lambda (identifier ...) expression)

This sort of lambda expression's value is a function that takes as many parameters as there are identifiers. Those names can appear inside the expression as though they were defined variables; the funciton will return the value of the expression.

The MIT style makes the explicit point that functions in Scheme are "first-class objects," values that can be handled just like numbers or strings or images. We'll see some implications of this in a few weeks.

Do exercise 4.6.2 in both styles (on paper).

(5.5) In Chapter 5, do exercise 5.3.2. Note that it just asks for a contract and purpose statement; we don't know enough Scheme yet to write the actual function.

(5.6) Just skim Chapter 6 for now. It describes how to set up animations. It's fun to build animations, but they need more complicated set-up than conventional functions in DrRacket's interactions window. Despite the additional details, the underlying programming principles are the same in both contexts. We will do some animations in the lab assignments, but we won't emphasize them on the quizzes or final. Anything we ask about them won't require you to memorize the details; we'll provide whatever reference material is necessary. We also have a reference sheet on these operations that you may find useful.

(6) Look at sections A, B, and C of the Scheme Finger Exercises. If you're absolutely sure you know how to do them, you don't have to write the answers down or turn them in. But if you're still feeling a little uncertain, working through them will help build your ability.

(7) We have posted a group of short videos that cover various helpful background information. We'll expect you to watch them over the next week or so; the information could show up on quizzes.

(8) Read through Lab Assignment 1 before lab on Monday, so you have an idea of what's coming. You should take a minute to consult the DrRacket Help Desk from the Help menu; it will be useful all quarter long. Enter "Picturing Programs" in the search box and skim the documentation for the Picturing Programs teachpack. This kind of documentation describes an API, an application programming interface; an API is a library of functions that someone has added, a toolkit we can use for some task. (Don't try to learn or memorize this page; just get an overview of what's there. We'll introduce the necessary features as we go along.) Also follow the "image teachpack" link and scan that API.

What to turn in: Most of these items you just need to do on your own. At the start of lab on Monday, show the TA your solutions to the exercises in part (5) above (or let him know where you had difficulty).

Based in part on ICS H21 and H22 assignments by David G. Kay from Fall 2003 and earlier; modified by David G. Kay for the Informatics Core Course, Fall 2004–Fall 2008 (with Alex Thornton in Fall 2006 and Richard Pattis in Fall 2008). Modified for Picturing Programs by David G. Kay iin Fall 2010.