[plt-scheme] 2htdp/image

I think there's a general agreement here on the basics. Two points though: 

1. Why do you think that a long list of image ops/tree nodes is more expensive than a bitmap? That's minor I think. I'd measure this first. 

2. Inexactness: Perhaps I am misunderstanding but here is what I think Robby is saying and what you are saying: 

Robby: there are exact and inexact images just like their are exact and inexact numbers. His operations preserve exactness as much as possible, just like numeric operations. (In a sense his inexactness is of course derived from the inexactness of the numbers associated with images.) 

Stephen: You are saying, deal with all images as if they were inexacts. That simplifies life and we don't need to worry about comparisons. 

The problem that I see is testing. For testing rendering functions, I'd like to exercise all my code and get an idea that they work properly. I may not test it on 10,000 shots and 3 UFOs but on 2 shots and 1 UFO and that gives me some confidence that it will draw things properly when I run the program (as opposed to testing it). 

I don't see how I can do this without comparisons, and I really dislike having to warn kids about =-comparisons for numbers on day 1. Day 38 is fine. So for images I'd like some 'exact' equality and perhaps we need an 'inexact' quality (=~) too. 

;; --- 

Does anyone know if others have turned images into first-class values and what problems they encountered and how they solved them? 

-- Matthias






On Nov 18, 2009, at 10:13 AM, Stephen Bloch wrote:

> I think this is a reasonable approach to images: by default, store them in terms of drawing primitives (so rotation, scaling, etc. work nicely) but for display and some other purposes, "flatten" them to bitmaps.  It also makes sense to have two different equality operators on images: do they have the same bit-map representation right now, and would they continue to have the same bit-map representation after rotation, reflection, scaling, etc?
> 
> So what should the drawing primitives be?  The obvious base cases (to me) are ellipses (filled or outline), polygons (filled or outline), line segments, and bitmaps.  And maybe text in a specified font.  The obvious operators, off the top of my head, are vertical and horizontal concatenation, overlay (with translation), rotation, reflection, scaling, and clipping.  Concatenation is the composition of an overlay and a translation.  Conveniently enough, rotation, reflection, translation, and scaling (as well as skewing) can all be represented as matrix multiplication, and matrix multiplication (at least in a pure, exact mathematical world) is associative, so any SEQUENCE of rotations, translations, reflections, scalings, and skews can be represented as a single matrix multiplication.  Overlay, and clipping to an arbitrary rectangular region aligned with the current coordinate system, should be trivial (although they can't be represented as matrix multiplication).
> 
> Now, about exactness.  It would be nice if (reflect-horiz (rotate 72 (rotate 200 (rotate 88 (reflect-horiz blah))))) were exactly equal to blah.  If you represent rotation, reflection, scaling, and skewing by matrix multiplication with floating-point matrix entries, it may not be.  On the other hand, if you represent each of these operations by separate tree nodes even when they're in sequence, flattening (and therefore displaying) becomes needlessly expensive, especially after you've run an animation of a spinning star for a few minutes.  Obviously, images coming from photographs should by rights be considered inexact, as should anything stored in a lossy format like JPEG... and for display on a physical monitor, we don't need exact images anyway.  Why don't we just cut the Gordian knot and say that ALL images and ALL functions on them are inexact, and you can't reasonably rely on the equality I mentioned at the top of this paragraph?  At low magnification, they may turn out to have equal bitmaps, just as the result of a floating-point computation may be within a large delta of another floating-point value, but one would no more expect exact equality on computed images than on computed inexact numbers.
> 
> Most of what I've said above applies to 3-D "images" too, of course, but that's another bucket of worms....
> 
> 
> Stephen Bloch
> sbloch at adelphi.edu
> 
> _________________________________________________
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme