У нас с коллегой возник философский спор на тему того, какой способ задания прямоугольника семантически (именно семантически) богаче: задание двух точек или задание точки и размера.
Я утверждаю, что семантически оба способа абсолютно эквиваленты. Мой коллега считает, что второй способ (точка + размер) — семантически богаче, поскольку такой способ оперирует сразу двумя понятиями: точка и размер, в то время как первый способ лишь одним — точкой.

Рассудите наш спор

зы: миллион леммингов не могут ошибаться!

Здравствуйте, lpc, Вы писали:

lpc>У нас с коллегой возник философский спор на тему того, какой способ задания прямоугольника семантически (именно семантически) богаче: задание двух точек или задание точки и размера.
lpc>Я утверждаю, что семантически оба способа абсолютно эквиваленты. Мой коллега считает, что второй способ (точка + размер) — семантически богаче, поскольку такой способ оперирует сразу двумя понятиями: точка и размер, в то время как первый способ лишь одним — точкой.

lpc>Рассудите наш спор

lpc>зы: миллион леммингов не могут ошибаться!

ИМХО, эквиваленты, поскольку размер — вектор — та же самая точка. А посему понятие остается одно — точка.

Здравствуйте, JFreeM, Вы писали:

lpc>>У нас с коллегой возник философский спор на тему того, какой способ задания прямоугольника семантически (именно семантически) богаче: задание двух точек или задание точки и размера.
lpc>>Я утверждаю, что семантически оба способа абсолютно эквиваленты. Мой коллега считает, что второй способ (точка + размер) — семантически богаче, поскольку такой способ оперирует сразу двумя понятиями: точка и размер, в то время как первый способ лишь одним — точкой.

lpc>>Рассудите наш спор

JFM>ИМХО, эквиваленты, поскольку размер — вектор — та же самая точка. А посему понятие остается одно — точка.

Две точки, так же, как и точка и размер — это некорректные способы задания прямоугольника. Что, если "верхняя левая" точка находится ниже "правой нижней"? В какую сторону от опорной точки отсчитывается размер?

Прямоугольник можно задать двумя отрезками — проекциями на оси координат. Т.е. [x1,x2]*[y1,y2] (Так даже корректнее в теоретико-множественном смысле).
Каждый из отрезков задаётся
— упорядоченной парой чисел (x1,x2), x1<=x2 --> [x1,x2]
— парой координата,размер (x,dx), dx>=0, --> [x,x+dx]
или
— неупорядоченной парой (x1,x2) --> [min(x1,x2),max(x1,x2)] либо [x1,max(x1,x2)], либо [min(x1,x2),x2]
— аналогично, координатой и произвольной дельтой
кстати, необязательно считать опорные точки концевыми
— (x,dx) --> [x-|dx/2|,x+|dx/2|]

Именно из-за последнего пункта можно утверждать: точка,размеры более богата, чем пара точек.
Потому что она позволяет отсчитывать координаты краёв от этой точки произвольным способом
((x,y),(dx,dy),(ax,ay)) где dx,dy — неотрицательные, а ax,ay — опции выравнивания (влево/вверх, в обе стороны, вправо/вниз).
Которые, кстати говоря, можно задавать не флагами, а процентами — как опорная точка разбивает отрезок
[x-a*dx,x+(1-a)*dx]
a=0.0 --> выравнивание влево, [x,x+dx]
a=0.5 --> центрирование, [x-dx/2,x+dx/2]
a=1.0 --> выравнивание вправо, [x-dx,x]

Также допустим, что координаты и габариты — переменные. Приложения, в которых опорная точка неподвижна, а размеры варьируются (либо наоборот, размеры фиксированы, а движется опорная точка) требуют одну модель; приложения, в которых прямоугольник независимо обтёсывается со всех сторон — другую.
Первая модель и встречается чаще, и функционально богаче.

Итого, мой выбор — опорная точка,размеры,опции выравнивания.

Здравствуйте, Кодт, Вы писали:

К>Две точки, так же, как и точка и размер — это некорректные способы задания прямоугольника. Что, если "верхняя левая" точка находится ниже "правой нижней"? В какую сторону от опорной точки отсчитывается размер?

Об этом можно "договориться". Например, считать что в первом случае задается левая верхняя и правая нижняя точка, а во втором случае — левая верхняя точка. Суть дискуссии не в этом, а в том, какои ИЗ ЭТИХ двух способов семантически богаче.

К>Прямоугольник можно задать двумя отрезками — проекциями на оси координат. Т.е. [x1,x2]*[y1,y2] (Так даже корректнее в теоретико-множественном смысле).
К>Каждый из отрезков задаётся
К>- упорядоченной парой чисел (x1,x2), x1<=x2 --> [x1,x2]
К>- парой координата,размер (x,dx), dx>=0, --> [x,x+dx]
К>или
К>- неупорядоченной парой (x1,x2) --> [min(x1,x2),max(x1,x2)] либо [x1,max(x1,x2)], либо [min(x1,x2),x2]
К>- аналогично, координатой и произвольной дельтой
К>кстати, необязательно считать опорные точки концевыми
К>- (x,dx) --> [x-|dx/2|,x+|dx/2|]

К>Именно из-за последнего пункта можно утверждать: точка,размеры более богата, чем пара точек.

Нет, не следует. Отсюда следует что точка, размеры и (как Вы называете) опции выравнивания — более богата, чем пара точек. И это дополнительное богатство добавляется за счет двух дополнительных степеней свободы, за счет опций варавнивания.

Я же утверждаю, что оба описанных мной варианта эквиваленты с точки зрения семантики, т.е. несут в себе равное количество смысловой нагрузки (прошу обратить внимание, что именно равное количество смысловой нагрузки, но не одинаковую смысловую нагрузку. Смысловую нагрузку можно измерить количеством информации, в обоих случаях оно одинаково и, очевидно, равно 4 * sizeof(T) * 8 бит, где Т — используемый тип данных.

Вы с этим согласны?

К>Итого, мой выбор — опорная точка,размеры,опции выравнивания.

Боюсь что такая гибкость в 90% случаев избыточна, хотя конечно это более правильный вариант. Вот MS выбирает первый вариант, Sun — второй.

Здравствуйте, lpc, Вы писали:

Следующий флэйм буде

x vs. y

кто прав кто виноват?

Здравствуйте, VladD2, Вы писали:

VD>Следующий флэйм буде
VD>

VD>x vs. y
VD>

Ошибаешься. Будет (x1,y1,x2,y2) vs (left,top,right,bottom). Я утверждаю, что второе — кретинский идиотизм.

Здравствуйте, McSeem2, Вы писали:

MS>Ошибаешься. Будет (x1,y1,x2,y2) vs (left,top,right,bottom). Я утверждаю, что второе — кретинский идиотизм.

А, ну, спорътэ мужчыны (с) анекдот про грузинов.

ЗЫ

Если по делу... мне всегда нравилось когда есть абстракция которую можно представлять по разному. Например, чтобы был класс который содержал бы наборы свойств позволяющие использовать как (x1,y1,x2,y2), так (l,t,r,b) и даже (x1,y1,x2,y2) vs (l,t,h,w). А уж как мне удобно, так я и буду их испльзовать. Если тебя смущает слово top, то можно сделать так, чтобы при пересчете в top/left всегда помещалась верхняя точка.

Здравствуйте, lpc, Вы писали:

lpc>У нас с коллегой возник философский спор на тему того, какой способ задания прямоугольника семантически (именно семантически) богаче: задание двух точек или задание точки и размера.
lpc>Я утверждаю, что семантически оба способа абсолютно эквиваленты. Мой коллега считает, что второй способ (точка + размер) — семантически богаче, поскольку такой способ оперирует сразу двумя понятиями: точка и размер, в то время как первый способ лишь одним — точкой.
lpc>Рассудите наш спор
Задание двух точек предполагает выполнение построения в любых направлениях обхода контура.
Задание точки и размера предполагает заранее известное выполнение построения в определённом направлении обхода контура.

Приходим к пониманию Экранной системы координат vs. Декартовой системы координат: где находится начало координат и куда направлены оси.
lpc>зы: миллион леммингов не могут ошибаться!
И в этой шутке есть доля шутки.

Здравствуйте, lpc, Вы писали:
lpc>У нас с коллегой возник философский спор на тему того, какой способ задания прямоугольника семантически (именно семантически) богаче: задание двух точек или задание точки и размера.
lpc>Я утверждаю, что семантически оба способа абсолютно эквиваленты. Мой коллега считает, что второй способ (точка + размер) — семантически богаче, поскольку такой способ оперирует сразу двумя понятиями: точка и размер, в то время как первый способ лишь одним — точкой.
здесь

Автор: Flamer
Дата: 22.04.05

Здравствуйте, lpc, Вы писали:

lpc>У нас с коллегой возник философский спор на тему того, какой способ задания прямоугольника семантически (именно семантически) богаче: задание двух точек или задание точки и размера.
lpc>Я утверждаю, что семантически оба способа абсолютно эквиваленты. Мой коллега считает, что второй способ (точка + размер) — семантически богаче, поскольку такой способ оперирует сразу двумя понятиями: точка и размер, в то время как первый способ лишь одним — точкой.

lpc>Рассудите наш спор

lpc>зы: миллион леммингов не могут ошибаться!


тогда уж только так
min_x, min_y, max_x, max_y
слушайте отцов растровой графики !

Здравствуйте, minorlogic, Вы писали:

M>тогда уж только так
M>min_x, min_y, max_x, max_y
M>слушайте отцов растровой графики !

Кого именно? Ссылку пожалуйста!

Здравствуйте, minorlogic, Вы писали:

M>тогда уж только так
M>min_x, min_y, max_x, max_y
M>слушайте отцов растровой графики !

То, о чём я говорил: два диапазона — min_x..max_x, min_y..max_y

Здравствуйте, lpc, Вы писали:

class IRectangle
{
public:
  virtual float GetWidth() = 0;   
  virtual float GetHeight() = 0;   
  virtual float GetTop() = 0;   
  virtual float GetLeft() = 0;   
  virtual float GetRight() = 0;   
  virtual float GetBottom() = 0;   
  virtual float GetX1() = 0;   
  virtual float GetX2() = 0;   
  virtual float GetY1() = 0;   
  virtual float GetY2() = 0;   
  //set методы 
  ....
};

_Winnie wrote:

>class IRectangle
>{
>public:
> virtual float GetWidth() = 0;
> virtual float GetHeight() = 0;
> virtual float GetTop() = 0;
> virtual float GetLeft() = 0;
> virtual float GetRight() = 0;
> virtual float GetBottom() = 0;
> virtual float GetX1() = 0;
> virtual float GetX2() = 0;
> virtual float GetY1() = 0;
> virtual float GetY2() = 0;
> //set методы
> ....
>};
>
Зачем так грубо?

struct Rectangle1
{
    int x1,x2,y1,y2;
};

template<class T> struct RectangleManipulator
{
private:
    //Вы должны предоставить специализацию RectangleManipulator
    //для данного вида прямоугольников!
    static int GetLeft(const T &);
    static int GetRight(const T &);
...
};

template<> struct RectangleManipulator<Rectangle1>
{
public:
    static int GetLeft(const Rectangle1 &);
    static int GetRight(const Rectangle1 &);
...
};

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>_Winnie wrote:

А моё решение можно спрятать в Dll. Или замаршалить через сеть. Что бы пользователь никогда не знал, с чем имеет дело. А у тебя достаточно глянуть в .h файл, и сразу понятно, через что реализован прямоугольник.

_Winnie wrote:

> C>_Winnie wrote:
> А моё решение можно спрятать в Dll.

Зато у меня нет виртуальных вызовов

> Или замаршалить через сеть.

Без проблем:

template<class Archive> void serialize(Archive ar, Rectangle1 &rect)
{
    ar&rect.x1&rect.x2&rect.x3&rect.x4;
};

Или даже просто memcpy (у меня ведь POD!).

> Что бы пользователь никогда не знал, с чем имеет дело. А у тебя
> достаточно глянуть в .h файл, и сразу понятно, через что реализован
> прямоугольник.

А разве это минус?

--
С уважением,
Alex Besogonov (alexy@izh.com)

Здравствуйте, Cyberax, Вы писали:

C>_Winnie wrote:

>> Или замаршалить через сеть.
Я имел в виду, что реализация может быть на удаленном сервере.
И имея локально интерфейс, никогда не догаешься, как на самом деле храняться координаты

C>А разве это минус?

В свете мучений автора топика — конечно да

Здравствуйте, lpc, Вы писали:

lpc>У нас с коллегой возник философский спор на тему того, какой способ задания прямоугольника семантически (именно семантически) богаче: задание двух точек или задание точки и размера.
lpc>Я утверждаю, что семантически оба способа абсолютно эквиваленты. Мой коллега считает, что второй способ (точка + размер) — семантически богаче, поскольку такой способ оперирует сразу двумя понятиями: точка и размер, в то время как первый способ лишь одним — точкой.

lpc>Рассудите наш спор

Трудно рассудить в отрыве от контекста.
Например, если мы оперирует контролами на форме, то согласен, положение и размер — это как бы несвязанные сущности в общем случае, т.е. очевидны варианты их раздельного использования.

С другой т.з., когда речь идет об алгоритмах, связанных с фигурами на плоскости (напр. вычисляем пересечение или объединение и т.д.), то нужны именно координаты. Поэтому в виндах структура RECT содержит координаты, а не "семантически богатые" Width и Height, эти св-ва содержит уже класс CRect из MFC.

Если бы RECT в виндах хранил бы не координаты, а положение и размер, то требовались бы лишние вычисления на каждый чих.

Windows.Forms — гораздо более позднее творение. Он позволяется себе подобный пересчет при вызове ф-ий WinAPI.

Хотя... Этот пересчет незаметен на фоне маршаллинга при интеропе, такие дела

_Winnie wrote:

>>> Или замаршалить через сеть.
> Я имел в виду, что реализация может быть на удаленном сервере.

Ну да, это плюс. Хотя делать RPC-вызовы для получения координат
прямоугольника может присниться только в страшном сне

--
С уважением,
Alex Besogonov (alexy@izh.com)