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

I>>Если кусок локализован, то не ясно, для чего бумажка

E>Ну, например, локализован точностью до стони строк. Скажем, что такой-то алгоритм, вернее такая-то его реализация работает не так, как ожидалось.
E>Что делаем дальше?

Дальше нужно отследить все зависимости в этом коде и разобраться с каждой из них. Не бывает проблем без проблемных зависимостей.

I>>Какое преимущество у бумажки перед редактором кода тем же ?
E>Возможность легко писать, чиркать, рисовать...

Ну чиркай себе на бумаге. У меня обычно с собой блокнот есть для такого, и карандаш и нож для заточки карандаша

Но вот не пойму, для чего нужно распечатку кода с собой носить

Код это всегда и везде зависимости, которые нужно отрабатывать.

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

Если же зависимостей не будет или количество будет некритичным, то задача сводится к функции и решается через тестирование.

И вот как тебе распечатка кода поможет искать зависимости — ума не приложу.

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

E>>>Слушай, а как ты ищешь ошибки в алгоритмах? Какое формальное представление алгоритма используешь и какими инструментами пользуешься?
I>>Рисую алгоритм на бумаге

E>Что значит "рисую алгоритм"? Блок-схему? Пример привести можешь?
E>IMHO, запись на ЯП намного лучше блок-схемы.

Рисуешь как тебе удобно. Я бы из блокнота отсканировал, но нет у меня сканера под рукой. Иногда удобно вместо рисования таблички заполнть. Иногда даже псевдокод писать.

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

I>>Ты не увиливай — бумага это одно, а распечатка кода — совсем другое.
E>Важное свойство распечатки то, что на ней легко рисовать и писать.

А без распечатки нельзя что ли рисовать и писать ? У меня вот получается

I>>Я на распознавании не специализируюсь. Но сильно сомневаюсь, что качество распознавания можно поднять распечатывая код на бумагу.
E>Распечатывать код надо не для этого. А для нетривиального анализа кода.

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

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

В софте даже спящие процессы вроде while(true) Sleep(1000); влияют друг на друга

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

E>>Ну, например, локализован точностью до стони строк. Скажем, что такой-то алгоритм, вернее такая-то его реализация работает не так, как ожидалось.
E>>Что делаем дальше?

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

Но давай вернёмся к нашим примерам.
1) Взрыв QSort'а.
Алгоритм совершенно замкнут в себе. Зависимостей нет никаких. Мы подогнали какие-то данные и получили на них не O(N log N), а O( N*N ).
Данные -- массив чисел типа double.
Что делаем дальше?

2) Сжатие RLE картинки. Опять же замкнутый в себе алгоритм. Чё за зависимости нам надо выявить?

I>Ну чиркай себе на бумаге. У меня обычно с собой блокнот есть для такого, и карандаш и нож для заточки карандаша
Ну на распечатке можно писать камменты к коду, а не просто камменты к бумажке...

I>Код это всегда и везде зависимости, которые нужно отрабатывать.
Ну покажи это на моих примерах. Я же давно у тебя мастер-класс прошу...

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

I>Если же зависимостей не будет или количество будет некритичным, то задача сводится к функции и решается через тестирование.
Ну покажи как оно решается-то?

I>И вот как тебе распечатка кода поможет искать зависимости — ума не приложу.
Никак. Она нужна для другого. Для статического анализа алгоритма, представленного в виде распечатанного кода. Например, для доказательства его правильности, либо выявления условий, при которых правильность таки можно гарантировать...

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

I>Рисуешь как тебе удобно. Я бы из блокнота отсканировал, но нет у меня сканера под рукой. Иногда удобно вместо рисования таблички заполнть. Иногда даже псевдокод писать.

Что за таблички?
В любом случае не ясно, как ты обеспечиваешь, что твои рисунки соответствуют анализируемому коду?

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

E>Лучше пусть мастер-класс даст. А то вдруг он Дейкстру таки почитает и утратит своё кунг-фу. А я его так и не посмотрю...

А вот интересно. Нам, с практической точки зрения, не обязательно иметь строгое доказательство работы того или иного алгоритма (да и невозможно его получить, поскольку доказательство само может содержать ошибки). Нам достаточно знать, что алгоритм верен с определенной вероятностью. Скажем, если вероятность ошибки меньше, чем 2^-128, то с практической точки зрения это то же самое, что 100%-верный алгоритм; вероятность сбоя аппаратуры значительно выше (причем даже принебрегая ошибками в аппаратуре — просто вероятность сбоя от того, что битик в регистре переключится сам собой из-за теплового шума).

В связи с этим возникает забавный философический вопрос: можно ли так покрыть программу тестами, чтобы уменьшить вероятность ошибок до заданного уровня (естественно, имея ввиду вероятность ошибок в полном комплекте, программа+тесты). Или, более частный вопрос, можно ли быть уверенным, что от добавления очередного теста совокупная вероятность ошибок уменьшается? Насколько быстро она уменьшается? Можно ли проектировать тесты не от фонаря, а чтобы вероятность ошибок уменьшалась быстро? Будет ли это более или менее трудоемко, чем строгое доказательство? Если нанять миллион индусов, что будет быстрее, строго доказать программу, или снизить вероятность ошибок в ней до практически приемлимого уровня?

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

I>Не надо для этого печатать код код это всегда зависимости, которые можно и нужно отрабатывать.
Это утверждение требует доказательств. Проведи его на примере функции для сжатия RLE-изображений, например.


I>При чем если ты распечатал только критический участок, этого как правило всегда мало. Для каждой зависимости нужно тоже смотреть код, особенно если имеет место всякая суровая императивщина с указателями, индексами и оптимизациями.

Это, всего лишь, обозначает одно из двух. Либо ты неверно выделил критический участок, либо ты совсем не ориентируешься в коде и тебе надо смотреть вообще всё

I>В софте даже спящие процессы вроде while(true) Sleep(1000); влияют друг на друга
Тоже интересно бы узнать, как такой процесс влияет на цвета пикселей, полученных в результате ошибки алгоритма сжатия. Или на взрыв QSort'а...

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

E>Но давай вернёмся к нашим примерам.
E>1) Взрыв QSort'а.
E>Алгоритм совершенно замкнут в себе. Зависимостей нет никаких. Мы подогнали какие-то данные и получили на них не O(N log N), а O( N*N ).
E>Данные -- массив чисел типа double.
E>Что делаем дальше?

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

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

Pzz>В связи с этим возникает забавный философический вопрос: можно ли так покрыть программу тестами, чтобы уменьшить вероятность ошибок до заданного уровня (естественно, имея ввиду вероятность ошибок в полном комплекте, программа+тесты). Или, более частный вопрос, можно ли быть уверенным, что от добавления очередного теста совокупная вероятность ошибок уменьшается? Насколько быстро она уменьшается? Можно ли проектировать тесты не от фонаря, а чтобы вероятность ошибок уменьшалась быстро? Будет ли это более или менее трудоемко, чем строгое доказательство? Если нанять миллион индусов, что будет быстрее, строго доказать программу, или снизить вероятность ошибок в ней до практически приемлимого уровня?

Я же говорю, что подветку давно пора в "философию" отделять. Она намного интереснее оригинального флейма про скобки

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

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

Так тоже, к сожалению бывает. Во всяком случае меня и нанимали и комадировали Правда пара-тройка недель -- это как-то долго.

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

Pzz>>В связи с этим возникает забавный философический вопрос: можно ли так покрыть программу тестами, чтобы уменьшить вероятность ошибок до заданного уровня (естественно, имея ввиду вероятность ошибок в полном комплекте, программа+тесты). Или, более частный вопрос, можно ли быть уверенным, что от добавления очередного теста совокупная вероятность ошибок уменьшается? Насколько быстро она уменьшается? Можно ли проектировать тесты не от фонаря, а чтобы вероятность ошибок уменьшалась быстро? Будет ли это более или менее трудоемко, чем строгое доказательство? Если нанять миллион индусов, что будет быстрее, строго доказать программу, или снизить вероятность ошибок в ней до практически приемлимого уровня?

E>Я же говорю, что подветку давно пора в "философию" отделять. Она намного интереснее оригинального флейма про скобки

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

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

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

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

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

Похожую проблему я решал таким образом — тупо использовал свободное пространство в структуре(из за выравнивания) что бы сохранить исходный индекс элемента.

Мне не надо было дампить ничего, просто нужно было знать, кто каким пришел по счету и что с этим делать. Потому я нумеровал элементы, а потом восстанавливал последовательность. Детектил чз GetThreadTimes + rdtsc + QueryPerformanceСounter.

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

Сильно думаю, CreatorCray имел сказать этот или похожий способ.

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

Не, ближайшие две недели у меня мозг занят другими делами.

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

Ты предложил задачу которая решается чз функциональщину, со всеми потрохами без сайдэффектов

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

I>>Вот тебе простой пример — около 100кб кода на ассемблере, эмулятора нет, комп один на троих-четверых, разрабатываемая станция одна на несколько секторов, отладчика нет, вывода в консоль, дампов, логов — ничего нет. Все что есть — светодиоды на задней панели станции, схема тестируемого блока.

I>>Вот это тот случай, где нужна распечатка, что бы не курить бамбук, пока нет ни компа ни станции.

Pzz>Нет, это как раз тот случай, когда надо написать эмулятор.

И на чем его писать, на листочке бумаги и выполнять на рулоне бумаги ?

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

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

Pzz>>Нет, это как раз тот случай, когда надо написать эмулятор.

I>И на чем его писать, на листочке бумаги и выполнять на рулоне бумаги ?

Как на чем? На Си

Никто ж не утверждает, что бумажка и ручка — единственный полезный инструмент.

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

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

I>Сильно думаю, CreatorCray имел сказать этот или похожий способ.

Наверное я как-то непонятно пишу, или мы разной терминологией пользуемся. Я уж не знаю.
Попробую объяснить очень подробно.
Вот смотри, всё, что ты написал выше -- это просто предварительный этап. Он ОЧЕНЬ ПРОСТОЙ. Но вот мы поняли на какой последовательности происходит взрыв.
Теперь нам надо ответить на два вопроса.
1) Насколько это вообще закономерно? То есть нам нереально фатально не повезло, или наши данные обладают какой-то особенностью, которая делает вероятность взрыва данной конкретной реализации QSort не такой уж и невероятной?
2) Что и как надо поправить, что бы сделать такое стечение обстоятельств невероятным?

Для простоты, давай считать, что реализация QSotr наша, её код доступен и для анализа и для модификации...

Итак, мы знаем, что эти 10 000 double, которые мы получаем из такого-то источника приводят нашу реализацию QSort к взрыву.
И вот тут на сцену выходит необходимость нетривильного анализа алгоритма. Что бы делаем дальше?

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

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

Это никакое не сильное, это скучная банальность.

E>Но давай вернёмся к нашим примерам.
E>1) Взрыв QSort'а.
E>Алгоритм совершенно замкнут в себе. Зависимостей нет никаких. Мы подогнали какие-то данные и получили на них не O(N log N), а O( N*N ).
E>Данные -- массив чисел типа double.
E>Что делаем дальше?

дальше можно попробовать сортировать структуры double+int, мерять время, дампить и анализировать данные.

I>>Ну чиркай себе на бумаге. У меня обычно с собой блокнот есть для такого, и карандаш и нож для заточки карандаша
E>Ну на распечатке можно писать камменты к коду, а не просто камменты к бумажке...

I>>Код это всегда и везде зависимости, которые нужно отрабатывать.
E>Ну покажи это на моих примерах. Я же давно у тебя мастер-класс прошу...

Ближайшие две недели у меня очень много работы.

I>>А это значит, что даже если у тебя есть 300 проблемных строк, то у них гарантировано будут зависимости от других модулей.
E>Нифига это не так. Это только в задачах типа "GUI-клей между разными моторами" так всегда. А если у тебя какой-то нетривильный алгоритм реализован, то пофигу зависимости обычно.

Такого практически не бывает.

I>>Если же зависимостей не будет или количество будет некритичным, то задача сводится к функции и решается через тестирование.
E>Ну покажи как оно решается-то?

Примерно так — assert(f(x) == 5);



I>>И вот как тебе распечатка кода поможет искать зависимости — ума не приложу.
E>Никак. Она нужна для другого. Для статического анализа алгоритма, представленного в виде распечатанного кода. Например, для доказательства его правильности, либо выявления условий, при которых правильность таки можно гарантировать...

Я вот не пому, для чего тебе код для доказательства правильности алгоритма ?

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

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

I>>Рисуешь как тебе удобно. Я бы из блокнота отсканировал, но нет у меня сканера под рукой. Иногда удобно вместо рисования таблички заполнть. Иногда даже псевдокод писать.

E>Что за таблички?

поток или последовательность данных

E>В любом случае не ясно, как ты обеспечиваешь, что твои рисунки соответствуют анализируемому коду?

Код при наличии тестов вещь очень эфемерная. БОлее того, его может и вообще не быть, что не мешает его анализировать

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

I>Не, ближайшие две недели у меня мозг занят другими делами.
Не проблема! Если мозг пока что недоступен, можешь мощно выступить на новогодних каникулах, например


E>>Разве речь о панацеи? Я предложил задачку, в которой, по моему мнению, будут полезны распечатки. Ты, можешь показать, как сделать лучше и без бумажек...

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

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

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

I>>И на чем его писать, на листочке бумаги и выполнять на рулоне бумаги ?

Pzz>Как на чем? На Си

Pzz>Никто ж не утверждает, что бумажка и ручка — единственный полезный инструмент.

За отсутствием компьютера надо писать эмулятор на Си ? Правильно я тебя понял ?

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

Pzz>>Никто ж не утверждает, что бумажка и ручка — единственный полезный инструмент.

I>За отсутствием компьютера надо писать эмулятор на Си ? Правильно я тебя понял ?

Не понял, а компьютер куда делся? Вы там на бухгалтерских счетах, что ли, программировали?