• 211Guidelines
Skip to end of metadata
Go to start of metadata

How to do your Scheme homework problems

  • Recall that all homeworks should be done in pairs if possible. Each pair should submit only one copy of their assignment from the account of either partner in the pair. This directive describes how to answer both expository problems and programming problems. For detailed instructions on how to format your homework as a single (.ss) file and submit it, see the HW Checklist.

Expository problems

  • Some homework problems will be conventional expository questions that require a short written answer.
  • All of the assigned expository problems should be answered in the same Scheme .ss file as your Scheme programming exercises. Each line in the answer to an expository question should begin a "comment escape character", namely ';' as the first character on that line. Alternatively, you can enclose an entire expository problem in a Scheme box (created using the command Comment Out with a Box or in Scheme block comment brackets #| and |# (sometime called bookends). Note that you can create your entire homework file using the DrScheme editor.

Hand evaluation problems

  • Most expository problems will be hand-evaluation problems where you are asked to evaluate a particularly Scheme program invocation. You must format your hand evaluation exactly like our examples.
    • Example 1: Hand evaluation
    • Example 2: Hand evaluation

Programming problems

  • Most of your homework problems will be programming problems.
  • Half (50%) of your grade on programming problems depends on good style and following the recipe (program grading is described in detail on the homework grading page). In particular, these points will be based on
    • 25% for following the design recipe carefully and documenting your program as you are taught in course (see below), and
    • 25% for good programming style as taught in the course.
  • The other half of your grade will be based on demonstrated correctness:
    • 25% for passing all of our tests and 25% for construction; and
    • 25% for constructing a comprehensive set of unit tests for each function in your program.
  • All assigned programming problems should be done in the same .ss file.
  • At the top of your programming solution file, please put a header with the assignment number, your name and e-mail address, and your partner's name and e-mail address, like this:
  • Strictly follow the formatting and documentation directives given below under the heading Requirements. The easiest way to follow these requirements is to imitate the Sample Program solution below.

Requirements

You must include a data definition and corresponding template for each form of data processed used in your homework submissions unless instructed otherwise. You only need to include a data definition and corresponding template once for an assignment, not once for every problem that uses that data defintion.

Data Definitions and Templates:

You need to devise (and document) your data design before you start writing functions that process this data. Data definitions should be documented as follows:

  • Example 3. Data definition of shape:
  • Example 4. Data definition of list-of-numbers:
  • Once your have written a data definition, you can use it in the rest of the assignment.
  • The template for writing a function that processes a particular kind of data (data type) is based only on the corresponding data definition, not on the particular functions that you happen define on that type. Hence, there is only one template per data type. This same template is used as the starting point for writing all functions that process that data type.
  • If the type is a structure, the template should include the field extraction operations. If the type is a union, the template needs to have an appropriate cond statement (see example 3). If the type is recursive, the template includes the expected recursive calls on the recursive data components (see example 4).

Basic form of a function definition

  • The basic form for each function that you write, including axillary and local functions, is as follows:
    • Example 5. Function definition for computing area of a ring:
    • Example 6. Function definition for computing product of list-of-number:
  • Remember to follow the design recipe.
  • It is important that things are presented in this order, so that is clear that you know the correct order for doing things.
  • You are allowed to use the equal? test only for testing. You are not allowed to use it anywhere else in the code.
  • If your examples get too big, then simply define a name for that big argument somewhere before you use it. You can use this name both in your comments in the example section and in the test cases in the Tests section.
  • Be sure to test throughly. Corner cases and edge cases should be tested. For example, when dealing with numerical functions, 0 and 1 are often good test cases.
  • When testing lists, make sure you test the following cases:
    • empty list: empty
    • list with one element: ex: (cons 3 empty)
    • list with more than one element: ex: (cons 1 (cons 3 (cons 3 (cons 7 empty))))
  • Local functions cannot be tested individually, so specific tests are not required for them. However, you main function's tests need to be comprehensive enough to test the local functions.

Sample Solution to a Programming Problem

The following text is a good solution to the problem of sorting a list of numbers into ascending order; it pulls together all of the specific pieces of design documentation, code documentation, and testing mentioned above. It would be better if it included a few more appropriately chosen tests.

Note: the Examples and Tests for each function above can be collapsed into a single entry by cutting out each Tests block and pasting it over the corresponding Examples block. Forward references in check-expect invocations work because the execution of check-expect code is deferred to the end of the contents of the definitions pane. For example, the Auxiliary function part can be rewritten as follows:

4. Termination Argument: (For Chapter 23 onwards only)

If the template does not guarantee that a function terminates, you are required to explain why that function will terminate for all possible inputs.

  • Example 7. Termination argument for quick-sort :
  • No labels