[racket] overlay and overlay/xy

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
<robby at 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 <dblaheta at 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-=-dblaheta at 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