You will turn in your homework by depositing it in our subversion server. (Details)
You must turn in your solution, with one file per question, named setJJ/K.rkt for problem set JJ, question K. Thus problem set 1, question 2 should be in a file named exactly set01/2.rkt, not set1/2.rkt, Set01/2.rkt, set 1/question2.rkt, or anything else. For each question, you must include the deliverables below.
You must also turn in a laboratory notebook that records the time you spent on each question.
We have coding conventions. If you follow them, you will make your life and the TA's life easier.
Your submission will be graded according to this rubric. The rubric will change somewhat from week to week, but this shows the general outline.
Design Recipe Deliverables
Here are the items you need to include for each question:
For Each Data Definition:
- The Data Definition itself
- The interpretation of the data definition. This should explain the meaning of each element in the data in terms of the information it represents.
- Examples if they will be helpful in understanding the interpretation. You will probably need examples for your tests as well. You may put these near the data definition or near the tests, whichever is clearer.
- A template for using structural decomposition on this kind of data.
- 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:
- 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 code. 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, e.g. something like
(define-test-suite bombs-after-tick-tests (test-case "bombs-after-tick should return a list the same length as its input" (check-equal? (length lobs-1) (length (bombs-after-tick lobs-1)))) ...)and then you will run your tests with
(run-tests bombs-after-tick-tests)once all the necessary help functions are defined.
GIVEN: a temperature in Fahrenheit RETURNS: the corresponding temperature in Celsius GIVEN: a Cat c and an 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. WHERE: the number is equal to the length of the list RETURNS: a list of numbers like the given one, except that each number is multiplied by its distance from the end of the list.
- Contract: a specification of data definitions for the arguments and the result. If you write
Last modified: Tue Jan 08 20:41:46 -0500 2013