Notes on Homework 4

Contents

• The Grading Technique
• Overly-Complex Code
• Testing
• Predicates
• The Six Ps
• An Easy Way to Trace Your Procedures

The Grading Technique

When I grade your assignments, I open your assignment in a text editor and in DrScheme. I execute your DrScheme file so that I have the definitions loaded and so that I may see your tests. If I cannot execute your .ss file, I know something is wrong. If I get error messages, I assume that most are due to interesting tests.

Once I've loaded your code, I read through your code and test things when I consider it appropriate to do so. I insert comments beginning with

; SR: 

whenever I have a comment on your work. Some of my comments may be positive (That's a clever way to solve the problem.). Some are simply for information purposes (You could have solved this more easily by ...). Some are serious criticisms (This code doesn't work on the following example.). For comments of the last sort, I also write PENALTY so you know that it's something that's wrong, and not something that's right or something that can be improved.

Overly-Complex Code

A number of you are making your code more complex than it needs to be. For example, in one problem, you need to ask if a number is between 0 and 100, inclusive.

One of you wrote something like.

(if (>= 100 val)
    (if (<= 0 val)
        some-special-action
        #f)
    #f)

Another wrote something like:

(if (and (>= 100 val) (<= 0 val)) 
    some-special-action   
    #f)

Why not take advantage of <='s ability to take more than two arguments and test the values in sequence?

(if (<= 0 val 100) some-special-action #f)

Many of you also seem to overuse if when you should be able to get by wich and and or.

Testing

I'd like to see more careful tests of your procedures. In particular, I'd like to see some tests in which you expect the procedure to fail badly (e.g., when given the wrong type of argument) and some of the special cases (e.g., the empty list, the one-element list).

For procedures like iota, it would have been interesting to see tests of cases close to zero, like (iota 1), (iota 0), and (iota -1).

For odds (or whatever you called it), I would have liked to have seen a variety of special cases, including the empty list, singleton lists, lists with only even numbers, lists with only odd numbers, lists with negative numbers.

Note that I find your output easier to read if you print a description of your tests before running the tests. For example,

(display "First test of odds: A list containg a variety of integers\n")
(display "(odds (list 1 8 2 99 34 21 1 2 2))\n")
(odds (list 1 8 2 99 34 21 1 2 2))
(display "Second test of odds: A list containing only even integers\n")
(display "(odds (list 2 4 6 8 10))\n")
(odds (list 2 4 6 8 10))

You are not required to do this, but it helps me (and shows me what you were thinking about when doing your tests).

Predicates

When you name predicates, make sure that the name ends with a question mark.

The Six Ps

Please be careful to use the six Ps.

Produces: Please name the value produced.

Postconditions: Remember that the postconditions should be as formal as you can make them. For example, what does it mean to be the member of a list that is closest to zero?

Note also that some of you didn't say that the result of closest-to-zero had to be a member of the original list. If you don't include that requirement in the postconditions, we could write closest-to-zero as

(define closest-to-zero
  (lambda (nums)
    0))

because 0 is closer to 0 than anything else.

An Easy Way to Trace Your Procedures

You can put display commands in the middle of your procedures and DrScheme executes them and, in essence, ignores the result. One use of this facility is printing out a trace of your procedure. For example, one of you turned in something like the following for finding the value closest to zero in a list.

(define ctz
  (lambda (lst)
    (if (null? (cdr lst))
        (car lst)
        (if (< (abs (car lst)) (abs (ctz (cdr lst))))
            (car lst)
            (ctz (cdr lst))))))

I added the trace code to get

(define ctz
  (lambda (lst)
    (display "Finding the closest-to-zero in ")
    (display lst)
    (newline)
    (if (null? (cdr lst))
        (car lst)
        (if (< (abs (car lst)) (abs (ctz (cdr lst))))
            (car lst)
            (ctz (cdr lst))))))

Here's the output from (ctz (list 5 4 3 2 1)).

Finding the closest-to-zero in (5 4 3 2 1)
Finding the closest-to-zero in (4 3 2 1)
Finding the closest-to-zero in (3 2 1)
Finding the closest-to-zero in (2 1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (2 1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (3 2 1)
Finding the closest-to-zero in (2 1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (2 1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (4 3 2 1)
Finding the closest-to-zero in (3 2 1)
Finding the closest-to-zero in (2 1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (2 1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (3 2 1)
Finding the closest-to-zero in (2 1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (2 1)
Finding the closest-to-zero in (1)
Finding the closest-to-zero in (1)
1

Doesn't that look like a lot of extra work?