Part A: Simple Transformations
Topics: Integer-encoded RGB colors, testing,
conditionals, numeric computation.
A simple, but common, color transformation is to flatten
a color by converting each component to one of a few selected values.
(e.g., 0, 63, 127, 191, 255).
;;; Procedure:
;;; irgb-flatten-5
;;; Parameters:
;;; color, an irgb color
;;; Purpose:
;;; "flatten" the color, making it one of a small group of similar colors.
;;; Produces:
;;; flattened, an irgb color
;;; Preconditions:
;;; [No additional.]
;;; Postconditions:
;;; All of the components are one of 0, 63, 127, 191, or 255.
;;; That is,
;;; (member? (irgb-red flattened) '(0 63 127 191 255))
;;; (member? (irgb-green flattened) '(0 63 127 191 255))
;;; (member? (irgb-blue flattened) '(0 63 127 191 255))
;;; Each of the components of flattened is near the corresponding
;;; component in color. That is.
;;; (<= (abs (- (irb-red flattened) (irgb-red color))) 32)
;;; (<= (abs (- (irb-green flattened) (irgb-green color))) 32)
;;; (<= (abs (- (irb-blue flattened) (irgb-blue color))) 32)
Because we want to do the same thing to each of the three components,
it makes sense to write a helper, flatten-component.
;;; Procedure:
;;; flatten-component-5
;;; Parameters:
;;; component, an integer
;;; Purpose:
;;; "flatten" the component to make it one of 0 63 127 191 255
;;; Produces:
;;; fc, an integer
;;; Preconditions:
;;; 0 <= component < 256
;;; Postconditions:
;;; fc is one of 0, 63, 127, 191, 255. That is,
;;; (member? fc '(0 63 127 191 255))
;;; fc is close to component. That is,
;;; (<= (abs (- fc component)) 32)
Once we've written flatten-component-5, it is
relatively easy to write irgb-flatten-5.
(define irgb-flatten-5
(lambda (color)
(irgb (flatten-component-5 (irgb-red color))
(flatten-component-5 (irgb-green color))
(flatten-component-5 (irgb-blue color)))))
Here is an incorrect implementation of flatten-component-5.
(define flatten-component-5
(lambda (component)
(if (< component 128) 0 255)))
You might want to explore what it does with a simple image.
Problem 1: Testing Flatten
Write a test suite for flatten-component-5. You
should make sure to test a variety of categories of “normal”
cases as well as appropriate “edge” cases.
You'll note that the postconditions of
flatten-component-5 are potentially a bit
vague. Suppose we had a component with a value of 95. If
flatten-component-5 transforms it to 63, we've
met both postconditions, because 63 is a member of that list and
95-63 is 32, which is less than or equal to 32. However, if
flatten-component-5 transforms 95 to 127, we've
also met both postconditions. 127 is an element of the list, and
127-95 is 32. How do we handle the possibility that
either value is correct? We focus on the
postconditions as described, rather than looking for particular
values.
(define valid-components (list 0 63 127 191 255))
(test-case "(fc5 95) is a valid component"
(check-true (member? (flatten-component-5 95) valid-components)))
(test-case "(fc5 95) is close to 95"
(check-true (<= (abs (- (flatten-component-5 95) 95)) 32)))
You will likely find it much easier to write your overall test suite if
you write one or more helper procedures.
Problem 2: A First Approach to Flattening
An obvious way to implement flatten-component-5 is
to write a conditional for each of the natural cases. For example, if
the input value is less than 32, we return 0. Use that approach
to implement flatten-component-5.
Problem 3: Another Approach to Flattening
As you may recall from the time before we learned conditionals, many of
the things that we are first inclined to write with conditionals we
can write equally well without conditionals. Implement
flatten-component-5 with an appropriate arithmetic
expression that does not involve conditionals.
Note: You may call this version
flatten-component-5-alt or something similar,
so that DrRacket does not complain about you trying to have duplicate
names in your file.
Hint: You probably want to use a combination of
addition, subtraction, multiplication, division, rounding, floor,
and ceiling. (You probably won't use all of those operations.)
Note: You are permitted to use the
values 0, 64, 128, 192, and 256 if you find that approach
easier.
Topics: Documentation, recursion, transforming images.
While the conditional and arithmetic approaches above are useful,
they are not particularly general. There are a number of ways
to generalize the “nearest value” algorithm. If the values
are equally divided (as they are in the example above), we can write
a somewhat more complex formula. But what if we want a nonlinear
division, say the values 0, 32, 64, 128, and 255? In that case, it
might make sense to make a list of possible values, and ask for the
“nearest” of those values. (As we noted in the previous
problem, there can be two nearest values. In that case, either should
be acceptable.)
In Scheme, we might describe the procedure as
(nearest val
values), and it's supposed to return
a value in values that is closest to
val.
Problem 4: Documenting nearest
Write the six-P style documentation for nearest.
Pay particular attention to the preconditions and postconditions.
Although we first came up with nearest
because we wanted to find a nearest component, note that you should
generalize the function so that it works for any reasonable number
and list.
Problem 5: Implementing nearest
Implement nearest. Given that you need to identify
an element of a list, you will likely need recursion. You will likely
find the procedure easier to write if you use helper recursion.
Problem 6: Flattening Images, Revisited
We can use the nearest procedure as part of a
broader attempt to flatten images. For example, we might write a
procedure that takes an image and a list of integers to use as
valid components.
;;; Procedure:
;;; image-flatten
;;; Parameters:
;;; image, an image id
;;; valid-components, a list of integers
;;; Purpose:
;;; "flatten" image by converting each component to a nearby value
;;; Produces:
;;; flattened, an image id
;;; Preconditions:
;;; Each element of valid-components is between 0 and 255, inclusive. That is,
;;; 0 <= (list-ref valid-components i) <= 255
;;; for any 0 <= i < (length valid-components).
;;; Postconditions:
;;; flattened is similar to image.
;;; Each component of each color in flattened is an element of
;;; valid-components. That is,
;;; (member? (irgb-component (image-get-pixel flattened col row))
;;; valid-components) for any valid
;;; column 0 <= col < (image-width image),
;;; row 0 <= row < (image-height image), and
;;; component extraction function irgb-red, irgb-green, or irgb-blue.
Implement this procedure.
Note: If you can't get nearest to work correctly,
you may use the following incorrect version. Your images will look
awful, but you can at least assure us that you understand how you
would use the function if you'd implemented it correctly.
(define nearest
(lambda (val values)
(if (and (> val 127) (not (null? (cdr values))))
(cadr values)
(car values))))
Problem 7: A decreasing? Predicate
Topics: Predicates, documentation, numeric
values.
At times, we want to know something about the relative ordering of
values in a list. For example, if we have a list of numbers (say,
representing rankings in figure skating), we might want to determine
whether the numbers are ordered in decreasing order, from largest to
smallest.
Let's start by specifying the procedure carefully. Document a
procedure, (decreasing?
numbers), that returns #f
only when any number in the list is less than the number following
it, and returns #t otherwise. In documenting this
procedure, pay particular attention to the preconditions and
postconditions.
> (decreasing? (iota 10))
#f
> (decreasing? (reverse (iota 10)))
#t
> (decreasing? (list 1/10 1/2 1/3 5/6))
#f
> (decreasing? (list 10 3 3 2 1 1 0))
#t
> (decreasing? (list 1/2 1/3 1/4 1/5 1/6))
#t
> (decreasing? (list 10))
#t
> (decreasing? null)
#t
Problem 8: Implement decreasing?
Topics: Recursion,
predicates, and, or.
Implement the decreasing? procedure that we
described and you documented in the previous problem.
While your inclination may be to write this procedure using
if (or when, or cond),
for full credit you should avoid using if (or
when or cond). Focus instead on
logical ways to combine the ways in which you know that the predicate
holds or fails to hold.
Problem 9: Transforming Color Names
Topics:
Color representations (color names and integer-encoded RGB colors),
color transformations, list iteration, composition.
In our explorations of colors, we found that we could start with a
procedure such as irgb-redder that takes a color
as a parameter and produces a new color, and use that procedure to
transform a whole image. Let's try a similar thing with lists of
color names. (Yes, it's clear that lists of color names cannot be
directly converted to images, but it is certainly possible to use them
to create images.) That is, let's consider procedures that transform
each color name in a list. Note that this process will be slightly
more difficult, because the color transformations expect integer-encoded
rgb colors rather than color names.
Write a procedure, (cnames-much-darker
color-names), that, given a list of color
names, returns a new list of color names, with each color name in the
result list an approximation of the color that results from applying
rgb-darker twice to the corresponding color in
the original list. For example,
> (cnames-much-darker (list "yellow" "green" "blue" "pink" "red" "violet" "black" "white"))
("gold" "darkgreen" "mediumblue" "tan" "red" "orchid" "black" "gainsboro")
Your procedure will look something like this.
(define cnames-much-darker
(lambda (cnames)
BODY))
Make the body of this procedure as concise as you can. You should
be able to write the body with seven units of text (variable or procedure
names), plus parentheses.
Note: Very clever programmers can use fewer than the 11 total units of
text we suggest (seven in the body and the four we provided). You
may receive a bit of extra credit if you can achieve such a solution.
Problem 10: Mystery Procedure
Topics: Code reading, procedures as parameters.
(define mystery (o rgb-list->irgb (l-s map (l-s + 32)) irgb->rgb-list))
a. Figure out what mystery does, then rename it
and write 6P documentation for it.
b. Write a seventh P, Process, that explains the
details of the underlying algorithm and how the code above manifests
an implementation of that algorithm.
This work is licensed under a
Creative Commons Attribution-NonCommercial 3.0 Unported License
.