When creating intervals that partition a one-dimensional line 
(the mathematical interval, not The Smalltalk Interval, which should be
named ArithmeticSequence) a very handy thing to is use half open
intervals, often written as: 

	[3,4)  meaning  x where  3 <= x < 4

These have the pleasing property that each point is in one, and only one
interval.  The same trick can be used to partition up a plane using
rectangles.  This is the thing Rectangle containsPoint: is doing.
Unfortunately, the regions boundary is neither open nor closed (loosely
speaking, half-open).  Often one wants a completely open or closed region.

Bummer, math is hard.  The Smalltalk graphics classes were designed to
support axis-aligned bit-mapped graphics, of which they do an adequate
job.  They are not meant to be "pressed" into more mathematical usage.
Just think about what it could possibly mean for Point <<# <
in a coordinate-free fashion (affine plane).  It is meaniningless.

Pesonally, I think a good thing would be "geometric encapsulation"
where only geometrically meaningful operations geometric object
could be performed, and the coordinates which represent said object
are encapsulated (i.e. hidden).  Internally, there would be a coordinate
frame which gives a geometric meaning to the coordinates (bunch o'numbers).

This would be analogous to the way that a class gives meaning to the
instVars of an object (bunch o' pointers).

As far as the pixel is concerned, a good article to read is:

	"What are the coordinates of a pixel?"
	Paul Heckbert, Graphics Gems, page 246-8

The short version is that there are two different kinds of coordinates,
discrete & continuous.  The pixel with discrete coordinates (x,y) has
its center at continous coordinates ( x + (1/2) , y + (1/2) ).
Of course in the current system, it's difficult to tell which is which.

-- Mike Klein

On Sat, 25 Apr 1998, Alan C. Kay wrote:

> I think you are right. You know, when Bill Atkinson did QuickDraw for the
> Mac, he came up with a useful insight: to have the coordinates be zero
> width and be located between the pixels, instead of being on the pixels.
> This has many felicitous properties and perhaps someday we should
> convert over to this convention for Squeak ....
> 
> Cheers,
> 
> Alan
> 
> -----
> 
> At 8:03 AM -0500 4/25/98, Tim Olson wrote:
> >Hi, Chris:
> >
> >>I seem to have found a bug in Rectangle.  In the method 
> >>
> >>containsPoint: aPoint 
> >>	       "Answer whether aPoint is within the receiver."
> >>	       ^origin <= aPoint and: [aPoint < corner]
> >>                                             ^^^
> >>
> >>the second comparison is a "<".  I think it should be a "<=" instead.
> >
> >I think the definition as it exists is correct (or at least internally 
> >correct and consistent as used in Squeak).  It's not explicitly stated 
> >anywhere, but a Rectangle consists of the set of points bounded by its 
> >origin and its corner, up to but not including the points on the corner's 
> >edges (right and bottom edges).
> >
> >This is because rectangles are frequently tiled, and if the exclusion 
> >didn't exist, there would be certain points that would be members of 
> >ajoining Rectangles, instead of belonging solely to one or the other.  
> >However, exclusion is fundamental to things like mouse hit detection, 
> >view layout, etc.
> >
> >Think of it this way:  if you are told to paint a rectangle on a tiled 
> >floor, starting in the corner (corner: 0 at 0) and going for one tile's 
> >length in both directions (extent: 1 at 1), you would end up with a single 
> >tile painted, and would respond "no" to the question of whether the tile 
> >at 1 at 1 was painted.
> >
> >
> >
> >     -- tim
> 
> 
>