Rectangle - a mathematical problem

I have found something NOT funny with rectangles:

Lets say, given are values of left, top, right and bottom coordinates and all those coordinates are intended to be inclusive.

So, calculating the width goes like:

width = right - left + 1

So far, so logical. But!

A width of zero (which makes sense, sometimes) would have to be stored as:

right = left - 1

which makes problems, when it comes to the following operations:

• Sorting the rectangle coordinates (to make it go left to right, top to bottom)
• Looping

Ok, of course those things can be handled with extra code for the special case of Width == 0, but, seriously, is there no better solution, no standard pattern or best practice to handle this?

Edit:

For the time being I have abandoned the "sorting" of the coordinates in my code and replaced it with an assertion stating that the rectangle must be left -> right, up -> down, but seriously...

To address this problem, most graphics libraries will draw rectangles from the left coordinate up to but not including the right coordinate. So if left=10 and right=20, then the ten pixels 10 through 19 will be drawn.

You can think of this as the pixel coordinate referring not to the lit-up portion, but the grid lines between pixels.

+---+---+---+
|   |   |   |
+---+---+---+
|   |   |   |
+---+---+---+
^   ^   ^   ^
0   1   2   3

It's important to distinguish between coordinates and pixels. You can think of the coordinate system as being an invisible grid which runs between pixels. Thinking of coordinates this way if you define a rect as { 0, 3, 0, 5 }, then you get 3 pixels by 5 pixels as expected.

   |  |  |  |  |  |
0 -x--+--+--+--+--x-
   |  |  |  |  |  | 
1 -+--+--+--+--+--+-
   |  |  |  |  |  | <- pixels are rectangular areas between coordinate grid
2 -+--+--+--+--+--+-
   |  |  |  |  |  | 
3 -x--+--+--+--+--x-
   |  |  |  |  |  | 
   0  1  2  3  4  5

If the edges (left, right, top, bottom) are inclusive then, by definition, the width (and height) of the rectangle cannot be 0. By "including" the side (which is a pixel), you're saying that it has to be at least 1 pixel wide.

Saying that

all those coordinates are intended to be inclusive

means that there actually are two distinct rectangles, one within another. That's where you get caught: when you write

width = right - left + 1

it really means:

inner_width = outer_right - outer_left + thickness

where thickness is the distance between corresponding sides of inner and outer rectangles.

So, to deal with the problem in abstract mathematical sense, you have to consider two rectangles instead of one.

Of course you can find a workaround for this, but what really is the problem here is going out of scope.

Your scope is a rectangle, and even if a width of zero would come in handy : there is no such thing as a rectangle with width zero.

Normally all functions have contracts and a predcondition of a functions that says docalculation(par_rectangle) is that par_rectangle in fact is a rectangle.

If you need a retangle-like object wich can be width zero, you first need to define it waterproof, and never just assert that rules for rectangles will apply on your definiton.