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

B>Не, не пойдёт, это уже натягивание совы на глобус.
B>Во-первых вы пытаетесь посчитать внешнюю грань, хотя в своей интрепретации формулы Эйлера её отбросили. Вот полная формула Эйлера, учитывающая внешнюю грань:
B>faces = edges + components — vertices + 1
B>в вашем же варианте нет "+ 1".

А в таком виде более узнаваемо?
(faces — 1) = edges + components — vertices
Зачем мне вообще грани, можете сказать? Ни я, ни заказчик гранями не интересовались. Заказчик вообще не поймет, зачем их сюда привлекать. Его интересуют только контуры.

B>Во-вторых не учитываете 134 и ещё четыре подобных цикла.

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

B>Я спросил где конкретно, потому что там это есть в нескольких местах.
Тогда я не понял, какое это имеет для вас значение, где конкретно? Разве в разных местах параллельности трактуются не одинаково?

B>В функцию длинной более тысячи строк и цикломатической сложностью за 300 (при рекомендованных значениях 10-15). При том что в этой функции элементарно очерчиваются обособленные алгоритмы.
Ну попробуйте придерживаться рекомендованных значений и не наплодить ненужной фрагментации.

B>На 3. действительно ушло бы очень много времени, но этого никто и не требовал. У вас же нет даже 1.
Почему нет? Вы же вместо 1 делаете мне упрек в смысле 2, и тут же заявляете, что у меня нет 1. А где логика?

B>Опять двадцать пять. Прийдётся даже скопировать: Boost.Graph был приведён в качестве доказательства того, что такое разбиение возможно.
Я не могу пока его проверить, вы хотите, чтобы я вам верил на слово?

B>То есть тесты вы делали только когда уже отдали работу заказчику, на его тестовых данных? А до этого вообще код не запускали?
Разумеется, запускал. Разработка включает ряд итераций, в том числе и с участием заказчика, в малых сериях тестов. Люди постоянно интересовались ходом разработки, и я не делал из этого тайны за семью печатями. Более того, только практические тесты и давали самую ценную пищу для развития — чего не придумаешь специально, сидя в офисе наедине с мышкой.

B>Да нет огорода, а получается проще чем с ручным линейным поиском:
B>

B>map<Style, vector<Curve>> locCurvesPool;
B>// ...
B>    locCurvesPool[currentStyle].push_back(currentCurve);
B>

Ну пусть так, хотя а не люблю вешать громоздкие векторы в неизвестно как оптимизированные mapы.
Мое возражение касалось самого Style, который не число, а набор компонентов структуры. А вот с упорядоченностью структуры надо возиться. А смысла в этом нет — это искусство ради искусства.

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

B>Не, не пойдёт, это уже натягивание совы на глобус.
B>Во-первых вы пытаетесь посчитать внешнюю грань, хотя в своей интрепретации формулы Эйлера её отбросили. Вот полная формула Эйлера, учитывающая внешнюю грань:
B>faces = edges + components — vertices + 1
B>в вашем же варианте нет "+ 1".

А в таком виде более узнаваемо?
(faces — 1) = edges + components — vertices
Зачем мне вообще грани, можете сказать? Ни я, ни заказчик гранями не интересовались. Заказчик вообще не поймет, зачем их сюда привлекать. Его интересуют только контуры.

B>Во-вторых не учитываете 134 и ещё четыре подобных цикла.

Я виноват, — не полностью четко выписал определение контура. Дело в том, что при точном определении эти контуры Эйлера (соответствующие моей формуле) образуют базисный набор контуров, аналогичный векторам, столбцам матрицы и тп. Все прочие контуры тогда всегда могут быть разложены по этим базисным, и учитывать их не надо. Наоборот, за базисные всегда можно принять иную группу контуров, подчиняющихся точному определению базисных.
Физикам, знакомым с контурами Кирхгофа, это не надо объяснять.

B>Я спросил где конкретно, потому что там это есть в нескольких местах.
Тогда я не понял, какое это имеет для вас значение, где конкретно? Разве в разных местах параллельности трактуются не одинаково?

B>В функцию длинной более тысячи строк и цикломатической сложностью за 300 (при рекомендованных значениях 10-15). При том что в этой функции элементарно очерчиваются обособленные алгоритмы.
Ну попробуйте придерживаться рекомендованных значений и не наплодить ненужной фрагментации.

B>На 3. действительно ушло бы очень много времени, но этого никто и не требовал. У вас же нет даже 1.
Почему нет? Вы же вместо 1 делаете мне упрек в смысле 2, и тут же заявляете, что у меня нет 1. А где логика?

B>Опять двадцать пять. Прийдётся даже скопировать: Boost.Graph был приведён в качестве доказательства того, что такое разбиение возможно.
Я не могу пока его проверить, вы хотите, чтобы я вам верил на слово?

B>То есть тесты вы делали только когда уже отдали работу заказчику, на его тестовых данных? А до этого вообще код не запускали?
Разумеется, запускал. Разработка включает ряд итераций, в том числе и с участием заказчика, в малых сериях тестов. Люди постоянно интересовались ходом разработки, и я не делал из этого тайны за семью печатями. Более того, только практические тесты и давали самую ценную пищу для развития — чего не придумаешь специально, сидя в офисе наедине с мышкой.

B>Да нет огорода, а получается проще чем с ручным линейным поиском:
B>

B>map<Style, vector<Curve>> locCurvesPool;
B>// ...
B>    locCurvesPool[currentStyle].push_back(currentCurve);
B>

Ну пусть так, хотя а не люблю вешать громоздкие векторы в неизвестно как оптимизированные mapы.
Мое возражение касалось самого Style, который не число, а набор компонентов структуры. А вот с упорядоченностью структуры надо возиться. А смысла в этом нет — это искусство ради искусства.