How to do your Racket homework problems
- this directive describes how to answer both expository problems and programming problems. For detailed instructions on how to format your homework as a single (.rkt) file and submit it, see the Racket HW Checklist.
- 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 Racket
.rktfile as your Racket programming exercises. Of course, you "comment out" each answer either by:
- Beginning each line in the answer to an expository question with the comment escape character ; (semicolon) ; or
- Enclosing the entire expository answer in a Racket comment box created using Racket block comment brackets
|#(sometimes called bookends).
- Note that you can create your entire homework file including solutions to expository problems using the DrRacket editor.
Hand evaluation problems
- Most expository problems will be hand-evaluation problems where you are asked to evaluate a particular Racket program invocation. You must format your hand evaluation exactly like our examples (except you will need to insert a comment escape character if the evaluation is embedded in a Racket file with executable Racket code.
Example 1: Hand evaluation
Example 2: Hand evaluation
- 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
- 30% for following the design recipe carefully and documenting your program as you are taught in this course (see below), and
- 20% for good programming style as taught in the course.
- The other half of your grade will be based on demonstrated correctness:
- 30% for passing all of our tests; and
- 20% for constructing a comprehensive set of unit tests for each function in your program.
- All assigned programming problems should be done in the same
At the top of your programming solution file, please put a header with the assignment number, your name, and your 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.
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
condstatement (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
definea 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,
1are often good test cases.
- When testing lists, make sure you test the following cases:
- empty list:
- list with one element: ex:
(cons 3 empty)
- list with more than one element: ex:
(cons 1 (cons 3 (cons 3 (cons 7 empty))))
- empty list:
- 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