Это вопрос о Boost Polygon (не о Boost Geometry)

Недавно я пытался поиграть с некоторыми геометрическими многоугольными конструкциями. посколькуПовысить геометрию (аразные библиотека, которая также имеет дело с полигонами) не работает косвенно в Boost 1.58, хотя я бы попробовалУвеличить полигон.

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

Цитата с главной страницы (выделено мое):

Тип данных координат является параметром шаблона всех типов данных и алгоритмов, предоставляемых библиотекой, икак ожидается, будет неотъемлемой. Типы данных координат с плавающей точкой не поддерживаются алгоритмами, реализованными в библиотеке, из-за того, что (sic) достижение устойчивости с плавающей запятой подразумевает другой набор алгоритмов и, как правило, специфичные для платформы предположения о представлениях с плавающей запятой.

Сначала я подумал, что это была проблема между точным и неточным представлением, поэтому я попытался заставить его работать с рациональными (Boost Rational) типами (я определил рациональный класс-обертку для его компиляции), но на самом деле целочисленные координаты - это строгое требование (Есть части в коде, которые фактически добавляют и вычитают одну для построения промежуточных результатов).

Возвращаясь к целым числам, я должен был сделать координаты очень большими (в целочисленных терминах), чтобы эта проблема дискретности исчезла. Другими словами, я должен все нормализовать взад и вперед. Ну, в конце это не очень полезно или удобно, как я первоначально думал.

Я что-то упускаю из-за использования этой библиотеки?

Эта библиотека предназначена для проблем с пикселями? Что такое полезность, если координаты ограничены целыми числами?

Является ли идея масштабировать координаты до очень больших чисел, а затем перенормировать результаты позже для геометрических приложений?

Я понимаю, что вычислительная геометрия с плавающей точкой очень больно,но почему эта библиотека даже не пытается быть совместимой с точными рациональными значениями?

Есть ли реальные примеры использования? (Руководство довольно плохо дает примеры)Кто-нибудь на самом деле использует эту библиотеку?

Бонусный вопрос:Это заброшенная библиотека?

Это пример того, как библиотека ведет себя из целочисленных координат:

Вот пример того, что происходит с целочисленными полигонами. Если я использую маленькие числа для представления координат, результаты даже не геометрически согласованы. (Два полигонаpolygon(-2,0)(2,-2)(6,4)(0,2) а такжеpolygon(-5,0)(-1,-2)(3,4)(-3,2))

(обратите внимание, как искажается все.)

Но когда я масштабирую полигоны так, чтобы они имели большие целочисленные координаты, результаты становятся более точными (два полигонаpolygon(-200,0)(200,-200)(600,400)(0,200) а такжеpolygon(-500,0)(-100,-200)(300,400)(-300,200), масштабированные версии двух выше.):

РЕДАКТИРОВАТЬ: я узнал немного больше вычислительной геометрии, очевидно, надежность вычислительной геометрии является очень сложной проблемой. Одна из стратегий - использовать целочисленную арифметику. Похоже, Boost.Polygon использует этот подход. Проблемы в непрерывном пространстве должны масштабироваться соответствующим образом.