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

S> Ну а доступ к этому агрегату то через интерфейс будешь городить? Какой смысл?
Зачем? Просто структура из нескольких поелй и всё...
S>Про агрегаты я уже синклеру писал http://www.rsdn.ru/forum/philosophy/5119558.1

Автор: Serginio1
Дата: 01.04.13

Я ничего не понял в том твоём сообщении...

S>А чем плохо наследование, если оно реально присутствует и отвечает за частные случаи. То есть Квадрат это фигура состоящая из 4 точек итд?
1) Я не понимаю, что значит "реально присутствует"
2) Наследование плохо тем, что накладывает связь и граничения. Если эта связь и ограничения не нужны для алгоритмов, то это недостаток.
Ты можешь обхяснить, почему наследование, а не агрегирование?
3) Логика "квадарт -- наследник фигуры из 4-х точек" вообще ущербна в большинстве задач. И она ничем не оличается от логики "4-вектор -- это std::вектор из 4-х элементов"
Ты так и не ответил создаёшь ли ты наследников вектора определённых размерностей?..
если нет, то почему?

S> В одних случаях хорошо оперировать как квадрат в других случаях как фигура. Так человек это млекопитающего и его внутренние органы соответствуют свинье итд.
Ну примеры-то *одних случаев* будут?..


S>При этом свинья выступает во многих случаях как моделью для изучения влияния различных воздействий.
Это всё не имеет не только доказательной, но и иллюстративной силы. Скажем чеме тебе корова не свинья? Тем не менее корова -- очень плохая можель человека.
Ну и в любом случае, если бы ООП в жизни работало, то лучшей моделью печени человека была бы не печень свиньи, а печень шимпанзе каких-нибудь

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

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

S>> А зачем тратить лишнее время. Сколько точек нужно для расчета периметра илм площади для окружности?

E>Если ты хранишь окружность, как дугу кривой какого-то семейства, то три-четыре, в зависимости от того, какое семейство кривых...
Для окружности достаточно всего одного радиуса. Для более сложных фигур уже нужно переходить на численное интегрирование.

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

E>>Почему наследование? Ты типа делаешь, кроме типа "фигура" ещё и тип "фигура в коробочке простой формы". Зачем вторая должна быть наслдником, а не агрегатором первой?

Я утверждаю, что если даже где-то нужен именно квадрат, то это должен быть ДРУГОЙ класс, который, например, может построить фигуру, если она кому-то понадобится...
Но и сам по себе класс "квадраты" для меня довольно таки сомнителен в геометрических задачах...

S>То есть ты утверждаешь, что квадрат это не фигура, или излишне вводить новую сущность как прямоугольный треугольник, прямоугольник, квадрат итд и достаточно всего массива набора точек?
Это очень зависит от задачи...
Но задач, где такие сущности нужны я не знаю

S>А может они введены для упрощения многих алгоритмов, в том числе и для базовых (тригонометрия например)

Примеры многих базовых алгоритмов таки будут?

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

E>>А как делаешь ты? Вот, например, у тебя в качестве упрощённых фигур есть круг, треугольник, прямоугольник, квадрат и элипс. Как ты, например, проверяешь, что нет пересечений?
S> Я возьму и приведу их всех к вписанному прямоугольнику.

К вписанному или к описанному?
Что такое "вписанный прямоугольник" для окружности, например? В смысле который из?
Что такое для треугольника?

S> И там по упрощенному алгоритму проверю, на пересечение. Если нет пересечений прямоугольников значит и нет пересечений многополигомных фигур. Если же пересекаются, то перехожу к более сложным фигурам.

А зачем тогда вообще эти промежуточные упрощённые фигуры?
Сразу всё приводи к прямоугольникам и по ним проверяй грубо, а потом сразу по полигонам негрубо. Работать будет не сильно дольше, но сильно точнее. Раскрои будут оптимальнее...

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

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

S>>Я уже приводил пример с картами раскроя. Так прямоугольный крой стоит дешевле чем криволинейный. Кроме того есть кромкование которое зависит от периметра.

E>Ничего не понимаю. Кривой у теюя там крой или прямой зависит от самих по себе фигур,а не от карты.
Я тебе привел пример для чего нужны площадь и периметр.

E>Общая длина реза зависит от того, как много границ удаётся совместить с граиницами слэба или границами деталей, но как раз тут и НЕЛЬЗЯ приближать фигуру упрощённой формой.
Почему? На практике так и происходит, так как проще оперировать простыми фигурами.

E>Общая длина кромкования вообще зависит только от самих деталей
Нужен периметр.

S>>Оптимальность раскроя зависит от общей площади деталей к площади листа.
E>Забыл ещё возможность переиспользования реза. То есть что бы один рез разделял соразу две детали.

S>>Ну и алгоритмы раскроя достаточно жадные до ресурсов и относятся к классу NP-полная задача
E>Ну они же жадные в области перебора вариантов размещения деталей, а не в области обсчёта конкретного варианта. Конечно детали можно для кроя немного упростить. Ну там совсем кривые края спрямить с запасом, и пометить, что переиспользование этой границы не является выигрышем, убрать с деталей всякие пазы щели и дырки, и т. д. Но в целом вычислить размещение реального полигона или упрощённого -- это разница всего-то в разы. Не в разы разница -- это структура перебора вариантов. Её-то и надо оптимизировать, а не фигню.

Ну так этих вариантов тем больше, чем более сложные фигуры.

E>ну и потом, выч. мощность очень дешёвая, на самом деле. А раскрой часто довольно дорог. Так что вообще не понятно, какой экономический смысл экономить на компике, что бы потом переплачивать за резку...
На мысли в том, что эту задачу невозможно решить за определенное время. Кстати даже после прямоугольного кроя люди вручную дооптимизирут.
А что говорить о более сложных фигурах.

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

S> Во пошло. А Дуга это разве не фигура? Опять же при раскрое ты будешь оперировать шагом итд. Вот мы пришлу уже к иерархии называемой семейством.

Ничего не понимаю.
Всё же от задачи зависит. Если у тебя есть таки в задаче не только ломанные, но и дуги, то есть тебе они таки нужны, то у теюя сама по себе обобщённая фигура, которая массив точек, будет, на самом деле, массивом дуг, часть из которых -- орезки прямых.
Как ты это там будешь хранить -- отдельный вопрос, но фигура всё равно будет массивом таких отрезков дуг/прямых.

Зачем из этой структуры выводить круги или квадраты я не понимаю.

S>Которая является фигурой и которую можно выразить через массив точек с определенным шагом.
Если всё можно приблизить тупо ломанными, то получаем просто массив границ отрезков, без дуг и криволинейностей. То есть примерно то же, тольео формулы чуть проще...

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

S>Для окружности достаточно всего одного радиуса. Для более сложных фигур уже нужно переходить на численное интегрирование.

Ну один там радиус или три точки -- разница не велика, в отличии от накладных расходов на организацию всего этого полиморфизма...

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

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

S>> Ну а доступ к этому агрегату то через интерфейс будешь городить? Какой смысл?
E>Зачем? Просто структура из нескольких поелй и всё...
S>>Про агрегаты я уже синклеру писал http://www.rsdn.ru/forum/philosophy/5119558.1

Автор: Serginio1
Дата: 01.04.13

E>Я ничего не понял в том твоём сообщении...
Если нет иерархии, а ты хочешь работать как с фигурой тебе нужно выставлять наружу что то, к чему ты можешь обратиться.
Одно дело, что ты работаешь только с одной фигурой то твой подход хорошь, если уже с несколькими, то нужно определять тип и тд. Как это делается в 1С.

S>>А чем плохо наследование, если оно реально присутствует и отвечает за частные случаи. То есть Квадрат это фигура состоящая из 4 точек итд?
E>1) Я не понимаю, что значит "реально присутствует"
E>2) Наследование плохо тем, что накладывает связь и граничения. Если эта связь и ограничения не нужны для алгоритмов, то это недостаток.
E>Ты можешь обхяснить, почему наследование, а не агрегирование?
E>3) Логика "квадарт -- наследник фигуры из 4-х точек" вообще ущербна в большинстве задач. И она ничем не оличается от логики "4-вектор -- это std::вектор из 4-х элементов"
E>Ты так и не ответил создаёшь ли ты наследников вектора определённых размерностей?..
E>если нет, то почему?

Я уже кучу примеров написал. Думаю, что дальше уже бессмысленно что то говорить.
S>> В одних случаях хорошо оперировать как квадрат в других случаях как фигура. Так человек это млекопитающего и его внутренние органы соответствуют свинье итд.
E>Ну примеры-то *одних случаев* будут?..
Я уже тебе их кучу привел.


S>>При этом свинья выступает во многих случаях как моделью для изучения влияния различных воздействий.
E>Это всё не имеет не только доказательной, но и иллюстративной силы. Скажем чеме тебе корова не свинья? Тем не менее корова -- очень плохая можель человека.
E>Ну и в любом случае, если бы ООП в жизни работало, то лучшей моделью печени человека была бы не печень свиньи, а печень шимпанзе каких-нибудь
Ну так шимпанзе то мало, а коров и свиней полно.

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

S> Я тебе привел пример для чего нужны площадь и периметр.
Да площадь и периметр могут и просто так заинтересовать. Не важно. Важно то, что их вычисление во время поиска оптимального раскроя не требуется...
Ну и для вычисления площади и периметра фигуры не нужно занть её форму, достаточно представления как массива ограничиваюих отрезков или дуг...

S> Почему? На практике так и происходит, так как проще оперировать простыми фигурами.
Потому, что если ты приблизил кривой рез прямым, а потом решил сэкономить, совместив этот прямой рез с другим прямым резом, то реально никакой экономии не получится...

S>Нужен периметр.
И что, это какая-то сложная задача, что ли? Зачем периметр треугольника или даже окружности, считать как-то иначе, чем периметр n-угольника?

E>>Не в разы разница -- это структура перебора вариантов. Её-то и надо оптимизировать, а не фигню.

S> Ну так этих вариантов тем больше, чем более сложные фигуры.

Именно поэтому надо задавать целенаправленность и отсечения в перебор вариантов, а не заниматься ерёндой с ООп-представлением фигур

S> На мысли в том, что эту задачу невозможно решить за определенное время. Кстати даже после прямоугольного кроя люди вручную дооптимизирут.
S>А что говорить о более сложных фигурах.

IMHO, Это говорит, что твоя прекрасная ООП-программа просто не работает. Долго и вычурно вычисляет не то...

Сравни с оптимизирующим компилятором С++, например. За ним вручную не особо пооптимизируешь, в отличии от. Только не надо говорить, что задача кроя проще, чем задача оптимизации С++

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

S> Если нет иерархии, а ты хочешь работать как с фигурой тебе нужно выставлять наружу что то, к чему ты можешь обратиться.
S>Одно дело, что ты работаешь только с одной фигурой то твой подход хорошь, если уже с несколькими, то нужно определять тип и тд. Как это делается в 1С.
Зачем это всё? Ты просто НУЖНЫЕ для перебора данные предоставь и всё. На кой для перебора вариантов кроя тип фигуры?

Я тут где-то тебе писал, как бы я сделал. С гипотезами размещения, генерируемыми по полигонам. Ты присмотрись к такой конструкции, она прямая, удобная и простая. И скорее всего после такой программы дооптимизировать вручную не получится, кстати

E>>Ты можешь обхяснить, почему наследование, а не агрегирование?
E>>3) Логика "квадарт -- наследник фигуры из 4-х точек" вообще ущербна в большинстве задач. И она ничем не оличается от логики "4-вектор -- это std::вектор из 4-х элементов"
E>>Ты так и не ответил создаёшь ли ты наследников вектора определённых размерностей?..
E>>если нет, то почему?

S> Я уже кучу примеров написал.
Ты не привёл пока ни одного КОНКРЕТНОГО примера алгоритма...

S>Думаю, что дальше уже бессмысленно что то говорить.
Ну ты на вопросы-то ответь?
а) Почему наследование, а не агрегирование?
б) Ты таки наследуешь из вектора 3-вектор, 4-вектор и т. д.?
б') Если таки нет, то почему?

E>>Ну примеры-то *одних случаев* будут?..
S> Я уже тебе их кучу привел.
Пока что ты привёл ровно один пример -- какой-то запутанный и неконкретный алгоритм оптимизации кроя, который, как потом ты сам же и написал, по факту ещё и не работает
Ещё ты приводил пример с площадью круга против площади n-угольника. Только я вообще ен понял чего это пример. Насколько я теюя понял, круг из n-угольника выводить вообще нельзя. Зато можно выводить из криволенейного n-угольника. Но если у нас в деле кривые, то и площадь и периметр круга снова становятся тривиальными...

S> Ну так шимпанзе то мало, а коров и свиней полно.
Не совсем уловил, какое влияние на ответ "насколько печень Х похожа на печень человека?" зависит от численности Х?
В конце концов макак просто как грязи, и они намного ближе к человеку, чем свиньи. И, тем не менее...
В общем предлагаю это "свинское" направление обсуждения не развивать. Оно толкьо дополнительно иллюстрирует, что ООП в жизни реально нифига не присутствует. Но это и так, IMHO, понятно

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

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

E>>>Почему наследование? Ты типа делаешь, кроме типа "фигура" ещё и тип "фигура в коробочке простой формы". Зачем вторая должна быть наслдником, а не агрегатором первой?

E>Я утверждаю, что если даже где-то нужен именно квадрат, то это должен быть ДРУГОЙ класс, который, например, может построить фигуру, если она кому-то понадобится...
E>Но и сам по себе класс "квадраты" для меня довольно таки сомнителен в геометрических задачах...


S>>То есть ты утверждаешь, что квадрат это не фигура, или излишне вводить новую сущность как прямоугольный треугольник, прямоугольник, квадрат итд и достаточно всего массива набора точек?
E>Это очень зависит от задачи...
E>Но задач, где такие сущности нужны я не знаю
Я тебе уже приводил этот класс задач. Раскрой. Для раскроя проще оперировать более простыми фигурами, их можно группировать и строить например из двух треугольников один прямоугольник из окружности прямоугольник, а из двух вогнутых фигур опять тот же прямоугольник итд. Соответственно работать с фигурой ты будешь по единому интерфейсу.

S>>А может они введены для упрощения многих алгоритмов, в том числе и для базовых (тригонометрия например)

E>Примеры многих базовых алгоритмов таки будут?
синус косинус итд. Я же написал тригонометрия. Числовые методы интегрирования итд.

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

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

E>>>А как делаешь ты? Вот, например, у тебя в качестве упрощённых фигур есть круг, треугольник, прямоугольник, квадрат и элипс. Как ты, например, проверяешь, что нет пересечений?
S>> Я возьму и приведу их всех к вписанному прямоугольнику.

E>К вписанному или к описанному?
E>Что такое "вписанный прямоугольник" для окружности, например? В смысле который из?
E>Что такое для треугольника?
Вписанный в прямоугольник. Так и знал, что докапаешься. Это минимальное соотношение площади фигуры к площади прямоугольника.

S>> И там по упрощенному алгоритму проверю, на пересечение. Если нет пересечений прямоугольников значит и нет пересечений многополигомных фигур. Если же пересекаются, то перехожу к более сложным фигурам.

E>А зачем тогда вообще эти промежуточные упрощённые фигуры?
E>Сразу всё приводи к прямоугольникам и по ним проверяй грубо, а потом сразу по полигонам негрубо. Работать будет не сильно дольше, но сильно точнее. Раскрои будут оптимальнее...
А зачем алгоритмы с погрешностями, от большей к меньшей? Яркий пример метод половинного деления. Просто для уменьшения количества затрачиваемого времени.
Еще раз я уже писал тебе про NP полную задачу. Предлагаю тебе двинуть в эту область одна из таких программ K3.

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

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

S>>Для окружности достаточно всего одного радиуса. Для более сложных фигур уже нужно переходить на численное интегрирование.

E>Ну один там радиус или три точки -- разница не велика, в отличии от накладных расходов на организацию всего этого полиморфизма...
Для криволинеек там отнюдь не 3 точки.
А какие там расходы? В написании слова override?

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

S> Я тебе уже приводил этот класс задач. Раскрой. Для раскроя проще оперировать более простыми фигурами, их можно группировать и строить например из двух треугольников один прямоугольник из окружности прямоугольник, а из двух вогнутых фигур опять тот же прямоугольник итд. Соответственно работать с фигурой ты будешь по единому интерфейсу.

Зачем всё это усложнение?
У тебя есть две сущности.
1) фигура
2) Вариант её размещения в раскрое.
Почему ты хочешь связать эти сущности отношением наследования?
Зачем? В какой момент и для какой операци тебе хочется работать с вариантом размещения, как с фигурой?

E>>Примеры многих базовых алгоритмов таки будут?
S>синус косинус итд. Я же написал тригонометрия. Числовые методы интегрирования итд.

Не понимаю, что такое синус окружности, например? Или n-угольника?

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

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

S>> Во пошло. А Дуга это разве не фигура? Опять же при раскрое ты будешь оперировать шагом итд. Вот мы пришлу уже к иерархии называемой семейством.

E>Ничего не понимаю.
E>Всё же от задачи зависит. Если у тебя есть таки в задаче не только ломанные, но и дуги, то есть тебе они таки нужны, то у теюя сама по себе обобщённая фигура, которая массив точек, будет, на самом деле, массивом дуг, часть из которых -- орезки прямых.
E>Как ты это там будешь хранить -- отдельный вопрос, но фигура всё равно будет массивом таких отрезков дуг/прямых.
Вот наконец то.
E>Зачем из этой структуры выводить круги или квадраты я не понимаю.
А затем, что оперировать для алгоритмов проще простыми фигурами. Вспомни замечательные пределы?

S>>Которая является фигурой и которую можно выразить через массив точек с определенным шагом.
E>Если всё можно приблизить тупо ломанными, то получаем просто массив границ отрезков, без дуг и криволинейностей. То есть примерно то же, тольео формулы чуть проще...
Ну наконец то. А вот с дугами то проще. Я особо не вникаю, но некоторые аппараты для резки оперировали только дугами, хотя проще для описания сплайны

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

S> Вписанный в прямоугольник. Так и знал, что докапаешься. Это минимальное соотношение площади фигуры к площади прямоугольника.

1) При чём тут "докапаешься"? Ты просто очень непонятно пишешь. Правда не понятно, что ты имеешь в виду.
2) А почему этот подход является хорошим? Эти "описанные" прямоугольники труно искать, трудно проверять их на пересечение, и они нужны только для отсечения окончательной проверки в конце концов.

S> А зачем алгоритмы с погрешностями, от большей к меньшей? Яркий пример метод половинного деления. Просто для уменьшения количества затрачиваемого времени.
Ну так ты оцени время-то. Асимптота от введения промежуточного слоя не меняется, константа тоже не сильно зависит, зато накладных расходов -- три вагона...

У тебя сколько фигур в типичном раскрое? штуки? Десятки? Сотни?..

S> Еще раз я уже писал тебе про NP полную задачу. Предлагаю тебе двинуть в эту область одна из таких программ K3.

Спасибо, но я пока двигаю свою. Пока что наша группа лидирует...
Кстати, думаешь задача потимизации С++ не NP-полна что ли? Тем не менее обогнать оптимизатор С++ трудно, а ту программу в которой якобы есть все эти иерархии, как ты утверждаешь, таки можно, опять же, как ты утверждаешь...

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

S> А какие там расходы? В написании слова override?
Больше кода, данных, сами данные сложнее, сложнее тестирование и т. д...

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

S> Вот наконец то.
Что "наконец-то"?
E>>Зачем из этой структуры выводить круги или квадраты я не понимаю.
S> А затем, что оперировать для алгоритмов проще простыми фигурами. Вспомни замечательные пределы?
Кому проще? И для каких алгоритмов?
Конкретка-то будет?

S> Ну наконец то. А вот с дугами то проще. Я особо не вникаю, но некоторые аппараты для резки оперировали только дугами, хотя проще для описания сплайны

Ты понимаешь, что дуги от отрезком вообще почти ничем не отличаются? Ну дял отрезка надо две точки знать, а для дуги там три или чеытре. Дальше всё ТАК ЖЕ.

При этом сами дуги тоже скорее всего не нужны полиморфные, хотя это вопрос простой оптимизации довольно.

Но ты говорил не о ДУГАХ/ОТРЕЗКАХ, а о полиморфных ФИГУРАХ. И пока что так ничего внятного про то, зачем тебе выводить из фигуры вообще, УЖЕ СОДЕРЖАЩЕЙ массив дуг, конкреетные фигуры, так рассказать и не смог.

Ты можешь какой-то код написать, который это ООП использует, например?

только РЕАЛЬНЫЙ, который какую-топ понятную задачу решает, а не "работает с фигурами вообще"...

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

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

S>> Я тебе привел пример для чего нужны площадь и периметр.
E>Да площадь и периметр могут и просто так заинтересовать. Не важно. Важно то, что их вычисление во время поиска оптимального раскроя не требуется...
E>Ну и для вычисления площади и периметра фигуры не нужно занть её форму, достаточно представления как массива ограничиваюих отрезков или дуг...

S>> Почему? На практике так и происходит, так как проще оперировать простыми фигурами.
E>Потому, что если ты приблизил кривой рез прямым, а потом решил сэкономить, совместив этот прямой рез с другим прямым резом, то реально никакой экономии не получится...

S>>Нужен периметр.
E>И что, это какая-то сложная задача, что ли? Зачем периметр треугольника или даже окружности, считать как-то иначе, чем периметр n-угольника?
У тебя ничего нет сложного. Для вычисления площади окружности достаточно всего одного радиуса, для вычисления площади квадрата достаточно одной стороны.


E>>>Не в разы разница -- это структура перебора вариантов. Её-то и надо оптимизировать, а не фигню.

S>> Ну так этих вариантов тем больше, чем более сложные фигуры.

E>Именно поэтому надо задавать целенаправленность и отсечения в перебор вариантов, а не заниматься ерёндой с ООп-представлением фигур

S>> На мысли в том, что эту задачу невозможно решить за определенное время. Кстати даже после прямоугольного кроя люди вручную дооптимизирут.
S>>А что говорить о более сложных фигурах.

E>IMHO, Это говорит, что твоя прекрасная ООП-программа просто не работает. Долго и вычурно вычисляет не то...
Это не моя. Это K3.

E>Сравни с оптимизирующим компилятором С++, например. За ним вручную не особо пооптимизируешь, в отличии от. Только не надо говорить, что задача кроя проще, чем задача оптимизации С++
Еще раз напомню класс задач NP полный. Как только ты прикинешь количество вариантов расположения 50 разных деталей на листе то все станет предельно ясно.

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

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

S>> Если нет иерархии, а ты хочешь работать как с фигурой тебе нужно выставлять наружу что то, к чему ты можешь обратиться.
S>>Одно дело, что ты работаешь только с одной фигурой то твой подход хорошь, если уже с несколькими, то нужно определять тип и тд. Как это делается в 1С.
E>Зачем это всё? Ты просто НУЖНЫЕ для перебора данные предоставь и всё. На кой для перебора вариантов кроя тип фигуры?

E>Я тут где-то тебе писал, как бы я сделал. С гипотезами размещения, генерируемыми по полигонам. Ты присмотрись к такой конструкции, она прямая, удобная и простая. И скорее всего после такой программы дооптимизировать вручную не получится, кстати
Тебе осталось только на этом денежки заработать. Ты никак не понимаешь смысл NP полноты задачи. Сколько вариантов у 50 разных деталей на листе?


E>>>Ты можешь обхяснить, почему наследование, а не агрегирование?
E>>>3) Логика "квадарт -- наследник фигуры из 4-х точек" вообще ущербна в большинстве задач. И она ничем не оличается от логики "4-вектор -- это std::вектор из 4-х элементов"
E>>>Ты так и не ответил создаёшь ли ты наследников вектора определённых размерностей?..
E>>>если нет, то почему?
Зачем вообще вводить понятие квадрат, прямоугольник, окружность в реальной жизни?

S>> Я уже кучу примеров написал.
E>Ты не привёл пока ни одного КОНКРЕТНОГО примера алгоритма...

То есть вычисление периметра и площади окружности для тебя недостаточно? Почему для вычисления площади ты использушь соответствующие формулы, а не как n вектор?

S>>Думаю, что дальше уже бессмысленно что то говорить.
E>Ну ты на вопросы-то ответь?
E>а) Почему наследование, а не агрегирование?
E>б) Ты таки наследуешь из вектора 3-вектор, 4-вектор и т. д.?
E>б') Если таки нет, то почему?

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


E>>>Ну примеры-то *одних случаев* будут?..
S>> Я уже тебе их кучу привел.
E>Пока что ты привёл ровно один пример -- какой-то запутанный и неконкретный алгоритм оптимизации кроя, который, как потом ты сам же и написал, по факту ещё и не работает
E>Ещё ты приводил пример с площадью круга против площади n-угольника. Только я вообще ен понял чего это пример. Насколько я теюя понял, круг из n-угольника выводить вообще нельзя. Зато можно выводить из криволенейного n-угольника. Но если у нас в деле кривые, то и площадь и периметр круга снова становятся тривиальными...

Почему нельзя? Можно так и так. Просто некоторые станки работают только с массивом точек. Только с дугами. А некоторые и так и сяк. Окражности да, криволинейки нет.

S>> Ну так шимпанзе то мало, а коров и свиней полно.
E>Не совсем уловил, какое влияние на ответ "насколько печень Х похожа на печень человека?" зависит от численности Х?
E>В конце концов макак просто как грязи, и они намного ближе к человеку, чем свиньи. И, тем не менее...
E>В общем предлагаю это "свинское" направление обсуждения не развивать. Оно толкьо дополнительно иллюстрирует, что ООП в жизни реально нифига не присутствует. Но это и так, IMHO, понятно

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