Your homework will be collected automatically from your github repository.
You must turn in your solutions for problem set JJ in a folder named setJJ. Each question should be submitted as a single file in that folder, in a onle 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 the Unix convention of using / to separate the components of a path name.] 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. The notebook should be in a file named notebook.txt
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:
- 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:
- 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, 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.
- Contract: a specification of data definitions for the arguments and the result. If you write
Last modified: Tue Oct 01 14:18:18 -0400 2013