Здравствуйте, 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>
Ну пусть так, хотя а не люблю вешать громоздкие векторы в неизвестно как оптимизированные mapы.
Мое возражение касалось самого Style, который не число, а набор компонентов структуры. А вот с упорядоченностью структуры надо возиться. А смысла в этом нет — это искусство ради искусства.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Или вы полагаете, что не имея работы, я могу позволить себе ставить самые последние навороченные версии, которые так завораживают местных хомячков?
Express версия студии вроде ж вообще бесплатная.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Юрий Лазарев, Вы писали:
B>>Не, не пойдёт, это уже натягивание совы на глобус. B>>Во-первых вы пытаетесь посчитать внешнюю грань, хотя в своей интрепретации формулы Эйлера её отбросили. Вот полная формула Эйлера, учитывающая внешнюю грань: B>>faces = edges + components — vertices + 1 B>>в вашем же варианте нет "+ 1". ЮЛ>А в таком виде более узнаваемо? ЮЛ>(faces — 1) = edges + components — vertices
Так я же и говорю, что в вашей интрепретации CONTOURS = (faces — 1), то есть без учёта внешней грани.
Для K5 ваша интрепретация даёт CONTOURS = 6.
Если же брать faces из оригинальной формулы, то есть с учётом внешней грани, то получается 7.
Вы же, пытаясь натянуть сову на глобус, говорить что вот искомые 6 контуров:
ЮЛ>Обозначая последовательно узлы 1,2,3,4,5, эти контуры будут, например 123, 234, 345, 451, 512 и 12345.
При этом используя в том числе внешнюю грань 54321.
Вы либо крестик снимите, либо трусы наденьте. Точнее либо покажите 7 контуров с учётом внешней грани, либо 6 но без неё.
ЮЛ>Зачем мне вообще грани, можете сказать? Ни я, ни заказчик гранями не интересовались. Заказчик вообще не поймет, зачем их сюда привлекать. Его интересуют только контуры.
Ну это вы же используете формулу Эйлера, которая даёт количество граней (только отнимаете одну, видимо внешнюю).
B>>Во-вторых не учитываете 134 и ещё четыре подобных цикла. ЮЛ>Я виноват, — не полностью четко выписал определение контура. Дело в том, что при точном определении эти контуры Эйлера (соответствующие моей формуле)
Вы думаете если придумаете какое-то своё определение контуров, то формула Эйлера для них заработает "по щучьему веленью, по моему хотенью"?
ЮЛ>образуют базисный набор контуров, аналогичный векторам, столбцам матрицы и тп. Все прочие контуры тогда всегда могут быть разложены по этим базисным, и учитывать их не надо. Наоборот, за базисные всегда можно принять иную группу контуров, подчиняющихся точному определению базисных.
Сова уже трещит по швам. Расскажите пожалуйста, про своё векторное пространство контуров, их сложение и скалирование — или какая там у вас алгебраическая структура. А главное, как это соотносится с формулой Эйлера в случае планарных графов типа вот этого:
Тут-то какие контуры базисные, а какие нет?
ЮЛ>Физикам, знакомым с контурами Кирхгофа, это не надо объяснять.
Главное объясните это формуле Эйлера, а то по всей видимости она не в курсе
B>>В функцию длинной более тысячи строк и цикломатической сложностью за 300 (при рекомендованных значениях 10-15). При том что в этой функции элементарно очерчиваются обособленные алгоритмы. ЮЛ>Ну попробуйте придерживаться рекомендованных значений и не наплодить ненужной фрагментации.
Проверил в одном своём проекте — графы и линейная алгебра. Максимальное колличество строк на функцию меньше 30, максимальная цикломатическая сложность меньше 10. С фрагментацией никаких проблем.
B>>На 3. действительно ушло бы очень много времени, но этого никто и не требовал. У вас же нет даже 1. ЮЛ>Почему нет? Вы же вместо 1 делаете мне упрек в смысле 2, и тут же заявляете, что у меня нет 1. А где логика?
Логика в том, что __даже__ 1. нет, когда по хорошему нужно было делать 2.
B>>Опять двадцать пять. Прийдётся даже скопировать: Boost.Graph был приведён в качестве доказательства того, что такое разбиение возможно. ЮЛ>Я не могу пока его проверить, вы хотите, чтобы я вам верил на слово?
Вы не верите что поиск компонент связности можно вынести в отдельный алгоритм? А это ведь одна из частей вашей "неделимой" реализации.
B>>То есть тесты вы делали только когда уже отдали работу заказчику, на его тестовых данных? А до этого вообще код не запускали? ЮЛ>Разумеется, запускал. Разработка включает ряд итераций, в том числе и с участием заказчика, в малых сериях тестов.
Как именно вы делали эти тесты? Например как тестировали поиск компонент связности?
Запускали вручную программу, вручную выбирали входные файлы, или как?
L>В 2015 году код, который после написания нужно еще и отлаживать, считается говнокодом. Без вариантов. К код ревью даже не допускается.
Это, конечно, очень сильное заявление.
Я тут недавно прошелся по граблям разнообразных битностей и little/big endian, и, пожалуй, вынужден не согласитья с твоим заявлением.
Код без тестов — этот да, на ревью не допускается. Но код, который отлаживали, — почему бы и нет.
ЮЛ>Вообще то я не люблю "готовые" решения; если такие были в бусте, это вполне мог бы знать Манагер, по его рассказам уже собаку съевший на этом. Молчание доказывало, что там нечего искать. Сейчас очевидно, что его знакомство с бустом ненамного опережало мое.
Я что-то представил себе девелопера, подходящего и заявляющего, что, мол, не любит он готовые решения.
IMHO, велосипедостроение — самый страшный грех, которым только может страдать программист. А уж кривое велосипедостроение, без изучения уже существующих велосипедов... как тот самый сон разума. Чудовищ рождает.
Здравствуйте, Bender, Вы писали:
B>Так я же и говорю, что в вашей интрепретации CONTOURS = (faces — 1), то есть без учёта внешней грани.
Да забудьте же вы о гранях. Нет граней. Граней нет!
Наконец, 1 в этой формуле всего лишь Эйлерова характеристика плоскости, или сферы, (без учета многокомпонентности) — для тора, например, она равна 0. А в моей формуле нет этой характеристики, связанной с топологией поверхностей, она более общего вида для любого графа (нарисованного в любом пространстве).
B>Image: 100px-Complete_graph_K5.svg.png B>Для K5 ваша интрепретация даёт CONTOURS = 6. B>Если же брать faces из оригинальной формулы, то есть с учётом внешней грани, то получается 7.
Так 6 и будет. А 7 — это граней, которым вы в вашем рисунке не найдете даже места, потому что граф — непланарный.
B>Вы же, пытаясь натянуть сову на глобус, говорить что вот искомые 6 контуров: B>
ЮЛ>>Обозначая последовательно узлы 1,2,3,4,5, эти контуры будут, например 123, 234, 345, 451, 512 и 12345.
B>При этом используя в том числе внешнюю грань 54321.
"Внешний контур (а не грань) вполне можно заменить любым ему эквивалентным, например 3451 (в сумме с 123 он образует ту же "внешнюю грань").
Как я сказал, определение базового набора контуров (число которых выражает моя модифицированная формула Эйлера) было неполным. Попробую дать четкое определение:
"Это максимальный набор различных замкнутых циклов, смежных не менее чем по одному ребру (т.е. имеющих общим хотя бы 1 ребро), при котором всякий прочий цикл выражается составляющими базового набора, взятыми не более 1 раза (т.е. циклы, в которых путь образует базовый контур 1, потом 2, потом снова 1, потом 3, к примеру, где контур 1 взят два раза, допускают еще дальнейшее разложение).
B> либо покажите 7 контуров с учётом внешней грани, либо 6 но без неё.
Я не могу показать вам 7 контуров, потому что их только 6. И это независимо от того, "с учетом внешней грани", или без учета. Учет грани — ваши проблемы, я прекрасно обхожусь без граней.
Простейший случай — окружность (1 контур и 2 грани). Что я вам тут должен показать, 2 контура или 1? Но 2 контура я вам из кармана не выну, я не иллюзионист.
ЮЛ>>Зачем мне вообще грани, можете сказать? Ни я, ни заказчик гранями не интересовались. Заказчик вообще не поймет, зачем их сюда привлекать. Его интересуют только контуры. B>Ну это вы же используете формулу Эйлера, которая даёт количество граней (только отнимаете одну, видимо внешнюю).
Это вы используете стандартную формулу Эйлера для многогранника, а я — обобщенную.
B>Вы думаете если придумаете какое-то своё определение контуров, то формула Эйлера для них заработает "по щучьему веленью, по моему хотенью"?
Это не мое хотение, а известный науке факт. Кстати, 1е и 2е числа Бетти именно этому и соответствуют.
ЮЛ>>образуют базисный набор контуров, аналогичный векторам, столбцам матрицы и тп. Все прочие контуры тогда всегда могут быть разложены по этим базисным, и учитывать их не надо. Наоборот, за базисные всегда можно принять иную группу контуров, подчиняющихся точному определению базисных.
B>Сова уже трещит по швам. Расскажите пожалуйста, про своё векторное пространство контуров, их сложение и скалирование — или какая там у вас алгебраическая структура. А главное, как это соотносится с формулой Эйлера в случае планарных графов типа вот этого: B>Image: face_illustration.png B>Тут-то какие контуры базисные, а какие нет?
Выше все рассказал. А с вашим новым рисунком — планарным — все еще проще. Возьмите каждую минимальную грань и окружающий ее контур можно принять за базисный. Итого 7 контуров, 7+1 граней с учетом внешней.
Но вы можете с таким же успехом брать за базисные их независимые комбинвции — например, объединяя треугольники по два и называя образующий их контур базовым. Результат будет тем же, хотя менее очевидным и видимо не согласующимся с вашим представлением о контуре-грани.
B>>>На 3. действительно ушло бы очень много времени, но этого никто и не требовал. У вас же нет даже 1. ЮЛ>>Почему нет? Вы же вместо 1 делаете мне упрек в смысле 2, и тут же заявляете, что у меня нет 1. А где логика? B>Логика в том, что __даже__ 1. нет, когда по хорошему нужно было делать 2.
Где же тут логика? Вы настаиваете на " __даже__ 1. нет" бездоказательно, см.ваше определение 1.
Это "я так сказал"-подход манагеров, а не логики.
B>Вы не верите что поиск компонент связности можно вынести в отдельный алгоритм? А это ведь одна из частей вашей "неделимой" реализации.
Можно, только зачем? Код от этого лучше не станет.
B>Как именно вы делали эти тесты? Например как тестировали поиск компонент связности? B>Запускали вручную программу, вручную выбирали входные файлы, или как?
Вручную. Тесты хранит Компас, так что входные файлы выбирать не требуется. А вы считаете написание скрипта верхом совершенства?
Здравствуйте, SkyDance, Вы писали:
L>>В 2015 году код, который после написания нужно еще и отлаживать, считается говнокодом. Без вариантов. К код ревью даже не допускается.
SD>Это, конечно, очень сильное заявление. SD>Я тут недавно прошелся по граблям разнообразных битностей и little/big endian, и, пожалуй, вынужден не согласитья с твоим заявлением.
Как протокольных дел мастер, постоянно сталкивающийся с разнообразными битностями, little/big endian и способами кодирования простых вещей, придуманными явно под водзействием веществ, не вижу проблем.
Другое дело, если ты вообще до запуска системы даже не представлял, что столкнешься с этой проблемой.
SD>Код без тестов — этот да, на ревью не допускается. Но код, который отлаживали, — почему бы и нет.
Здравствуйте, landerhigh, Вы писали:
L>Если программисту в 2015 году "в процессе" работы с его собственным кодом нужен отладчик, то он явно занят не своим делом
Очень уж категорично заявлено.
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
L>>Если программисту в 2015 году "в процессе" работы с его собственным кодом нужен отладчик, то он явно занят не своим делом CC>Очень уж категорично заявлено.
Отладчик — хороший, но специализированный инструмент, но как и любой специализированный инструмент, его нужно использовать по назначению.
То, как его использует ТС, и не только он, судя по предыдущим подобным топикам — "скомпилировал, запустил, упало, запустил под отладчиком, нашел, исправил, скомпилировал, запустил, не упало, но функциональность сломана" есть ad-hoc или ковбойская разработка, результатом которой ничего, кроме говнокода, быть не может. Иными словами, разработчик сам не понимает, как будет работать код, им же написанный. Не говоря уже о том, что от написания первой линии кода с первым багом до собственно момента, когда этот код можно будет запустить в составе запускаемого приложения при отсутствии юнит-тестирования могут пройти месяцы. Известно, что зачастую несколько месяцев достаточно, чтобы отношение разраба к собственому же коду изменилось от "шедевр" до "кто этот шит написал?".
Особенно это понятно при разработке чего-то низкоуровневого вроде протоколов. Когда до собственно запуска под отладчиком нужно закончить собственно этот уровень протокола, и все уровни над ним, написать тестового клиента и тестовый сервер. И только потом у разработчика возникает возможность посмотреть в свой код отладчиком. А с ней и необходимость. Удачной отладки, как говорится. Не говоря уже о том, что вручную симулировать все возможные ситуации абсолютно невозможно.
Программист должен уметь проверять работоспособность своего кода и верифицировать функциональность без отладчика. Именно поэтому я всегда говорю, что я бы вообще у разработчиков отбирал отладчик на время собственно разработки.
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>Здравствуйте, Bender, Вы писали:
B>>Так я же и говорю, что в вашей интрепретации CONTOURS = (faces — 1), то есть без учёта внешней грани. ЮЛ>Да забудьте же вы о гранях. Нет граней. Граней нет!
Допустим. Число контуров в вашей интрепретации, на единицу меньше чем граней в оригинальной формуле. Откуда эта связь, как определён ваш "контур"?
B>>Вы же, пытаясь натянуть сову на глобус, говорить что вот искомые 6 контуров: B>>
ЮЛ>>>Обозначая последовательно узлы 1,2,3,4,5, эти контуры будут, например 123, 234, 345, 451, 512 и 12345.
B>>При этом используя в том числе внешнюю грань 54321. ЮЛ>"Внешний контур (а не грань) вполне можно заменить любым ему эквивалентным, например 3451 (в сумме с 123 он образует ту же "внешнюю грань").
Допустим, но зачем тогда вообще добавлять 3451, если внешюю грань можно получить комбинацией первых пяти 123, 234, 345, 451, 512? Чтобы подогнать под шестёрку, да?
ЮЛ>Как я сказал, определение базового набора контуров (число которых выражает моя модифицированная формула Эйлера) было неполным. Попробую дать четкое определение: ЮЛ>"Это максимальный набор различных замкнутых циклов, смежных не менее чем по одному ребру (т.е. имеющих общим хотя бы 1 ребро), при котором всякий прочий цикл выражается составляющими базового набора, взятыми не более 1 раза (т.е. циклы, в которых путь образует базовый контур 1, потом 2, потом снова 1, потом 3, к примеру, где контур 1 взят два раза, допускают еще дальнейшее разложение).
Вот если взять простую регулярную сетку из квадратов, например 5 квадратов на 5, всего 25 квадратов. Формула эйлера даст 26 граней, а ваша соответсвенно 25 контуров.
При этом очевидно, что многие из контуров квадратов, следуя вашему расплывчатому определению контурного базиса, не будут контуро-независимыми, и поэтому насобирать 25 независимых контуров у вас никак не получится.
B>> либо покажите 7 контуров с учётом внешней грани, либо 6 но без неё. ЮЛ>Я не могу показать вам 7 контуров, потому что их только 6. И это независимо от того, "с учетом внешней грани", или без учета. Учет грани — ваши проблемы, я прекрасно обхожусь без граней.
Пусть будет "с учётом внешнего контура"
B>>Вы думаете если придумаете какое-то своё определение контуров, то формула Эйлера для них заработает "по щучьему веленью, по моему хотенью"? ЮЛ>Это не мое хотение, а известный науке факт.
Известный факт? Сами до конца ещё не сформулировали свою контурно-базисную алгебру, а уже заявляете что формула Эйлера работает для неё
ЮЛ>>>образуют базисный набор контуров, аналогичный векторам, столбцам матрицы и тп. Все прочие контуры тогда всегда могут быть разложены по этим базисным, и учитывать их не надо. Наоборот, за базисные всегда можно принять иную группу контуров, подчиняющихся точному определению базисных.
B>>Сова уже трещит по швам. Расскажите пожалуйста, про своё векторное пространство контуров, их сложение и скалирование — или какая там у вас алгебраическая структура. А главное, как это соотносится с формулой Эйлера в случае планарных графов типа вот этого: B>>Image: face_illustration.png B>>Тут-то какие контуры базисные, а какие нет? ЮЛ>Выше все рассказал. А с вашим новым рисунком — планарным — все еще проще. Возьмите каждую минимальную грань и окружающий ее контур можно принять за базисный. Итого 7 контуров, 7+1 граней с учетом внешней.
Значит тут типа не нужен внешний контур потому что он составляется из базисных, но тогда зачем же он нужен в K5?
ЮЛ>Обозначая последовательно узлы 1,2,3,4,5, эти контуры будут, например 123, 234, 345, 451, 512 и 12345.
Тут 12345 точно также составляется из первых пяти
B>>>>На 3. действительно ушло бы очень много времени, но этого никто и не требовал. У вас же нет даже 1. ЮЛ>>>Почему нет? Вы же вместо 1 делаете мне упрек в смысле 2, и тут же заявляете, что у меня нет 1. А где логика? B>>Логика в том, что __даже__ 1. нет, когда по хорошему нужно было делать 2. ЮЛ>Где же тут логика? Вы настаиваете на " __даже__ 1. нет" бездоказательно, см.ваше определение 1. ЮЛ>Это "я так сказал"-подход манагеров, а не логики.
Я в первом же сообщении выделил несколько независимых/законченных алгоритмов. Уже забыли?
B>>Вы не верите что поиск компонент связности можно вынести в отдельный алгоритм? А это ведь одна из частей вашей "неделимой" реализации. ЮЛ>Можно, только зачем? Код от этого лучше не станет. B>>Как именно вы делали эти тесты? Например как тестировали поиск компонент связности? B>>Запускали вручную программу, вручную выбирали входные файлы, или как? ЮЛ>Вручную. Тесты хранит Компас, так что входные файлы выбирать не требуется. А вы считаете написание скрипта верхом совершенства?
Какого скрипта? Если бы внутренние алгоритмы были отдельными чистыми функциями, то они бы элементарно тестировались юнит-тестами, что на порядок эффективнее "ручного запускания".
Здравствуйте, Юрий Лазарев, Вы писали:
ЮЛ>В качестве примера — привожу последний наш разговор на фирме. Перед этим мне доверили разобрать их (такой ценный) код в попытке ответить одному из клиентов на недоуменный вопрос, почему их программа не выдает расстояний между точками, находящимися в разных локальных системах координат. Системы координат у них произвольные, т.е. с произвольной матрицей растяжения и поворота. Мне открыто в глаза было заявлено ЗМанагером, что расстояния измеряются только внутри локальных систем, а в разных системах расстояния будут зависеть от их расположения (!) и потому выводить расстояния нельзя.
Достаточно получить глобальные координаты соответствующих точек и измерить глобальное расстояние между ними.
ЮЛ>Мне как физику (а не ИТ хомяку) было заранее понятно, что тут что то не так. В реальном мире (а не в ИТ "Матрице") расстояния инвариантны независимо от координат. Обдумав ситуацию, на след.день я пришел к ним обрадовать их известием, что они неправильно измеряют расстояния, что в произвольной системе координат метрические измерения нельзя производить без учета метрического тензора, и что по видимому, они просто не знают основ математики.
Метрический тензор помог бы измерить глобальное расстояние между точками с координатами в одной локальной системе. Но как вы собрались использовать его для измерения расстояния между точками заданных координатами в разных локальных системах?
Здравствуйте, Bender, Вы писали:
B>Допустим, но зачем тогда вообще добавлять 3451, если внешюю грань можно получить комбинацией первых пяти 123, 234, 345, 451, 512? Чтобы подогнать под шестёрку, да?
Определите комбинацию контуров не как произвольную выборку их частей, а как любое их объединение с удалением общих частей. Так лучше?
B>Вот если взять простую регулярную сетку из квадратов, например 5 квадратов на 5, всего 25 квадратов. Формула эйлера даст 26 граней, а ваша соответсвенно 25 контуров. B>При этом очевидно, что многие из контуров квадратов, следуя вашему расплывчатому определению контурного базиса, не будут контуро-независимыми, и поэтому насобирать 25 независимых контуров у вас никак не получится.
Как говорил наш препод матана, если очевидно, так докажи.
B>Известный факт? Сами до конца ещё не сформулировали свою контурно-базисную алгебру, а уже заявляете что формула Эйлера работает для неё
Она существует, это более "очевидно", чем ваши очевидности. Я вам подбираю геометрическую формулировку. А можно при желании записать ее и в матричной форме.
B>Тут 12345 точно также составляется из первых пяти
Тож же самое, что и выше.
B>Я в первом же сообщении выделил несколько независимых/законченных алгоритмов. Уже забыли?
Да я давно уже выделил 8 таких алгоритмов в своем коде и разбил их, — если вы читали эту тему, я назвал этот способ всего лишь разбиением книги на страницы, чисто технический метод для сокращения объема, но это совсем не решает проблему читаемости.
Если уж говорить о рефакторинге, то я считаю совершенным именно что-то близкое к вашему пункту 3) буста. Но опять — на это нужно время. И не всегда его трата оправдана. Поэтому тут вы ломитесь в открытые ворота. А 1) у вас записано вынести алгоритм в отдельную функцию — и всё. Так он и так в отдельной функции.
B>Какого скрипта? Если бы внутренние алгоритмы были отдельными чистыми функциями, то они бы элементарно тестировались юнит-тестами, что на порядок эффективнее "ручного запускания".
Ну да, само собой. Только смысл готовить эти тесты, если они сами собой последовательно подготавливаются каждым предыдущим пройденным блоком? Лишняя работа.
Здравствуйте, Bender, Вы писали:
B>Достаточно получить глобальные координаты соответствующих точек и измерить глобальное расстояние между ними.
Естественно, но не все так просто доходит до ИТ спецов. Те же евклидовы расстояния у них вычислялись и между точками в одной локальной системе (т.е.заведомо неверно)
B>Метрический тензор помог бы измерить глобальное расстояние между точками с координатами в одной локальной системе. Но как вы собрались использовать его для измерения расстояния между точками заданных координатами в разных локальных системах?
Все координаты приводятся к одной системе координат (локальной или глобальной, на ваш вкус). С глобальным же расстоянием вообще нет нужды вычислять метрический тензор, достаточно просто получить глобальные координаты и вычислить обычное евклидово расстояние (если только у вас само пространство не риманово ))).
Но чтобы правильно вычислять, надо для начала хотя бы иметь об этом представление. Т.е. заниматься не пустыми филологическо-лексическими формальностями (код не нравится), а реальными физическими вещами (старый спор физиков с лириками, причем из ИТ еще и никудышные лирики)
L>Программист должен уметь проверять работоспособность своего кода и верифицировать функциональность без отладчика. Именно поэтому я всегда говорю, что я бы вообще у разработчиков отбирал отладчик на время собственно разработки.
Такой вариант процесса тоже существует.
Но надо понимать, что "отладчик" никуда не девается, просто вместо универсального инструмента сторонней разработки применяется "отладчик" в виде пачки тестов.
Безусловный плюс этого подхода в том, что после окончания отладки тесты никуда не исчезают и будут затем повторно использоваться.
Здравствуйте, SkyDance, Вы писали:
SD>Такой вариант процесса тоже существует. SD>Но надо понимать, что "отладчик" никуда не девается, просто вместо универсального инструмента сторонней разработки применяется "отладчик" в виде пачки тестов.
В том-то и дело, что это не отладчик. А просто другой, весьма специализированный инструмент, которым тоже нужно уметь пользоваться.
SD>Безусловный плюс этого подхода в том, что после окончания отладки тесты никуда не исчезают и будут затем повторно использоваться.
Не только в этом. Огормный плюс этого подхода в том, что он позволяет практически бесплатно и со 100% повторяемостью прогонять код в условиях, которых либо "в реальной жизни никогда не бывает", либо те, которые просто при ручном отладочном прогоне невозможно создать, а чаще всего и тех и других.
L>В том-то и дело, что это не отладчик. А просто другой, весьма специализированный инструмент, которым тоже нужно уметь пользоваться.
В своё время дебаггер считали такой же "серебряной пулей".
Честно скажу — нет никакой серебряной пули. Иногда для того, чтобы написать тест, нужно найти (дебаггером, да) проблему. Не факт, что она (проблема) в твоём коде. Может быть где угодно, от ядра ОС до микрокода процессора.
Здравствуйте, SkyDance, Вы писали:
L>>В том-то и дело, что это не отладчик. А просто другой, весьма специализированный инструмент, которым тоже нужно уметь пользоваться.
SD>В своё время дебаггер считали такой же "серебряной пулей".
А кто говорит по серебряную пулю? Это просто инструмент, гораздо лучше подходящий для верификации в процессе разработки. Правда, в сравнении с "скомпилировал, запустил, упало, запустил под отладчиком, нашел, исправил, скомпилировал, запустил, не упало, но функциональность сломана" это и правда пуля из благородного металла.
SD>Честно скажу — нет никакой серебряной пули. Иногда для того, чтобы написать тест, нужно найти (дебаггером, да) проблему.
Проблемы, находимые дебаггером — это такая халява, что даже неинтересно.
SD>Не факт, что она (проблема) в твоём коде. Может быть где угодно, от ядра ОС до микрокода процессора.
Совершенно верно. Как тебе проблема, которая всплывает только в определенный день високосного года в случае, если устройству был отправлена команда на согласование времени с сервером исключительно после отправки двух других специальных команд при условии, что сеть построена на оборудовании вендора А и по пути происходит коллизия, приводящая к повтору команды? В итоге это оказался все же баг в коде, но отладчиком такое не найти. Нашлось исключительно написанием специального функционального теста с последующией идентификацией ответственного модуля и написанием уже юнит-теста для проблемы.
А уж примеров проблем во внешнем оборудовании тоже до чертиков, когда баг назначают на систему, а она оказывается вот совсем не виноватая!
П.С. Сейчас, именно благодаря юнит-тестам, нашел багу в оптимизаторе MSVS 2012. Минимизировать не удается, а весь проект засылать им нихачу.
B>>Допустим, но зачем тогда вообще добавлять 3451, если внешюю грань можно получить комбинацией первых пяти 123, 234, 345, 451, 512? Чтобы подогнать под шестёрку, да? ЮЛ>Определите комбинацию контуров не как произвольную выборку их частей, а как любое их объединение с удалением общих частей. Так лучше?
Да, конечно лучше — симметрическая разность множеств рёбер.
Тут получается абелева группа, где минимальная мощность порождающего множества определяется формулой e-v+c.
А векторное пространство здесь получается над полем Галуа, где соответсвенно вектора это Эйлеровы циклы, линейная комбинация которых это симметрическая разность рёбер. Отсюда и набор базисных циклов. Так?
B>>Я в первом же сообщении выделил несколько независимых/законченных алгоритмов. Уже забыли? ЮЛ>Да я давно уже выделил 8 таких алгоритмов в своем коде и разбил их, — если вы читали эту тему, я назвал этот способ всего лишь разбиением книги на страницы, чисто технический метод для сокращения объема, но это совсем не решает проблему читаемости.
Наоборот решает. Вот был бы поиск компонент связности в отдельной чистой функции, да ещё и с юнит-тестами, сразу бы было намного читаемее.
ЮЛ>Если уж говорить о рефакторинге, то я считаю совершенным именно что-то близкое к вашему пункту 3) буста. Но опять — на это нужно время. И не всегда его трата оправдана. Поэтому тут вы ломитесь в открытые ворота. А 1) у вас записано вынести алгоритм в отдельную функцию — и всё. Так он и так в отдельной функции.
В отдельной и трудноусвояемой, по большей части из-за её неподъемного размера.
B>>Какого скрипта? Если бы внутренние алгоритмы были отдельными чистыми функциями, то они бы элементарно тестировались юнит-тестами, что на порядок эффективнее "ручного запускания". ЮЛ>Ну да, само собой. Только смысл готовить эти тесты, если они сами собой последовательно подготавливаются каждым предыдущим пройденным блоком? Лишняя работа.
Данные от предыдущего блока могут быть с ошибкой. Хуже того, два последовательных блоков могут содержать ошибки которые маскируют друг друга на большинстве данных.
Вообще говоря тестировать систему в целом тоже необходимо, это называется интеграционное тестирование. Но оно не заменяет юнит-тестирование.
Причём и то и то нужно автоматизировать, а не запускать постоянно вручную одни и те же тесты. Вот когда функции выполняют чёткую задачу — их и тестировать легко.
Здравствуйте, Юрий Лазарев, Вы писали:
B>>Достаточно получить глобальные координаты соответствующих точек и измерить глобальное расстояние между ними. ЮЛ>Естественно, но не все так просто доходит до ИТ спецов. Те же евклидовы расстояния у них вычислялись и между точками в одной локальной системе (т.е.заведомо неверно)
Почему же заведомо неверно? Расстояния вполне могут иметь разную природу.
Например на одном листе два чертежа, у каждого своя локальная система, причём на самом листе они могут быть растянуты как угодно. Тут евклидово расстояние в локальных координатах может вполне иметь смысл (например известны "оригинальные" локальные координаты точек и между ними вычисляется расстояние). При этом также имеют смысл и "глобальные" расстояния на самом листе, которые можно измерить линейкой — например для вычисления оптимального размера какой-нибудь аннотации.
B>>Метрический тензор помог бы измерить глобальное расстояние между точками с координатами в одной локальной системе. Но как вы собрались использовать его для измерения расстояния между точками заданных координатами в разных локальных системах? ЮЛ>Все координаты приводятся к одной системе координат (локальной или глобальной, на ваш вкус). С глобальным же расстоянием вообще нет нужды вычислять метрический тензор, достаточно просто получить глобальные координаты и вычислить обычное евклидово расстояние (если только у вас само пространство не риманово ))).
Я подумал что вы как-то собрались использовать __только__ метрический тензор для вычисления растояния на паре координат из разных локальных систем, поэтому и удивился.
ЮЛ>Но чтобы правильно вычислять, надо для начала хотя бы иметь об этом представление. Т.е. заниматься не пустыми филологическо-лексическими формальностями (код не нравится), а реальными физическими вещами (старый спор физиков с лириками, причем из ИТ еще и никудышные лирики)
Никакие это не лирики, а инженеры. И никакие это не формальности филологические, а вполне себе объективные измеряемые технические вещи.
