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

S> У тебя ничего нет сложного. Для вычисления площади окружности достаточно всего одного радиуса, для вычисления площади квадрата достаточно одной стороны.

Это просто не правда. Нужно не только сторону знать, но и тот факт,ч то это квадарт. А вот это уже может легко оказаться дороже, чем просто прожевать массив точек по формуле.
Особенно, если ты считаешь на какой-то суперпараллельной архитерктуре. Скажем на граф-карточке

E>>IMHO, Это говорит, что твоя прекрасная ООП-программа просто не работает. Долго и вычурно вычисляет не то...
S> Это не моя. Это K3.
"Твоя" в смысле "о которой ты писал". Если ты не имеешь отношения к её разработке, с чего ты взял, что там внутри такое странное ООП?
Ну и потом, похоже, там основное направление -- 3д можели всякие, визуализация, работа с ЧПУ и т. д. Оптимизация раскроя там просток ак-то написана. Не факт, что там хотя бы один нормальный математик в RnD есть, а не одни спецы по 3Д-моделям, как на сайте написано

S>Еще раз напомню класс задач NP полный. Как только ты прикинешь количество вариантов расположения 50 разных деталей на листе то все станет предельно ясно.
Слушай, я профессионально в AI математиком работаю. Я всё понимаю и говорю тебе, что не то они в совём Нижнем Новгороде делают.
В смысле то, конечно, так как им оптимальнй крой вообще не нужен. Им нужем минимально приемлемый. И то они не справляются, так как люди могут улучшить. Но и так сходит. Потому, что они продают не оптимизацию кроя, а автоматизацию бизнеса.

Впрочем, если тут есть люди из ЦИП "ГеоС", то можно было бы с ними обсудить что и как они делают почему и зачем и насколько хорошо выходит.
но я так думаю, что они под подпиской о неразглашении сидят, так что обсудить, даже если захотят, смогут сильно ограниченно

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

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

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

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


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

E>Не понимаю, что такое синус окружности, например? Или n-угольника?
Замечательный предел помнишь? И как расчитать площадь n угольника?

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

S> Тебе осталось только на этом денежки заработать.
не особо понятно как...

S> Ты никак не понимаешь смысл NP полноты задачи. Сколько вариантов у 50 разных деталей на листе?
А что, у 50 аппроксимированных кругами и сапогами деталей вариантов меньше что ли?..
Какой вообще выигрыш в структуре перебора ты получаешь за счёт всей этой ООП иерархии-то?

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

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

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

просто ответ на твой вопрос зависит от того, что и с чем ты сравниваешь.
В частности, если ты сравниваешь n-угольник, с окружностью, то ответь мне на вопрос. При каком n уже можно выводить из n-угольника окружность?..

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

Хорошо. Это зафиксируем. И зачем тогда тебе специальный код для окружностей? по идее площадь трапеции под дугой и длину дуги тебе всё равно надо вычислять уметь, окружность, в зависимости от семейства, у тебя, скорее всего задаётся двумя дугами или одной. И зачем ради замены одной формулы на другую мутить ООП?

S> Почему нельзя? Можно так и так. Просто некоторые станки работают только с массивом точек. Только с дугами. А некоторые и так и сяк. Окражности да, криволинейки нет.
В смысле? Не все фигуры можно вырезать на "некотрых станках" что ли? Или что?
Как вообще задача оптимального раскроя листа связана с форматом того данных для станка?

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

S>Классы — это наш способ моделировать реальность. И это — далеко не единственный способ. Посмотрите на javascript — он прекрасно обходится без классов, и многие аспекты реальных объектов его подход моделирует гораздо лучше.

Не заметно. Чуть не все фремворки используют классы на уровне библиотеки.

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

S> Я уже ничего не хочу. Еще раз. Любую фигуру я могу представить как массив точек и характер соединения точек.
Да, и это верно.

S>Для алгоритмов раскроя мне проще оперировать простыми фигурами котрыми я могу описать эту фигуру. Манипулировать этими фигурами я буду по единому интерфейсу, а пилить я буду по массиву точек.
Это тоже, скорее всего верно. Типа по каждой фигуре мы строим некий объект, который умеет генерироватьили содержит, осмысленные варианты размещения, умеет их как-то оптимизировать итерировать ипроверять, что нет пересечений.

Зачем с раскроем для станка и с этим объектом, условно "гипотезой о размещении" уметь работать как с одним и тем же типом?


S>>>синус косинус итд. Я же написал тригонометрия. Числовые методы интегрирования итд.
E>>Не понимаю, что такое синус окружности, например? Или n-угольника?
S>Замечательный предел помнишь? И как расчитать площадь n угольника?

Если у теюя n-угольник задан КООРДИНАТАМИ своих вершин (у тебя же так задан, я надеюсь?), то что бы рассчитать его площадь надо просто просумировать по кругу (x[i]-x[i+1])*(y[i] + y[i+1]) и разделить результат на 2. (Тут предполагается, что после последнего индекса +1 переходит снова к первому)
Правда площадь получится со знаком, который зависит в каком направлении описывался n-угольник. Но знак легко отбросить.
Этот метод быстрый, так как содержит всего-то 3N сложений и N умножений (ну и в конце надо ещё на 2 поделить, правда). При этом, если исходные данные целые, то и все промежуточные ТОЖЕ, так что он ещё всё вычисляет ТОЧНО, то есть вообще без погрешностей.

если же считать площадь по 3-ка по формуле Герона, а не по этой общей, то надо сначала вычислить три длины стороны (это уже куча умножений, сложений и три корня квадратных в конце), и эти все вычисления уже в плавучке и с погрешностями.
Потом эти длины сторон надо будет складывать и перемножать, а из результата извлекать корень. Можно пояснить на кой это вс делать?

Это типа первоапрельская шутка такая что ли?..

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



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

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

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

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

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

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

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

Дуга окружности отличается от произвольной кривой.

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

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

Занматься размещением простых фигур проще, чем крутить вертеть по маленькому углу многоугольные фигуры.


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

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

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

S> Обогнать по времени компиляции легко.
Обычно надо не по времени компиляции, а по хорошести её результатов...

S>Моих иерархий нигде может и не быть. Но они возможны и не значит, что они будут менее эффективны даже в первом приближении.

Ну ты это можешь как-то обосновать-то? Пока я так и не поянл, как всё это твоё ООП помогает как-то оптимизировать перебор?

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

E>>Конкретка-то будет?
S>Еще раз повторю, для расположения фигур на листе.
Это цель, а не алгоритм!

S> Дуга окружности отличается от произвольной кривой.
Обычно апроксимируют дугами кривых из какого-то семейства. например дугами кривых второго или там третьего порядка...

S> Занматься размещением простых фигур проще, чем крутить вертеть по маленькому углу многоугольные фигуры.

Ты перебираешь маленькие углы поворотов? Зачем? Можно же сразу вычислить на какой угол максимально можно повернуть фигуру в эту или в другую сторону?

S> Это от алгоритмов зависит. А чем проблемы раскроя не топ задача?
Ну пиши алгоритмы, решающие эту задачу. Просто нужны примеры КОНКРЕТНЫХ алгоритмов решающих КОНКРЕТНЫЕ задачи. Иначе разговор беспредметен.

S> Почему прямоугольник или прямоугольный треугольник не является наследником фигуры с массивом точек?
Это неправильный вопрос. Правильный вопрос "зачем им быть такими наследниками"?

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

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

S>> У тебя ничего нет сложного. Для вычисления площади окружности достаточно всего одного радиуса, для вычисления площади квадрата достаточно одной стороны.

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

E>>>IMHO, Это говорит, что твоя прекрасная ООП-программа просто не работает. Долго и вычурно вычисляет не то...
S>> Это не моя. Это K3.
E>"Твоя" в смысле "о которой ты писал". Если ты не имеешь отношения к её разработке, с чего ты взял, что там внутри такое странное ООП?
E>Ну и потом, похоже, там основное направление -- 3д можели всякие, визуализация, работа с ЧПУ и т. д. Оптимизация раскроя там просток ак-то написана. Не факт, что там хотя бы один нормальный математик в RnD есть, а не одни спецы по 3Д-моделям, как на сайте написано

Я тебе дал пример где это может использоваться. Кстати а чем агрегат лучше наследования? По сути в C++ агрегирование и множественное наследование мало чем отличаются.
Да и нейдобно обращаться через лишнюю точку.

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

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

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

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

S>> Тебе осталось только на этом денежки заработать.
E>не особо понятно как...

S>> Ты никак не понимаешь смысл NP полноты задачи. Сколько вариантов у 50 разных деталей на листе?
E>А что, у 50 аппроксимированных кругами и сапогами деталей вариантов меньше что ли?..
E>Какой вообще выигрыш в структуре перебора ты получаешь за счёт всей этой ООП иерархии-то?
ну получается столько вариантов, что их невозможно всех перебрать. Обычно устанавливается приемлемый коэффициент заполнения.
Про иерархию, я говорил о том, что в реальности прямоугольник является частным случаем фигугуры с массивом точек. Для программы раскроя проще оперировать прямоугольником, а резать как фигуру.
В реалии это может быть фигура вписанная в прямоугольник.Хочешь агрегат работвй с агрегатами. Мне проще как наследником. Опять же напомню С++ и множественное наследование.


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


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

E>Я вот не понимаю, ты говоришь об отрезках прямой или о кривых дугах? Если второе, то каких конкретно? (из какого семейства?)

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

Окружность можно легко представить как набор точек, с маленьким шагом между точками. Детерминированный случай. Но можно перейти, на описание сплайнами с достаточной погрешностью.

Опять же фигура это массив точек с соединением точек по прямой или криволинейный.

E>просто ответ на твой вопрос зависит от того, что и с чем ты сравниваешь.
E>В частности, если ты сравниваешь n-угольник, с окружностью, то ответь мне на вопрос. При каком n уже можно выводить из n-угольника окружность?..
Какая погрешность при соединении этих точек тебя устраивает? \lim_{x \to 0}\frac{\sin x}{x} = 1.

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

E>Хорошо. Это зафиксируем. И зачем тогда тебе специальный код для окружностей? по идее площадь трапеции под дугой и длину дуги тебе всё равно надо вычислять уметь, окружность, в зависимости от семейства, у тебя, скорее всего задаётся двумя дугами или одной. И зачем ради замены одной формулы на другую мутить ООП?

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

S>> Почему нельзя? Можно так и так. Просто некоторые станки работают только с массивом точек. Только с дугами. А некоторые и так и сяк. Окражности да, криволинейки нет.
E>В смысле? Не все фигуры можно вырезать на "некотрых станках" что ли? Или что?
E>Как вообще задача оптимального раскроя листа связана с форматом того данных для станка?

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




S>>>>синус косинус итд. Я же написал тригонометрия. Числовые методы интегрирования итд.
E>>>Не понимаю, что такое синус окружности, например? Или n-угольника?
S>>Замечательный предел помнишь? И как расчитать площадь n угольника?

E>Если у теюя n-угольник задан КООРДИНАТАМИ своих вершин (у тебя же так задан, я надеюсь?), то что бы рассчитать его площадь надо просто просумировать по кругу (x[i]-x[i+1])*(y[i] + y[i+1]) и разделить результат на
2. (Тут предполагается, что после последнего индекса +1 переходит снова к первому)
А теперь периметр посчитай.

E>Правда площадь получится со знаком, который зависит в каком направлении описывался n-угольник. Но знак легко отбросить.
E>Этот метод быстрый, так как содержит всего-то 3N сложений и N умножений (ну и в конце надо ещё на 2 поделить, правда). При этом, если исходные данные целые, то и все промежуточные ТОЖЕ, так что он ещё всё вычисляет ТОЧНО, то есть вообще без погрешностей.
Особенно это правильно делать для окружностей где достаточно хранить радиус. Для прямоугольника достаточно хранить две стороны.

E>если же считать площадь по 3-ка по формуле Герона, а не по этой общей, то надо сначала вычислить три длины стороны (это уже куча умножений, сложений и три корня квадратных в конце), и эти все вычисления уже в плавучке и с погрешностями.
E>Потом эти длины сторон надо будет складывать и перемножать, а из результата извлекать корень. Можно пояснить на кой это вс делать?
Для треуголька, прямоугольника проще оперировать сторонами. И поворачивать их на 10% в раскрое не имеет смысла.

E>Это типа первоапрельская шутка такая что ли?..
Ладно. Извини. Я на этом прекращу. А то это бесконечный разговор.

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

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

S>> Обогнать по времени компиляции легко.
E>Обычно надо не по времени компиляции, а по хорошести её результатов...

S>>Моих иерархий нигде может и не быть. Но они возможны и не значит, что они будут менее эффективны даже в первом приближении.

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

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

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

E>>>Конкретка-то будет?
S>>Еще раз повторю, для расположения фигур на листе.
E>Это цель, а не алгоритм!

S>> Дуга окружности отличается от произвольной кривой.
E>Обычно апроксимируют дугами кривых из какого-то семейства. например дугами кривых второго или там третьего порядка...
Про сплайны я уже упоминал.

S>> Занматься размещением простых фигур проще, чем крутить вертеть по маленькому углу многоугольные фигуры.

E>Ты перебираешь маленькие углы поворотов? Зачем? Можно же сразу вычислить на какой угол максимально можно повернуть фигуру в эту или в другую сторону?
Для многоугольников какой угол будет оптимальным? Он может зависеть от расположения ближайшей фигуры. Для прямоугольникв ближайшая сторона под прямым углом.
Для примера посмотри раскрои для портных, где криволинейки полно. И там как раз нужно крутить вертеть.

S>> Это от алгоритмов зависит. А чем проблемы раскроя не топ задача?
E>Ну пиши алгоритмы, решающие эту задачу. Просто нужны примеры КОНКРЕТНЫХ алгоритмов решающих КОНКРЕТНЫЕ задачи. Иначе разговор беспредметен.
Я не работаю с этими задачами, но в свое время интересовался.Максимум что делал это задача о рюкзаке. Но и там была куча вариаций без возможности полного перебора.
Поэтому мне понятна проблема с раскроем. Это более сложная задача, чем задача о рюкзаке.

S>> Почему прямоугольник или прямоугольный треугольник не является наследником фигуры с массивом точек?
E>Это неправильный вопрос. Правильный вопрос "зачем им быть такими наследниками"?
Нет есть реальное наследование. Прямоугольник это фигура. Все её свойства никуда не делись. Но добавились часные случаи, которыми проще оперировать.
И так может быть фигура не прямоугольником, но не может быть прямоугольника не фигурой. Мы можем работать с прямоугольником как с фигурой так и с прямоугольником зная его две стороны и угол наклона.
Если угол может быть всего в двух вариациях как 0 и 90 то еще проще с ним работать.

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

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

S> Я тебе дал пример где это может использоваться. Кстати а чем агрегат лучше наследования? По сути в C++ агрегирование и множественное наследование мало чем отличаются.
Логически отличаются сильно, и технически тоже много отличий есть.

S> Да и нейдобно обращаться через лишнюю точку.
А не надо через чтоку, лучше специальный метод для доступа иметь.
Зато читабельнее и код лучше структурируется.

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

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

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


S>> Да и нейдобно обращаться через лишнюю точку.
E>А не надо через чтоку, лучше специальный метод для доступа иметь.
E>Зато читабельнее и код лучше структурируется.
Я это и предлагал в разговоре с синклером. Где класс можно рассматрвать как свойсва виртуальных свойств как отдельно так и полностью.
Просто иногда некоторые свойства агрегатов перекрываются , но по сути имет одно и тот же смысл.
Понятно, что большая часть таких решений реализуется через интерфйсы, но можно напрмер сделать класс обертку который будет дергать нужные свойства например через делегаты, что бы не переопределять для всех свою реализацию.

Но по сути это тоже вариант наследования.

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

E>испоьзоват Мин-Макс координат, как описывающий прямоугольник для быстрой проверки пересечений не так уж и бессмысленно. Остальное не понимаю.
Ты видел раскрои портных? Там есть вогнутые, выгнутые, скошенные детали. Допустим у тебя есть треугольник, а рядом нужно поместить другой треугольник, так что бы общая площадь вписанная в прямоугольник была минимальна. Понятно, что они должны лежать типа 69. Здесь мин макс хорошо для описание через прямоугольник. Но вот более сложные фигуры нужно вертеть.

Здравствуйте, Serginio1, Вы писали:
S> Ну я уже упоминал тебе карты раскроя. Для каждого вида фигур можно сделать либо общий алгоримт перебора с поворотами на определенные углы. То для прямоугольников углы будут строго ограничены.
Как мне нравится ваш язык. "Либо" без второй альтернативы, "то" без если... Вы программы тоже так пишете?

S>А для Окружности вообще нечего поворачивать.

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

S> А вот для алгоритмов раскроя это очень важно.
"это" — это что? Сосредоточьтесь.
S> При этом оперировать проще простыми фигурам к которым можно приводить по похожести, а вот раскрой делать по набору точек. И есть явное наследование от фигуры с массивом точек.
Две эти ваши фразы никак не связаны между собой. Откуда наследование-то взялось? Зачем оно?

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

S> Ну мне ближе 1С там никаких классов нет. Одно процедурное программирование + модули обработки. Но вот всегда для решения множества задач необходимы классы, даже без иерархии но хотя бы с делегатами, которые в массе своей могут заменять перекрытие методов.
Вы только что смешали в одну кучу две существенно различные парадигмы, если что.

S>>Запрос интерфейса у объекта в дотнете вполне себе есть. То, как он сделан в COM, который вас вдохновляет, напрямую связано с поддержкой агрегации. А её, в свою очередь, сделали потому, что наследования реализации в COM сделать не получилось.
S> Нет не так как в ком. Смотри выше.
Что значит "нет"? Вы опять лезете в ненужные подробности. В дотнете запрос интерфейса сделан через приведение типа. А в COM — через специальный метод.
Сделано это потому, что в COM нельзя было полагаться на реализацию наследования, как в гомогенной архитектуре типа С++ или .Net. Вместо наследования в COM ввели агрегацию — а про неё знает только участник агрегата, исполняющая среда не может самостоятельно выполнить приведение. Вот и приходится делегировать работу по тайп-касту методу QueryInterface, который обязан реализовывать сам объект.

S>>Ключевое заблуждение выделено. Вся проблема — в том, что никакого наследования "на самом деле" нет. Никто не заводит новый тип документа в бухгалтерии как "давайте отнаследуемся от накладной на поступление и перекроем кое-какие виртуальные методы". Просто есть некий workflow, есть нужные для него реквизиты, и есть документ с этими реквизитами. Это вы приходите со своим замыленным ООП взглядом и говорите "о! давайте отнаследуем всё от документа ХХХ".
S> Ну вот я ничего в 1С не перекрываю. Горожу кучу копи пасте в пердопределенных методах. Нет строгости в наименованиии атрибутов, что приводит к сложности утинной типизации итд.
Зачем copy-paste? Я плохо знаком с 1С, наверное чего-то не понимаю.

S> Еще раз треугольник наследуется не от квадрата, а от абстрактной фигуры с массивом точек и абстрактными методами периметр и площадь. Она будет родителем для любой фигуры в том числе и множества частных случаев этих фигур.
Ещё раз: зачем наследовать треугольник? Все нужные от него методы уже реализованы для "фигуры из N точек". Вы же не думаете, что периметр трапеции вычисляется как-то иначе, чем периметр прямоугольника?

S> Есть, так как складские документы обязаны правильно взаимодействовать с регистрами накопления.
Документы никому ничего не обязаны. Они всего лишь хранят данные. То, что вы запихиваете в документы поведение — ваша вольность.

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

S> Но вот алгоритмы списания и набор реквизитов у них должен быть одинаковым (Как уже писал выше и утиную типизацию для ник применить сложно). Поэтому иногда хочется иметь свойства виртуальных свойств и на основании её общие свойства ( Просто иногда некие наборы атрибутов для каждого регистра могут дублироваться). При этом я не забуду об атрибутах необходимых для регистров и при этом могу применять алгоритмы только для определенного вида регистров.
Ничего не понимаю.

Здравствуйте, Serginio1, Вы писали:
S> Еще раз любая частная фигура есть потомок общей фигуры. Можно любую фигуру привести к частной как вписанную.
Всё строго наоборот. Вот у нас есть метод BoundingRect GetBoundingRect(Polygon p), который для любой фигуры строит вмещающий её прямоугольник.
Для всего набора фигур строим такие прямоугольники, и размещаем уже их. Получаем некий раскрой, оцениваем его оптимальность.
Можем сразу оценить перспективность раскроя, оценив соотношение площади исходной фигуры к вмещающему прямоугольнику.
Мы можем выбрать один из примитивов, на который исходная фигура наиболее похожа — опять же пройдясь по списку методов GetBoundingXXX и сравнив площади.
И так далее.

S>Мы работаем как с частной, а режем как реальную. Если мы работаем только с одной фигурой то хватает и агрегации, если добавляется в алгоритм еще фигура, то проще оперировать уже наследниками.
Совершенно непонятно, откуда берутся наследники. Алгоритмы размещения прямоугольников существенно отличаются от алгоритмов размещения кругов.
Поэтому один алгоритм будет работать с набором прямоугольников, другой — с набором кругов. Я хоть убей не понимаю, каким образом тут можно применить наследование.

S> У документов поведения, связанного со складом, нету вовсе.

из того, что у документа нет поведения связанного со складом, совсем не вытекает, что у документа должны отсутствовать методы, связанные со складов.


В качестве примера, можно взять gdocs — у документа есть метод Download as. Само же поведение вызываемое этим методом находится не в документе, документ является лишь проксей.