Well, I thought I'd done what Don suggested and unfortunately now the deadline for feedback has passed, making it difficult to change things (impossible for the current release of course). So I think the best thing is probably just to experiment with the current set in your class and perhaps give me feedback in a month or so.
Thanks, Robby On Wed, Aug 3, 2011 at 3:16 PM, Mark Engelberg <mark.engelb...@gmail.com> wrote: > Just getting ready for the new year, and looking closely at the > changes to the image teachpack. > > I like that there is now a version of overlay that works as an offset > from the middle-middle point, but it doesn't address Don's second > observation that the semantics of overlay/offset feel backwards. As > he points out, it is far more intuitive for the offset to apply to > image1 than image2. Any particular reason you chose to stick with > this seemingly "backwards" behavior? If so, it would help to > understand the reasoning so that I can explain it to my students. > > Thanks, > > Mark > > On Sun, Feb 20, 2011 at 1:43 PM, Robby Findler > <ro...@eecs.northwestern.edu> wrote: >> This thread seems to have died down so I took what I thought was the >> best idea, namely doing what Don suggests but giving the function a >> new name (I took the one suggested by Stephen). So now we have >> overlay/offset, underlay/offset, overlay/align/offset, and >> underlay/align/offset (just pushed to git). If you pass 0 and 0 for >> the x and y arguments, then you get functions that behave like the >> versions without the word "offset" in them (restricted to two >> arguments, of course). >> >> We have a few months before the next release, and feedback before that >> time would be appreciated. >> >> Thanks, >> Robby >> >> On Sun, Jan 30, 2011 at 8:40 PM, Don Blaheta <dblah...@monm.edu> wrote: >>> I shifted entirely to using 2htdp/image this semester; now all >>> the pinhole stuff is gone and we can do "image arithmetic" with various >>> combinations of overlay, underlay, above, and beside, which is great. >>> >>> The problem is, overlay/xy now sticks out like a weird wart on the >>> system, and it's profoundly counterintuitive to my students (and me, >>> actually), in at least two important ways: >>> >>> 1) One might expect the following two expressions to yield the same >>> result: >>> >>> (overlay red-circ black-sq) >>> (overlay/xy red-circ 0 0 black-sq) >>> >>> but they don't. All the base image arithmetic functions default to >>> aligning at the middle, but overlay/xy doesn't. Which means that if >>> (overlay a b) is almost what you want, but just requires a nudge of a >>> few pixels, you can't just start with an overlay/xy with offset of 0 0 >>> and tweak from there. >>> >>> This expectation doesn't only come from the time-honoured "guess based >>> on the function name" strategy; it's also based on the description in >>> the documentation: >>> >>> Constructs an image by overlaying i1 on top of i2 after shifting i2 over >>> by x pixels to the right and y pixels down. >>> >>> which would lead you to believe that it's just like overlay, except with >>> an offset. The docs could be clarified here, but that just raises the >>> further question, "why is overlay/xy based on a top-left alignment but >>> overlay based on a middle-middle alignment?" Who knows? >>> >>> 2) The semantics of the offset are backwards. Or at least, they feel >>> backwards. When my students typed >>> >>> (overlay/xy red-circ 10 0 black-sq) >>> >>> they expected the red circle to be overlaid atop the black square and >>> offset to the right by ten pixels; but in fact it is the reverse. The >>> natural interpretation of this is *not* "oh it's the black square that >>> got shifted to the right", but rather, "why is the red circle shifted to >>> the left when I gave it a positive offset?" That's because it's the >>> red circle being overlaid, so you expect it's also the red circle that >>> gets shifted. (The confusion here is only magnified by a confound with >>> the y-increases-down property of the graphics system.) I assume this is >>> effectively a holdover from version 1 of the library, where it was the >>> the second image overlaid upon the first, and thus it made sense for the >>> second image to be the one that was offset, but it's still confusing >>> (although here at least the documentation is correct). >>> >>> >>> The net effect is that the only reliable way to use overlay/xy is to try >>> a bunch of different numbers until one looks right, which is a big pain >>> but less of a pain than having to figure out the weird offsets and >>> backwards semantics of the function. I'm trying to decide if I can just >>> tell them to avoid overlay/xy entirely, but I don't think I can---although >>> place-image is great, sometimes you need an offset without cropping. >>> >>> -- >>> -=-Don >>> Blaheta-=-dblah...@monm.edu-=-=-<http://www.monmsci.net/~dblaheta/>-=- >>> "On two occasions I have been asked [by members of Parliament!], `Pray, >>> Mr. Babbage, if you put into the machine wrong figures, will the right >>> answers come out?' I am not able rightly to apprehend the kind of >>> confusion of ideas that could provoke such a question." >>> --Charles Babbage >>> _________________________________________________ >>> For list-related administrative tasks: >>> http://lists.racket-lang.org/listinfo/users >>> >> >> _________________________________________________ >> For list-related administrative tasks: >> http://lists.racket-lang.org/listinfo/users > _________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
