The first one is more abstract, the second is geared to pixel
graphics-oriented interprentation of rectangles and points. In that
interpretation the components are integers representing indices in the
pixel matrix. A rectangle is interpreted as containing its top and
left sides but NOT its bottom and right sides. This may sound strange
at first, but consider that it's natural to think that a rectangle
defined as either of
100 @ 100 corner: 101 @ 101
100 @ 100 extent: 1 @ 1
is one pixel wide, which means that the pixel 100 @ 100 belongs to it
but pixel 101 @ 101 doesn't.
Perhaps a better name for containsPoint: would be containsPixel:.
--Vassili
On 4/25/07, Andres Fortier <
[hidden email]> wrote:
> hi list,
> I'm working on a r-tree implementation to hold geometrics in 2D
> and 3D. While testing it I found out something that called my attention:
>
> (2@2 extent: 1@1) contains: (3@3 extent: 0@0) -> true
> (2@2 extent: 1@1) containsPoint: 3@3 -> false
>
> Which kind of surprised me. The reason for this behaviour is clear on
> the implementation: #contains: checks for "aRectangle corner <= corner"
> while #containsPoint: checks for "aPoint < corner".
>
> Does anybody knows why is this implemented in this way? Shouldn't both
> of the above messages answer in a consistent way?
>
> Thanks in advance,
> Andrés
>
>
Locked
