On May 19, 2012, at 11:01 AM, Danny Heap wrote:
> I wrote a small module for the convenience of my students in
> manipulating image color-lists in 2htdp/image.
You might take a look at the picturing-programs teachpack, which does a lot of
this stuff already. In particular, it provides
map-image (which applies a specified function to each pixel of an image,
theoretically in parallel, producing an image the same size and shape)
build-image (which applies a specified function to each ordered pair in
{0..width-1) x (0--height-1), producing an image of the specified size and
shape)
fold-image (which applies a specified function to each pixel of an image
successively, with the result of each being fed into the next).
There are several variants of these. For example, map-image checks whether its
function argument has arity 1 or 3: if 1, it gives that function just the
color, and if 3, it also gives it the (x,y) coordinates, so you can do
location-dependent manipulations.
> I want them
> to be able to create a new color one band at a time, and in my draft I
> have, for instance:
>
> ; new-red : number color -> color
> ; Produces a new color by replacing
> ; the red intensity of col by val.
> (define (new-red val col) ...)
That's a very different approach, but I think it's motivated by the same
pedagogical impulse -- I wanted students to be able to do pixel manipulation
before they knew about structs -- that led me to write map3-image and
build3-image. These take 3 separate function arguments (one producing the red
component, one green, and one blue); in addition, map3-image gives its
functions the red, green, and blue components of the input pixel separately
rather than passing in a color struct.
In practice, I've found that map3-image and build3-image are a pain to use in
the classroom, because you have to write three separate functions before you
can use them. So what I did this semester was introduce "make-color" very
early -- the second week of the semester -- so students could use build-image
immediately, and so they would get a lot of practice BUILDING color structs
before they ever had to take one apart. I postponed map-image until they had
seen color-red, color-green, and color-blue. That's not ideal either, but I
think it worked reasonably well.
> Is there a convention for naming, rather than new-???, that makes it
> obvious that there is no mutation going on?
We've been discussing that, in connection with the plan for define-struct (in
student languages) to provide such "functional setters" for ALL structs, not
just colors. No resolution yet, AFAIK :-(
> I also included an image comprehension, for/image, to suppress the
> details of image->color-list, followed by color-list->bitmap, in
> transforming an image. I read some of the discussion on preferring
> map over the for- comprehensions, but I want to allow my students to
> transform colors at the expression level, without the overhead of
> functions, named or anonymous. Are there grievous pedagogical
> implications I should be aware of?
I don't know about "grievous", but I think this sort of image manipulation
gives students the motivation to practice writing (typically very short and
simple) functions, which is a good thing. I have them practice writing
expressions at the "image" level for a week or so before starting them on
functions, but then I tell them "Get used to writing functions: you'll write at
least a hundred of them in the remainder of the semester."
If you have suggestions for other image utilities like this, talk to me
off-list and we can include them in picturing-programs, which has the advantage
of being bundled with DrRacket so there's no separate installation procedure.
Stephen Bloch
sbl...@adelphi.edu
____________________
Racket Users list:
http://lists.racket-lang.org/users
