Deliverables for the Design Recipe

The deliverables for each problem are listed below.
You must also turn in a laboratory notebook that records the time you spent on each question. The notebook should be in a file named notebook.txt The exact format of the laboratry notebook is specified here.
At the end of each work session, you must commit your work (including your laboratory notebook) to your github repository. We will assign a repository to each student. Initially, this repository will be located at https://github.com/cs5010f14/pdp-YOUR-CCIS-LOGIN-NAME . You will receive notification of the exact name of your repository. Later on, we will be creating private repositories for each pair.
You must also show this commit as an entry in your laboratory notebook.
If you do not check in your assignments nightly, we will assume that you are not working on the assignment. Checking in your partially-completed assignments also serves to prove that you actually did the assignment yourself. If you only check in the final version of your assignment, we will assume that you probably stole the code from somewhere.
Nightly check-ins mean that you will always have a backup of your work. If you screw things up, you can always revert to an earlier version.
You must commit your solutions for problem set JJ to your repository, in a folder named setJJ. Each question should be submitted as a single file in that folder, in a file named NAME.rkt, where NAME.rkt is the filename specified in the question. If the question does not specify a filename, then use K.rkt for question K. Thus, if problem set 1, question 2 does not specify a filename, then the answer should be in a file named exactly set01/2.rkt, not set1/2.rkt, Set01/2.rkt, set 1/question2.rkt, or anything else. Here I've used the Unix convention of using / to separate the components of a path name. If you do not use the proper folder and filenames for your solutions, you will break our scripts and you will be penalized.
Your homework will be collected automatically from your github repository at the date and time listed on the problem set (usually 6pm local time on Monday).
Your submission will be graded according to this rubric. The rubric will change somewhat from week to week, but this shows the general outline.
We have coding conventions. If you follow them, you will make your life and the TA's life easier.

Design Recipe Deliverables

Here are the items you need to include for each question:

For Each Data Definition:

A set of struct definitions, if necessary.
A specification of how to build values for this data definition.
An interpretation, explaining the meaning of each element in the data in terms of the information it represents.
A template for using structural decomposition on this kind of data.
Examples if they will be helpful in understanding the interpretation, or for use in tests. If the examples are primarily for use in tests, you may put them near the tests.

For Each Function:

Contract: a specification of data definitions for the arguments and the result. If you write
list-numbered : ListOf<Number> Number -> ListOf<Number>
then your function must take any list of numbers and any number and produce the output that is described by the purpose statement, unless the contract is qualified by an invariant (WHERE-clause). We will talk about WHERE-clauses in module 7.

Purpose Statement:
A short noun phrase describing what the function is supposed to return. Typically phrased in terms of information, not data. Generally takes the form GIVEN/WHERE/RETURNS, where each of these keywords is followed by a short noun phrase. Examples:
GIVEN: a temperature in Fahrenheit RETURNS: the corresponding temperature in Celsius GIVEN: a Cat c and a Scene s RETURNS: A scene like s, except that the cat c has been painted on it. GIVEN: a list of numbers lon and a number n WHERE: n = (length lon) RETURNS: a list of numbers like lon, except that each number is multiplied by its distance from the end of the list.

You may omit the GIVEN clause by referring to the givens in the RETURNS clause. Sometimes this is easier than writing a GIVENS clause, sometimes it is harder. Examples:
RETURNS: the temperature in Celsius that corresponds to the given Fahrenheit temperature. RETURNS: A scene like the given one, except that the given cat has been painted on it.

Examples

Design Strategy: the name of the design strategy used for this function. If the strategy is "structural decomposition", specify which argument and which data definition you are using. Example:
;; bombs-after-tick : ListOf<Bomb> Number -> ListOf<Bomb> ;; ...[purpose statement and examples omitted]... ;; Strategy: structural decomposition on bombs : ListOf<Bomb> (define (bombs-after-tick bombs amt) (cond [(empty? bombs) empty] [else (cons (bomb-after-tick (first bombs) amt) (bombs-after-tick (rest bombs) amt))]))

The function definition. If your strategy is "structural decomposition", then your code must match the template for the appropriate data definition.

The tests. Generally, you will define a test suite for each function by writing
(begin-for-test (check-equal? (length lobs-1) (length (bombs-after-tick lobs-1)) "bombs-after-tick did not return a list the same length as its input") ...)

Tests created with begin-for-test will be run at the end of the file.

Last modified: Mon Jul 14 22:29:34 Pacific Daylight Time 2014

Homework Policies

Design Recipe Deliverables