Яка ідея визначення прямокутників з двома точками? [зачинено]

Справа не в тому, що це не має сенсу, але це просто спрацьовує незручно 99% часу.

Часто у двовимірній графіці прямокутники ініціалізуються, зберігаються та маніпулюються у вигляді пари точок. Немає конкретної мови,

class Rect:
   p1, p2: point

Більш сенс визначати прямокутник як два значення x і два значення y, як це:

class Rect
   xleft, xright: int
   ytop, ybottom: int

З двома пунктами, якщо в якомусь місці вихідного коду ви хочете використовувати значення у верхній частині, ви повинні сказати rect.p1.y (хм, зупиніться і подумайте, це p1 або p2), але з чотирма значеннями як звичайні члени даних, це зрозуміло і прямо: rect.ytop (не потрібно думати!) Використання двох точок означає, що в роботі з вертикаллю вам доведеться заплутати горизонталь; між сторонніми елементами існує стороння залежність.

Як виникла ця двоточна ідея і чому вона зберігається? Чи має якась користь над голою координатами x та y?

ДОБАВЛЕНО ПРИМІТКА: Це питання знаходиться в контексті прямокутників, вирівнюваних XY, таких як у менеджерах Windows та інструментальних інструментах GUI, а не в контексті довільних фігур у програмі малювання та малювання.

Чи вважали ви, що вона менш схильна до помилок?

Якщо ви використовуєте (Point1, Point2), тоді буде дуже зрозуміло, що ви вказуєте. Якщо ви надаєте 2 бали, то єдиною можливою помилкою є те, що користувач змішав свої х і у при побудові балів, оскільки порядок балів не має значення.

Якщо ви надаєте 4 цілих числа, то, якщо хтось не звертає уваги, він може подавати (x1, x2, y1, y2), коли ви хотіли (x1, y1, x2, y2) або навпаки. Також деякі API, такі як Rect структура WCF, визначають прямокутник як (x, y, ширина, висота), який може потім викликати плутанину щодо того, що означає (1, 2, 3, 4). Це (x, y, w, h) або (x1, y1, x2, y2) чи (x1, x2, y1, y2)?

Загалом, (Point1, Point2) мені здається трохи безпечнішим.

Мені завжди подобалося визначати прямокутник як точку + ширину та висоту, де точка - верхній лівий кут прямокутника.

class Rect {
  float x, y;
  float width, height;
}

А потім додайте будь-які методи, необхідні для отримання інших показників. Як і версія Java

Насправді прямокутник не визначається двома балами. Прямокутник можна визначити лише двома точками, якщо він паралельний осям.

Існує кілька способів зобразити прямокутники, паралельні осям:

1. Дві діагонально протилежні точки
2. Одна кутова точка, висота та ширина
3. Центральна точка, половина висоти та ширини (нечасто, але іноді корисно).
4. Як дві координати X і дві координати Y

Для (1) багато бібліотек використовують конвенцію, щоб визначити, які два пункти використовуються - наприклад, topLeft і bottomRight, наприклад.

Вибір представлення може бути зумовлений початковою метою визначення прямокутника, але я думаю, що воно часто довільне . Представлення рівнозначні в інформації, яку вони несуть. Однак вони відрізняються легкістю, з якою можна обчислити властивості прямокутника, і зручністю, з якою можна виконувати операції на прямокутнику.

Переваги визначення (1) перед іншими включають:

• Узгодженість API з іншими багатокутниками, лініями тощо
• topLeft, bottomRight можна передавати будь-якому методу, який приймає бали
• Методи класу Point можна викликати на topLeft, bottomRight
• Більшість властивостей можна отримати легко, наприклад, знизу вліво, вгоріВправо, ширина, висота, центр, довжина діагоналі тощо

Що ж, p1: Pointі p2: Pointчи всі у них все одно матимуть дві intкоординати , тож ваш клас не означає одне і те ж?

І якщо ви зберігаєте ці два пункти як першокласні Pointоб'єкти, чи не отримаєте від них трохи більше корисності? У більшості графічних систем координат, про які я знаю, точки підрозділяються таким чином, щоб створити ієрархію об'єктів: point -> circle -> ellipseтощо.

Отже, якщо ви створюєте об'єкт, який не використовує Pointклас, ви розлучили його з рештою ієрархії класів.

Ось чому мені подобаються Delphi TRect. Він визначається як варіант запису (об'єднана структура на C-говорі), який можна інтерпретувати як топ TopLeft і BottomRight, або цілі числа Top, Left, Bottom та Right, що б не було зручніше на даний момент.

Звичайно, якщо ви визначите свій прямокутник як:

class Rect
{
    Point bottomLeft;
    Point topRight;
}

то ви відразу знаєте, яка точка є.

Ще краще було б додати додаткові властивості, які дозволять вам маніпулювати прямокутником, коли б вам не знадобилось для вашої програми. Вони будуть просто оновлювати базову структуру даних.

Додавши перетворення до форми, ви можете орієнтувати свій прямокутник будь-яким способом. Вам все одно знадобиться вікно з обмеженням для вирівнювання по осі для швидкого прийому / відхилення чеків :)

Однак якщо ваша модель дозволяє прямокутники в будь-якій орієнтації без застосування перетворення, то "знизу вліво" і "вгорі праворуч" не мають значення, що призводить назад до "p1" і "p2" (або чогось еквівалентного).

я думаю, що має більше сенсу прямокутник бути представлений х і у мірою та крапкою; Ви навіть можете зробити точку розташування центром прямокутника, щоб воно було незалежним від обертання

але, мабуть, найпростіше було кодувати це як два моменти!

Мені це не подобається, тому що ми викинули потенційну ступінь свободи, яка по суті дозволяє довільну ротацію. Загальний прямокутник 2D має п'ять невідомих (ступенів свободи). Ми могли б вказати їх як координати точки, довжини двох сторін, які утворюють вершину з цією точкою, та кута від горизонталі першого рядка (другий вважається кутом на 90 градусів більшим). Нескінченна кількість інших можливостей також може бути використана, але необхідно вказати п’ять незалежних величин. Деякі варіанти ведуть до легшої алгебри, ніж інші, залежно від того, що з ними робиться.

Хіба це не те саме, що 2 бали? Як це незручно ... Більшість процедур малювання вимагають очок, а не окремих x / y компонентів.

Визначення прямокутників як точкових пар дозволяє повторно використовувати точку як вершину для іншої форми. Просто думка...

Я вважаю, що це головним чином встановлення рівномірності між усіма примітивними формами.

Впевнені, що ви можете визначити прямокутник багатьма різними способами, але як визначити трикутник, зірку чи коло таким чином, щоб можна було використовувати подібні структури даних?

Всі багатокутники можна визначити за їх точками, з короткою логікою, щоб визначити, що робити з точками.

Графічні бібліотеки функціонують в основному на цих полігонах з точки зору вершин і ребер, тому точки і лінії між ними всі обчислення працюють за цими двома ознаками, добре, що і гранями, але це саме по собі є лише функцією ребер.

У двох вимірах зберігання прямокутника як двох точок зрозуміліше, ніж визначення конкретного кута та ширини та висоти - врахуйте негативну ширину чи висоту, або розрахунки, необхідні для визначення кожного варіанту з іншого.

Виконувати обертання прямокутника, визначеного точками, також набагато простіше, ніж один, визначений з точкою плюс ширина та висота.

Я очікую, що інкапсуляція зробить цю диференціацію неважливою як користувач класу.

Прямокутник слід визначити як три точки, які слід добре визначити в 3 вимірах. Я не зовсім впевнений у вимозі визначення прямокутника у 4 та більше вимірах.

Це абсолютно довільно. Щоб намалювати прямокутник, вам потрібно чотири частини інформації. Дизайнер (и) бібліотеки вирішили представити її двома точками (кожна з координатою xy), але легко могли це зробити з x / y / w / h або top / bottom / left / right.

Я думаю, справжнє питання ОП: чому саме цей вибір був зроблений?

Вибір параметрів важливий лише для дизайнерів / кодерів низького рівня.

Користувачам високого рівня потрібно лише думати про:

• IsPointInRect
• Площа
• Перехрестя (або відсікання)
• HasOverlap (те саме, що перехресть. Зона> 0)
• Союз (стає списком прямокутників)
• Віднімання (перелік прямокутників, що представляють той самий набір точок, який знаходиться в прямій А, але не в прямій B)
• Перетворити
  • Зсуви в X і Y
  • Обертання (0, 90, 180, 270)
  • Масштабування в X і Y (див. Примітку)
• Простий синтаксис для властивостей Xmin, Xmax, Ymin, Ymax, Width, Height, щоб користувачеві не потрібно було знати точний вибір параметрів.

Примітка. Для того, щоб мінімізувати втрати точності під час трансформації масштабування, іноді доцільно реалізувати другий клас Rect, який використовує координати з плаваючою комою, щоб проміжні результати могли бути точно збережені в послідовності перетворень і лише округлені до цілого числа в останній крок

Як говорить @Steven, я думаю, що це має бути з точки зору однієї (x, y) точки та вектора розміру (w, h). Це тому, що легко впасти в неоднозначність. Припустимо, у вас є наступний заповнений прямокутник, починаючи з точки (0,0).

  012
0 XXX
1 XXX
2 XXX

Зрозуміло, що це ширина, висота (3,3), але що це за другий момент? Це (2,2) чи (3,3)?

Ця неоднозначність може викликати всілякі проблеми.

Я дізнався насилу років тому , що краще думати про графічних координатах , як лінії між пікселями, а не як лінії пікселів на . Таким чином, немає двозначності.

Pa(x,y)*-----------------------------------*Pb(x,y)
       |                                   |
       |                                   |
       |                                   |
       |                                   |
       |                                   |
       |                                   |
Pc(x,y)*-----------------------------------*Pd(x,y)

Ми можемо визначити обидва Pb & Pc таким чином:

Pb (Pd (x), Pa (y))

і

Pc (Pa (x), Pd (y))

Тому немає необхідності визначати всі чотири точки через симетрію