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


B>>Допустим, но зачем тогда вообще добавлять 3451, если внешюю грань можно получить комбинацией первых пяти 123, 234, 345, 451, 512? Чтобы подогнать под шестёрку, да?
ЮЛ>Определите комбинацию контуров не как произвольную выборку их частей, а как любое их объединение с удалением общих частей. Так лучше?

Да, конечно лучше — симметрическая разность множеств рёбер.
Тут получается абелева группа, где минимальная мощность порождающего множества определяется формулой v-e+c.
А векторное пространство здесь получается над полем Галуа, где соответсвенно вектора это Эйлеровы циклы, линейная комбинация которых это симметрическая разность рёбер. Отсюда и набор базисных циклов.

B>>Я в первом же сообщении выделил несколько независимых/законченных алгоритмов. Уже забыли?
ЮЛ>Да я давно уже выделил 8 таких алгоритмов в своем коде и разбил их, — если вы читали эту тему, я назвал этот способ всего лишь разбиением книги на страницы, чисто технический метод для сокращения объема, но это совсем не решает проблему читаемости.

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

ЮЛ>Если уж говорить о рефакторинге, то я считаю совершенным именно что-то близкое к вашему пункту 3) буста. Но опять — на это нужно время. И не всегда его трата оправдана. Поэтому тут вы ломитесь в открытые ворота. А 1) у вас записано вынести алгоритм в отдельную функцию — и всё. Так он и так в отдельной функции.

В отдельной и трудноусвояемой, по большей части из-за её неподъемного размера.

B>>Какого скрипта? Если бы внутренние алгоритмы были отдельными чистыми функциями, то они бы элементарно тестировались юнит-тестами, что на порядок эффективнее "ручного запускания".
ЮЛ>Ну да, само собой. Только смысл готовить эти тесты, если они сами собой последовательно подготавливаются каждым предыдущим пройденным блоком? Лишняя работа.

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

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


B>>Допустим, но зачем тогда вообще добавлять 3451, если внешюю грань можно получить комбинацией первых пяти 123, 234, 345, 451, 512? Чтобы подогнать под шестёрку, да?
ЮЛ>Определите комбинацию контуров не как произвольную выборку их частей, а как любое их объединение с удалением общих частей. Так лучше?

Да, конечно лучше — симметрическая разность множеств рёбер.
Тут получается абелева группа, где минимальная мощность порождающего множества определяется формулой e-v+c.
А векторное пространство здесь получается над полем Галуа, где соответсвенно вектора это Эйлеровы циклы, линейная комбинация которых это симметрическая разность рёбер. Отсюда и набор базисных циклов. Так?

B>>Я в первом же сообщении выделил несколько независимых/законченных алгоритмов. Уже забыли?
ЮЛ>Да я давно уже выделил 8 таких алгоритмов в своем коде и разбил их, — если вы читали эту тему, я назвал этот способ всего лишь разбиением книги на страницы, чисто технический метод для сокращения объема, но это совсем не решает проблему читаемости.

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

ЮЛ>Если уж говорить о рефакторинге, то я считаю совершенным именно что-то близкое к вашему пункту 3) буста. Но опять — на это нужно время. И не всегда его трата оправдана. Поэтому тут вы ломитесь в открытые ворота. А 1) у вас записано вынести алгоритм в отдельную функцию — и всё. Так он и так в отдельной функции.

В отдельной и трудноусвояемой, по большей части из-за её неподъемного размера.

B>>Какого скрипта? Если бы внутренние алгоритмы были отдельными чистыми функциями, то они бы элементарно тестировались юнит-тестами, что на порядок эффективнее "ручного запускания".
ЮЛ>Ну да, само собой. Только смысл готовить эти тесты, если они сами собой последовательно подготавливаются каждым предыдущим пройденным блоком? Лишняя работа.

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