intersect: when intsersects: is false

> [Using Squeak 3.8; apologies if more current versions "fix" this ... ]
>
> This expression yields false:
>
> ((0@0) corner: (50@50)) intersects: ((100@100) corner: (150@150))
>
> So, what should this yield?:
>
> ((0@0) corner: (50@50)) intersect: ((100@100) corner: (150@150))
>
> I was expecting perhaps nil. Instead I got (100@100) corner: (50@50).
> This is "a surprise". It's certainly not right mathematically ...

> On 2010/06/20 00:58, Jim Rosenberg wrote:
>> [Using Squeak 3.8; apologies if more current versions "fix" this ... ]
>>
>> This expression yields false:
>>
>> ((0@0) corner: (50@50)) intersects: ((100@100) corner: (150@150))
>>
>> So, what should this yield?:
>>
>> ((0@0) corner: (50@50)) intersect: ((100@100) corner: (150@150))
>>
>> I was expecting perhaps nil. Instead I got (100@100) corner: (50@50).
>> This is "a surprise". It's certainly not right mathematically ...
>
> It's still that way in trunk, at any rate.
>
> I do think that the current behaviour's wrong.
>
> In the interest of keeping the result of a #intersect: uniform, we could
> return Rectangle origin: (0@0) corner: (0@0) instead of nil. (And we can
> put that long expression inside a new method,
> Rectangle>>emptyRectangle.) Then we could compose multiple #intersect:s
> without special-casing anything.
>
> I think we just need a guard clause like
>
>      | aPoint left right top bottom |
>      (self intersects: aRectangle) ifFalse: [^ self emptyRectangle].
>
>      "Rest of #intersect goes here."
>
> but I'm sure Nicolas Cellier will weigh in with a definitive answer :)
>
> frank
>

> Whatever is thought to be the "correct" answer, please have a look at the
> result of this method in other Smalltalk dialects. I recently had the
> unpleasant experience of having to work around minor incompatibilities
> between VisualWorks, Squeak and Pharo. Please don't add another one. OTOH,
> if it is already different, that would a chance for unification.
>
> >From the point of view of correctness: There is no such thing as a Rectangle
> which is the intersection of non-intersecting rectangles. The "correct"
> answer could be to raise an exception, similar to what happens for a
> division by zero, or to answer nil. Both would certainly break a lot of
> existing code. (0@0) corner: (0@0) is completely wrong IMO. While it is
> empty in a mathematical sense, it would give you answers for #origin and
> #corner and many other messages which are complete nonsense. One could just
> leave it as it is, because the precondition for answering a "correct"
> rectangle is that the receiver and the argument intersect. If the don't, the
> answer is undefined, which means that whatever is answered is correct in a
> mathematical sense. So the third option besides nil and an exception would
> be to document the precondition in the method's comment.
>
> Whatever you do, please keep it compatible with other Smalltalk dialects!
>
> Just my 2c.
> Joachim Geidel
>
> Am 20.06.10 10:36 schrieb Frank Shearar:
>
>> On 2010/06/20 00:58, Jim Rosenberg wrote:
>>> [Using Squeak 3.8; apologies if more current versions "fix" this ... ]
>>>
>>> This expression yields false:
>>>
>>> ((0@0) corner: (50@50)) intersects: ((100@100) corner: (150@150))
>>>
>>> So, what should this yield?:
>>>
>>> ((0@0) corner: (50@50)) intersect: ((100@100) corner: (150@150))
>>>
>>> I was expecting perhaps nil. Instead I got (100@100) corner: (50@50).
>>> This is "a surprise". It's certainly not right mathematically ...
>>
>> It's still that way in trunk, at any rate.
>>
>> I do think that the current behaviour's wrong.
>>
>> In the interest of keeping the result of a #intersect: uniform, we could
>> return Rectangle origin: (0@0) corner: (0@0) instead of nil. (And we can
>> put that long expression inside a new method,
>> Rectangle>>emptyRectangle.) Then we could compose multiple #intersect:s
>> without special-casing anything.
>>
>> I think we just need a guard clause like
>>
>>      | aPoint left right top bottom |
>>      (self intersects: aRectangle) ifFalse: [^ self emptyRectangle].
>>
>>      "Rest of #intersect goes here."
>>
>> but I'm sure Nicolas Cellier will weigh in with a definitive answer :)
>>
>> frank
>>
>
>
>
>

> 2010/6/20 Joachim Geidel <[hidden email]>:
>> Whatever is thought to be the "correct" answer, please have a look at the
>> result of this method in other Smalltalk dialects. I recently had the
>> unpleasant experience of having to work around minor incompatibilities
>> between VisualWorks, Squeak and Pharo. Please don't add another one. OTOH,
>> if it is already different, that would a chance for unification.
>>
>> >From the point of view of correctness: There is no such thing as a Rectangle
>> which is the intersection of non-intersecting rectangles. The "correct"
>> answer could be to raise an exception, similar to what happens for a
>> division by zero, or to answer nil. Both would certainly break a lot of
>> existing code. (0@0) corner: (0@0) is completely wrong IMO. While it is
>> empty in a mathematical sense, it would give you answers for #origin and
>> #corner and many other messages which are complete nonsense. One could just
>> leave it as it is, because the precondition for answering a "correct"
>> rectangle is that the receiver and the argument intersect. If the don't, the
>> answer is undefined, which means that whatever is answered is correct in a
>> mathematical sense. So the third option besides nil and an exception would
>> be to document the precondition in the method's comment.
>>
>> Whatever you do, please keep it compatible with other Smalltalk dialects!
>>
>> Just my 2c.
>> Joachim Geidel
>>
>> Am 20.06.10 10:36 schrieb Frank Shearar:
>>
>>> On 2010/06/20 00:58, Jim Rosenberg wrote:
>>>> [Using Squeak 3.8; apologies if more current versions "fix" this ... ]
>>>>
>>>> This expression yields false:
>>>>
>>>> ((0@0) corner: (50@50)) intersects: ((100@100) corner: (150@150))
>>>>
>>>> So, what should this yield?:
>>>>
>>>> ((0@0) corner: (50@50)) intersect: ((100@100) corner: (150@150))
>>>>
>>>> I was expecting perhaps nil. Instead I got (100@100) corner: (50@50).
>>>> This is "a surprise". It's certainly not right mathematically ...
>>>
>>> It's still that way in trunk, at any rate.
>>>
>>> I do think that the current behaviour's wrong.
>>>
>>> In the interest of keeping the result of a #intersect: uniform, we could
>>> return Rectangle origin: (0@0) corner: (0@0) instead of nil. (And we can
>>> put that long expression inside a new method,
>>> Rectangle>>emptyRectangle.) Then we could compose multiple #intersect:s
>>> without special-casing anything.
>>>
>>> I think we just need a guard clause like
>>>
>>>      | aPoint left right top bottom |
>>>      (self intersects: aRectangle) ifFalse: [^ self emptyRectangle].
>>>
>>>      "Rest of #intersect goes here."
>>>
>>> but I'm sure Nicolas Cellier will weigh in with a definitive answer :)
>>>
>>> frank
>>>
>>
>>
>>
>>
>
> Well, I never have a definitive answer - though I pedantically may seem to :)...
> What I usually suggest is to put enough brain storming to help
> reaching an answer that is least surprising indeed.
> To me, least-surprising includes:
> - uniform thru the library
> - mathematically well grounded
> The other rationale to be taken into account is simplicity.
> And of course, cross-dialect compatibility is another pragmatic POV.
>
> Nicolas
>

> 2010/6/20 Joachim Geidel <[hidden email]>:
>> Whatever is thought to be the "correct" answer, please have a look at the
>> result of this method in other Smalltalk dialects. I recently had the
>> unpleasant experience of having to work around minor incompatibilities
>> between VisualWorks, Squeak and Pharo. Please don't add another one. OTOH,
>> if it is already different, that would a chance for unification.
>>
>> >From the point of view of correctness: There is no such thing as a Rectangle
>> which is the intersection of non-intersecting rectangles. The "correct"
>> answer could be to raise an exception, similar to what happens for a
>> division by zero, or to answer nil. Both would certainly break a lot of
>> existing code. (0@0) corner: (0@0) is completely wrong IMO. While it is
>> empty in a mathematical sense, it would give you answers for #origin and
>> #corner and many other messages which are complete nonsense. One could just
>> leave it as it is, because the precondition for answering a "correct"
>> rectangle is that the receiver and the argument intersect. If the don't, the
>> answer is undefined, which means that whatever is answered is correct in a
>> mathematical sense. So the third option besides nil and an exception would
>> be to document the precondition in the method's comment.
>>
>> Whatever you do, please keep it compatible with other Smalltalk dialects!
>>
>> Just my 2c.
>> Joachim Geidel
>>
>> Am 20.06.10 10:36 schrieb Frank Shearar:
>>
>>> On 2010/06/20 00:58, Jim Rosenberg wrote:
>>>> [Using Squeak 3.8; apologies if more current versions "fix" this ... ]
>>>>
>>>> This expression yields false:
>>>>
>>>> ((0@0) corner: (50@50)) intersects: ((100@100) corner: (150@150))
>>>>
>>>> So, what should this yield?:
>>>>
>>>> ((0@0) corner: (50@50)) intersect: ((100@100) corner: (150@150))
>>>>
>>>> I was expecting perhaps nil. Instead I got (100@100) corner: (50@50).
>>>> This is "a surprise". It's certainly not right mathematically ...
>>>
>>> It's still that way in trunk, at any rate.
>>>
>>> I do think that the current behaviour's wrong.
>>>
>>> In the interest of keeping the result of a #intersect: uniform, we could
>>> return Rectangle origin: (0@0) corner: (0@0) instead of nil. (And we can
>>> put that long expression inside a new method,
>>> Rectangle>>emptyRectangle.) Then we could compose multiple #intersect:s
>>> without special-casing anything.
>>>
>>> I think we just need a guard clause like
>>>
>>>      | aPoint left right top bottom |
>>>      (self intersects: aRectangle) ifFalse: [^ self emptyRectangle].
>>>
>>>      "Rest of #intersect goes here."
>>>
>>> but I'm sure Nicolas Cellier will weigh in with a definitive answer :)
>>>
>>> frank
>>>
>>
>>
>>
>>
>
> Well, I never have a definitive answer - though I pedantically may seem to :)...
> What I usually suggest is to put enough brain storming to help
> reaching an answer that is least surprising indeed.
> To me, least-surprising includes:
> - uniform thru the library
> - mathematically well grounded
> The other rationale to be taken into account is simplicity.
> And of course, cross-dialect compatibility is another pragmatic POV.
>
> Nicolas
>

> Playing with empty rectangles:
> (I'll try to not get caught by a premature gmail send shortcut)
>
> (0@0 corner: 0@0) containsPoint: 0@0 -> false.
> Thus, yes, it is an empty rectangle.
>
> (0@0 corner: -1 @ -1) = (0@0 corner: 0@0) -> false.
> Two empty rectangles can be different though...
>
> (100 @ 100 corner: 50 @ 50) center -> (75@75).
> Des not have the same center as (0@0 corner: 0@0).
>
> ((0@0 corner: 0@0) merge: (100 @ 100 corner: 50 @ 50)) -> (0@0 corner: 50@50).
> Merging two empty rectangles can result in a non empty rectangle.
>
>  (100 @ 100 corner: 50 @ 50) area -> 0.
>
> ((0@0 corner: 0@0)  pointNearestTo: 50@100) -> (0@0).
> ((0@0 corner: -1 @ -1)  pointNearestTo: 50@100) -> (-1@-1).
> ((100 @ 100 corner: 50 @ 50) pointNearestTo: 50@100) -> (50@50).
>
> ((100@100 corner: 50@50) intersects: (40@40 corner: 110@110)) -> true.
> ((100@100 corner: 50@50) intersect: (40@40 corner: 110@110)) ->
> (100@100 corner: 50@50).
> An empty rectangle can intersect a non empty one, though the
> intersection is an empty rectangle. Funny...
>
> All in all, it may not be a good idea to return (0@0 corner: 0@0) in
> all cases...
> It is just another empty rectangle, maybe not the one you want.
> Maybe we could just implement #isEmpty...
> Oh wait, it is just named #hasPositiveExtent.
>
> Nicolas
>
> 2010/6/20 Nicolas Cellier <[hidden email]>:
>> 2010/6/20 Joachim Geidel <[hidden email]>:
>>> Whatever is thought to be the "correct" answer, please have a look at the
>>> result of this method in other Smalltalk dialects. I recently had the
>>> unpleasant experience of having to work around minor incompatibilities
>>> between VisualWorks, Squeak and Pharo. Please don't add another one. OTOH,
>>> if it is already different, that would a chance for unification.
>>>
>>> >From the point of view of correctness: There is no such thing as a Rectangle
>>> which is the intersection of non-intersecting rectangles. The "correct"
>>> answer could be to raise an exception, similar to what happens for a
>>> division by zero, or to answer nil. Both would certainly break a lot of
>>> existing code. (0@0) corner: (0@0) is completely wrong IMO. While it is
>>> empty in a mathematical sense, it would give you answers for #origin and
>>> #corner and many other messages which are complete nonsense. One could just
>>> leave it as it is, because the precondition for answering a "correct"
>>> rectangle is that the receiver and the argument intersect. If the don't, the
>>> answer is undefined, which means that whatever is answered is correct in a
>>> mathematical sense. So the third option besides nil and an exception would
>>> be to document the precondition in the method's comment.
>>>
>>> Whatever you do, please keep it compatible with other Smalltalk dialects!
>>>
>>> Just my 2c.
>>> Joachim Geidel
>>>
>>> Am 20.06.10 10:36 schrieb Frank Shearar:
>>>
>>>> On 2010/06/20 00:58, Jim Rosenberg wrote:
>>>>> [Using Squeak 3.8; apologies if more current versions "fix" this ... ]
>>>>>
>>>>> This expression yields false:
>>>>>
>>>>> ((0@0) corner: (50@50)) intersects: ((100@100) corner: (150@150))
>>>>>
>>>>> So, what should this yield?:
>>>>>
>>>>> ((0@0) corner: (50@50)) intersect: ((100@100) corner: (150@150))
>>>>>
>>>>> I was expecting perhaps nil. Instead I got (100@100) corner: (50@50).
>>>>> This is "a surprise". It's certainly not right mathematically ...
>>>>
>>>> It's still that way in trunk, at any rate.
>>>>
>>>> I do think that the current behaviour's wrong.
>>>>
>>>> In the interest of keeping the result of a #intersect: uniform, we could
>>>> return Rectangle origin: (0@0) corner: (0@0) instead of nil. (And we can
>>>> put that long expression inside a new method,
>>>> Rectangle>>emptyRectangle.) Then we could compose multiple #intersect:s
>>>> without special-casing anything.
>>>>
>>>> I think we just need a guard clause like
>>>>
>>>>      | aPoint left right top bottom |
>>>>      (self intersects: aRectangle) ifFalse: [^ self emptyRectangle].
>>>>
>>>>      "Rest of #intersect goes here."
>>>>
>>>> but I'm sure Nicolas Cellier will weigh in with a definitive answer :)
>>>>
>>>> frank
>>>>
>>>
>>>
>>>
>>>
>>
>> Well, I never have a definitive answer - though I pedantically may seem to :)...
>> What I usually suggest is to put enough brain storming to help
>> reaching an answer that is least surprising indeed.
>> To me, least-surprising includes:
>> - uniform thru the library
>> - mathematically well grounded
>> The other rationale to be taken into account is simplicity.
>> And of course, cross-dialect compatibility is another pragmatic POV.
>>
>> Nicolas
>>
>

> Hello,
>
> Am 2010-06-20 um 15:02 schrieb Nicolas Cellier:
>
>> ((100@100 corner: 50@50) rotateBy: #pi centerAt: 0@0) area -> 2500.
>> Rotating an empty rectangle does not preserve its emptyness.
>
>
> Why shall (100@100 corner: 50@50) be an empty rectangle?
> I do not understand. Especially, why is
> (100@100 corner: 50@50) = (50@50 corner: 100@100)
> false?
> Isn't it just the same Rectangle, albeit, rotated?
>
> So Long,
>        -Tobias
>

> On Sun, 20 Jun 2010 11:07:23 +0200, Joachim Geidel
> <[hidden email]> wrote:
>
>>snip...
>>One could just
>>leave it as it is, because the precondition for answering a "correct"
>>rectangle is that the receiver and the argument intersect. If they don't, the
>>answer is undefined, which means that whatever is answered is correct in a
>>mathematical sense.
>>snip...
>
> I urge some caution here.  If "whatever is answered is correct in a
> mathematical sense" is true then returning any rectangle like (100@100)
> corner: (150@150) would be correct, clearly that is not the case.  In
> Smalltalk, nil is undefined, nil is probably the "correct" answer.

>>>snip...
>>>One could just
>>>leave it as it is, because the precondition for answering a "correct"
>>>rectangle is that the receiver and the argument intersect. If they don't, the
>>>answer is undefined, which means that whatever is answered is correct in a
>>>mathematical sense.
>>>snip...
>>
>> I urge some caution here.  If "whatever is answered is correct in a
>> mathematical sense" is true then returning any rectangle like (100@100)
>> corner: (150@150) would be correct, clearly that is not the case.  In
>> Smalltalk, nil is undefined, nil is probably the "correct" answer.
>
>Yes, this is tempting.
>However from a pragmatic point of view that would mean that:
>- either every call must be protected with an intersects: test or (...
>intersect ...) ifNil: [...]
>- or UndefinedObject must understand Rectangle protocol
>Answering an empty rectangle seems more simple with this respect.
>Nicolas

>>>> snip...
>>>> One could just
>>>> leave it as it is, because the precondition for answering a "correct"
>>>> rectangle is that the receiver and the argument intersect. If they don't, the
>>>> answer is undefined, which means that whatever is answered is correct in a
>>>> mathematical sense.
>>>> snip...
>>>
>>> I urge some caution here.  If "whatever is answered is correct in a
>>> mathematical sense" is true then returning any rectangle like (100@100)
>>> corner: (150@150) would be correct, clearly that is not the case.  In
>>> Smalltalk, nil is undefined, nil is probably the "correct" answer.
>>
>> Yes, this is tempting.
>> However from a pragmatic point of view that would mean that:
>> - either every call must be protected with an intersects: test or (...
>> intersect ...) ifNil: [...]
>> - or UndefinedObject must understand Rectangle protocol
>> Answering an empty rectangle seems more simple with this respect.
>> Nicolas
>
> As I don't play with rectangles much, I will defer to your better judgment.
> Mostly I was concerned about the "whatever is answered is correct in a
> mathematical sense" statement but maybe I was being too picky.  And why I
> quoted "correct" when I said nil was probably the "correct" answer. Correct
> or not an empty rectangle is probably the "better" answer.

>On 2010/06/21 16:03, Louis LaBrunda wrote:
>>>>> snip...
>>>>> One could just
>>>>> leave it as it is, because the precondition for answering a "correct"
>>>>> rectangle is that the receiver and the argument intersect. If they don't, the
>>>>> answer is undefined, which means that whatever is answered is correct in a
>>>>> mathematical sense.
>>>>> snip...
>>>>
>>>> I urge some caution here.  If "whatever is answered is correct in a
>>>> mathematical sense" is true then returning any rectangle like (100@100)
>>>> corner: (150@150) would be correct, clearly that is not the case.  In
>>>> Smalltalk, nil is undefined, nil is probably the "correct" answer.
>>>
>>> Yes, this is tempting.
>>> However from a pragmatic point of view that would mean that:
>>> - either every call must be protected with an intersects: test or (...
>>> intersect ...) ifNil: [...]
>>> - or UndefinedObject must understand Rectangle protocol
>>> Answering an empty rectangle seems more simple with this respect.
>>> Nicolas
>>
>> As I don't play with rectangles much, I will defer to your better judgment.
>> Mostly I was concerned about the "whatever is answered is correct in a
>> mathematical sense" statement but maybe I was being too picky.  And why I
>> quoted "correct" when I said nil was probably the "correct" answer. Correct
>> or not an empty rectangle is probably the "better" answer.
>
>It does occur to me that perhaps the behaviour's deliberate. Reading
>Andreas' comment in the method, it's an optimisation of a method that
>goes back to Smalltalk-76 [1]!
>
>GNU Smalltalk defines the behaviour of #intersect: [1] as returning nil
>for non-overlapping Rectangles [2]. (So we're already incompatible with
>another dialect!) My brief Googling didn't reveal what the other
>Smalltalks do.
>
>frank
>
>[1]
>http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.2641&rep=rep1&type=pdf
>
>[2]
>http://www.gnu.org/software/smalltalk/manual-base/html_node/Rectangle_002drectangle-functions.html
>

> On Mon, 21 Jun 2010 21:02:29 +0200, Frank Shearar
> <[hidden email]> wrote:
>
>>On 2010/06/21 16:03, Louis LaBrunda wrote:
>>>>>> snip...
>>>>>> One could just
>>>>>> leave it as it is, because the precondition for answering a "correct"
>>>>>> rectangle is that the receiver and the argument intersect. If they don't, the
>>>>>> answer is undefined, which means that whatever is answered is correct in a
>>>>>> mathematical sense.
>>>>>> snip...
>>>>>
>>>>> I urge some caution here.  If "whatever is answered is correct in a
>>>>> mathematical sense" is true then returning any rectangle like (100@100)
>>>>> corner: (150@150) would be correct, clearly that is not the case.  In
>>>>> Smalltalk, nil is undefined, nil is probably the "correct" answer.
>>>>
>>>> Yes, this is tempting.
>>>> However from a pragmatic point of view that would mean that:
>>>> - either every call must be protected with an intersects: test or (...
>>>> intersect ...) ifNil: [...]
>>>> - or UndefinedObject must understand Rectangle protocol
>>>> Answering an empty rectangle seems more simple with this respect.
>>>> Nicolas
>>>
>>> As I don't play with rectangles much, I will defer to your better judgment.
>>> Mostly I was concerned about the "whatever is answered is correct in a
>>> mathematical sense" statement but maybe I was being too picky.  And why I
>>> quoted "correct" when I said nil was probably the "correct" answer. Correct
>>> or not an empty rectangle is probably the "better" answer.
>>
>>It does occur to me that perhaps the behaviour's deliberate. Reading
>>Andreas' comment in the method, it's an optimisation of a method that
>>goes back to Smalltalk-76 [1]!
>>
>>GNU Smalltalk defines the behaviour of #intersect: [1] as returning nil
>>for non-overlapping Rectangles [2]. (So we're already incompatible with
>>another dialect!) My brief Googling didn't reveal what the other
>>Smalltalks do.
>>
>>frank
>>
>>[1]
>>http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.2641&rep=rep1&type=pdf
>>
>>[2]
>>http://www.gnu.org/software/smalltalk/manual-base/html_node/Rectangle_002drectangle-functions.html
>>
>
> VA Smalltalk V8 returns:
>  100 @ 100 corner: 50 @ 50
>

> I don't think I like it but that is what it does.  I will be interested to
> see what ends up in Squeak and pass that along to Instantiations.
>
> Lou
> -----------------------------------------------------------
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
> mailto:[hidden email] http://www.Keystone-Software.com
>
>
>

> On Mon, 21 Jun 2010 21:02:29 +0200, Frank Shearar
> <[hidden email]> wrote:
>
>>On 2010/06/21 16:03, Louis LaBrunda wrote:
>>>>>> snip...
>>>>>> One could just
>>>>>> leave it as it is, because the precondition for answering a "correct"
>>>>>> rectangle is that the receiver and the argument intersect. If they don't, the
>>>>>> answer is undefined, which means that whatever is answered is correct in a
>>>>>> mathematical sense.
>>>>>> snip...
>>>>>
>>>>> I urge some caution here.  If "whatever is answered is correct in a
>>>>> mathematical sense" is true then returning any rectangle like (100@100)
>>>>> corner: (150@150) would be correct, clearly that is not the case.  In
>>>>> Smalltalk, nil is undefined, nil is probably the "correct" answer.
>>>>
>>>> Yes, this is tempting.
>>>> However from a pragmatic point of view that would mean that:
>>>> - either every call must be protected with an intersects: test or (...
>>>> intersect ...) ifNil: [...]
>>>> - or UndefinedObject must understand Rectangle protocol
>>>> Answering an empty rectangle seems more simple with this respect.
>>>> Nicolas
>>>
>>> As I don't play with rectangles much, I will defer to your better judgment.
>>> Mostly I was concerned about the "whatever is answered is correct in a
>>> mathematical sense" statement but maybe I was being too picky.  And why I
>>> quoted "correct" when I said nil was probably the "correct" answer. Correct
>>> or not an empty rectangle is probably the "better" answer.
>>
>>It does occur to me that perhaps the behaviour's deliberate. Reading
>>Andreas' comment in the method, it's an optimisation of a method that
>>goes back to Smalltalk-76 [1]!
>>
>>GNU Smalltalk defines the behaviour of #intersect: [1] as returning nil
>>for non-overlapping Rectangles [2]. (So we're already incompatible with
>>another dialect!) My brief Googling didn't reveal what the other
>>Smalltalks do.
>>
>>frank
>>
>>[1]
>>http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.106.2641&rep=rep1&type=pdf
>>
>>[2]
>>http://www.gnu.org/software/smalltalk/manual-base/html_node/Rectangle_002drectangle-functions.html
>>
>
> VA Smalltalk V8 returns:
>  100 @ 100 corner: 50 @ 50
>

> I don't think I like it but that is what it does.  I will be interested to
> see what ends up in Squeak and pass that along to Instantiations.
>
> Lou
> -----------------------------------------------------------
> Louis LaBrunda
> Keystone Software Corp.
> SkypeMe callto://PhotonDemon
> mailto:[hidden email] http://www.Keystone-Software.com
>
>
>