Homework Policies

Home

Git and Github

Notebook

Coding Conventions

Rubric

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:
  1. A specification of how to build values for this data definition.
  2. An interpretation, explaining the meaning of each element in the data in terms of the information it represents.
  3. A template for using structural decomposition on this kind of data.
  4. 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:
  1. 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.
  2. 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 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.
      

  3. Examples
  4. 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))])) 
     

  5. The function definition. If your strategy is "structural decomposition", then your code must match the template for the appropriate data definition.
  6. 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.

---

Last modified: Tue Oct 01 14:18:18 -0400 2013