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

E>>Это очень сильное утверждение, его не плохо бы доказать...
I>Это никакое не сильное, это скучная банальность.
Значит, наверное, доказать это утверждение тебе будет не трудно.
Итак, где док-во?

I>дальше можно попробовать сортировать структуры double+int, мерять время, дампить и анализировать данные.
Зачем всё это?
1) Лучше измерять не время, а число вызовов функции сравнения.
2) Положим мы уже знаем последовательность чисел, которая приводит к взрыву.
ЧТО ДЕЛАЕМ ДАЛЬШЕ?

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

E>>А если у тебя какой-то нетривильный алгоритм реализован, то пофигу зависимости обычно.
I>Такого практически не бывает.
В смысле? Ты не веришь что в ПО есть куча нетривильных алгоритмов?
Вообще-то у кого как

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

I>
А если провалился, потому, что (f(x) == 6, то что делаем дальше?
I>>>И вот как тебе распечатка кода поможет искать зависимости — ума не приложу.
E>>Никак. Она нужна для другого. Для статического анализа алгоритма, представленного в виде распечатанного кода. Например, для доказательства его правильности, либо выявления условий, при которых правильность таки можно гарантировать...

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

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

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

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

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

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

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

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


E>>Что за таблички?
I>поток или последовательность данных
Не проще ли их распечатать?


E>>В любом случае не ясно, как ты обеспечиваешь, что твои рисунки соответствуют анализируемому коду?
I>Код при наличии тестов вещь очень эфемерная. БОлее того, его может и вообще не быть, что не мешает его анализировать

Не понимаю. Вот у тебя ошибка в коде, или где?

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

I>Для Qsort не нужен анализ алгоритма, берешь гуглишь очередную реализацию и выясняешь, где проблема, с данными или твоей мега-фичей.
Не понял, что гуглишь? Вот у тебя есть массив из 10 000 чисел и какая-то реализация QSort, как ты понимаешь, QSort, это на самом деле целое семейство алгоритмов. И что же нам погуглить, чтобы гарантировать пользователя от зависания нашего ПО?

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

I>Я вот не пому, для чего тебе код для доказательства правильности алгоритма ?
Ну потому, что это формальное представление алгоритма, с которым можно формально работать. Формально -- это значит путём формальных выкладок. Например, его можно преобразовать в какую-то более удобную форму, если надо. Или снабдить каким-нибудь предикатами, вычислить какие-нибудь пред и пост условия на что-нибудь в тех или иных точках и т. д...

I>Для доказательства правильности нужна запись алгоритма в виде всяких форумул.
Этого я совсем не понимаю. Запиши, пожалуйста, "в виде всяких форумул" алгоритм сортировки пузырьком, например.

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

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

О! Аврал в конце года? Видимо управление разработкой не на высоте?

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

Pzz>>>Интересно, если автоматические инструменты есть для всего, зачем человек-то при них нужен?

AV>>Ну как же, а кто будет нажимать кнопку мыши чтобы автоматические инструменты начали работать?

Pzz>Автоматический нажиматель на кнопку мыши?

А кто нажмет на кнопку мыши для запуска автоматического нажимателя?

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

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

E>О! Аврал в конце года? Видимо управление разработкой не на высоте?

Авраала нет, просто у меня задания по той области с которой я вообще не работал до этого.

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

E>>>Что за таблички?
I>>поток или последовательность данных
E>Не проще ли их распечатать?

Если есть чего печатать и это не пачка бумаги, то можно распечатать.

E>>>В любом случае не ясно, как ты обеспечиваешь, что твои рисунки соответствуют анализируемому коду?
I>>Код при наличии тестов вещь очень эфемерная. БОлее того, его может и вообще не быть, что не мешает его анализировать

E>Не понимаю. Вот у тебя ошибка в коде, или где?

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

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

I>>Для Qsort не нужен анализ алгоритма, берешь гуглишь очередную реализацию и выясняешь, где проблема, с данными или твоей мега-фичей.
E>Не понял, что гуглишь? Вот у тебя есть массив из 10 000 чисел и какая-то реализация QSort, как ты понимаешь, QSort, это на самом деле целое семейство алгоритмов.

Сначала был Qsort, щас уже конкретная модификация, чуть позже у тебя появятся еще какие то уточнения в условии

Гуглишь сначала по своей модификации, ищешь реализацию. Нет своей — ищешь подходящую. Проверяешь, сравниваешь результаты.

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

На это уйдет от силы час.

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

То есть, проанализировать код и найти ошибку.

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

E>>>Это очень сильное утверждение, его не плохо бы доказать...
I>>Это никакое не сильное, это скучная банальность.
E>Значит, наверное, доказать это утверждение тебе будет не трудно.
E>Итак, где док-во?

доказательство находится в определении понятия зависимость.

I>>дальше можно попробовать сортировать структуры double+int, мерять время, дампить и анализировать данные.
E>Зачем всё это?

Потому что это очень просто и эффективно

E>1) Лучше измерять не время, а число вызовов функции сравнения.
E>2) Положим мы уже знаем последовательность чисел, которая приводит к взрыву.

Опаньки, снова изменение условия задачи.

E>ЧТО ДЕЛАЕМ ДАЛЬШЕ?

Дальше см. другое сообщение. Но ты понмаешь, что изменил условие по ходу задачи ?

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

Мне трудно чего то объяснять тебе, особенно когда ты меняешь условие на ходу да вдобавок сам рассказываешь про полуавтоматические средства.

I>>Такого практически не бывает.
E>В смысле? Ты не веришь что в ПО есть куча нетривильных алгоритмов?

И что с того ?

E>А если провалился, потому, что (f(x) == 6, то что делаем дальше?

Анализируешь код и исправляешь. Не помогло — анализируешь дальше и так до победы. По ходу анализа у тебя обязательно появятся новые тесты.

Естественно, тесты не должны вносить доп. сложность.

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

I>>Я вот не пому, для чего тебе код для доказательства правильности алгоритма ?
E>Ну потому, что это формальное представление алгоритма, с которым можно формально работать. Формально -- это значит путём формальных выкладок. Например, его можно преобразовать в какую-то более удобную форму, если надо. Или снабдить каким-нибудь предикатами, вычислить какие-нибудь пред и пост условия на что-нибудь в тех или иных точках и т. д...

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

Предикаты, пред и пост условия отлично вставляются в редакторе кода.

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

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

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

Я ж сказал — компьютер один на троих-четверых.

Эмулятор писать дело достаточно трудоёмкое. Многие крупные конторы до сих пор не могут родить толковый эмулятор для своих разработок.

Одно дело — эмулятор процессора, и совсем другое — эмулятор для компонента который по сложности как компьютер, при компонент этот в стадии разработки.

На то время, это было более 10 лет назад, подобные эмуляторы были только как внутренний софт у контор вроде Intel.

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

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

Да нет здесь ничего особенного что бы отправлять в философию

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

E>>Один и простых примеров такого сценария -- это мы курим бумажку и понимаем какие инварианты каких циклов хорошо бы проверить. И если они ещё не проверяются в коде, то расставляем asserts и делаем прогон...

Pzz>Я бы перед тем, как писать такой текст, сначала спросил бы Ikemefula, знает ли он, что такое инварианты циклов

У Егора задача простая — доказать, что для вычисления инвариантов цикла обязательно нужна бумажка с распечатаным на ней кодом.

Доказать он это не может, пример привести — тоже не может.

По этой причине он пытается хитрить — предлагает мне доказать что бумажка с кодом не нужна

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

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

"инвариант цикла"

Скажи честно, для чего по твоему используется юнит-тестирование ?

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

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

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

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

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

I>Я ж сказал — компьютер один на троих-четверых.

Я так понял по твоему изначальному рассказу, что там target один на троих-четверых, а не host.

У вас что, писюков в достаточном количестве не было? Круто.

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

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

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

I>На то время, это было более 10 лет назад, подобные эмуляторы были только как внутренний софт у контор вроде Intel.

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

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

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

Я согласен с Егором. Вообще, на бумажке думать можно, на компьютере — нет. Его электромагнитное излучение парализует мозги

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

I>Скажи честно, для чего по твоему используется юнит-тестирование ?

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