[racket] overlay and overlay/xy

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.engelberg at 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
> <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
>