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

I>Ты до сих пор не дал нормального примера

Уже два дал.
1) Взрыв QSort
2) Сжатие по двум осям RLE картинки

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

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

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

I>Конечно не решаются. При этом от бумаги с кодом толку еще меньше будет,
Почему это, обязательно с кодом? С материалами по задаче. Если задача про код, то с кодом, а если про что-то другое, с этим самым другим...

I>потому что для таких дел есть специальные инструменты.
Какие? Не поделишься?

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

I>>И заметь — про это уже было сказано.

E>А мне вот бумажка с распечаткой помогает как раз. Возможно именно потому, что это ФОРМАЛЬНОЕ представление алгоритма, и я УМЕЮ с ним работать на бумажке. Тоже формально.

Есть такие люди, которые без бумаги жить не могут

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

VV>Очень сомневаюсь, что он может выдать что-то сакральное. Если бы такое знание было — он бы его выдал уже давно. Хотя я буду рад ошибиться.

Я сторонник корректного конструктивного обсуждения проблем.

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

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

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

E>Я сторонник корректного конструктивного обсуждения проблем.

Имхо вы давно сошли на обсуждение личных предпочтений. А на вкус и цвет...

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

I>>Начинать анализ системы
E>IMHO, в таких условиях НАЧИНАТЬ анализ как-то поздновато. Я, например, в аналогичных обстоятельствах обычно знаю несколько мест, которые надо срочно пристально курить.

А это по твоему не анализ, да ?

I>> Для анализа кода лучше брать не бумагу, а Code Collaborator например, ибо известно — две головы лучше одной.
E>Кому как. Это всего лишь вопрос, как организовать коллективную работу. Почему ты считаешь что именно Code Collaborator лучше всего? Я бы, например, быстренько бы обсудил с теми, кто в теме, что надо проанализировать, а потом раздал бы куски для анализа по людям...

По бумажке каждому, да ? Code Collaborator нужен если две части тимы в разных странах сидят например.

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

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

Т.е. бумажка уже не является необходимым условием Ты сам то понял, что сказал ?

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

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

VV>Имхо вы давно сошли на обсуждение личных предпочтений. А на вкус и цвет...

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

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

VV>>>А как у Вас с соблюдением режима? Вы сегодня зарядку делали?
I>>Думаешь это как то коррелирует с твоими мыслями ?

VV>Вам кажется, что Вы можете читать мои мысли?

А про чтение ничего и не было

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

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

I>>Тесты если уметь ими пользоваться, получаются очень простыми.
E>Ну покажи на модельной задаче, как надо делать. AFAIK, тесты получаются простыми, только в задачах с простой спецификацией.

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

E>>>И вот на каком-то изображении получаем, что некоторые пикселы результата не того цвета. И что мы делаем дальше?
I>>Очевидно, юнит-тесты написаны коряво. Нужно фиксить юнит-тесты, они должны основываться на реальных данных.
E>Это я не понял. Что такое "реальные данные" для библиотеки обработки изображений?

Изображения из тех которые надо обрабатывать.

I>>Из деклараций функций мне например ничего не ясно.
E>Упс, я ошибся. Правильно, конечно же так:

void HrzCompressTwiceKeepBlackStrokes( ImageStroke*& dst, ImageStroke const* &src, int linesCount = 1)

Мы берём в src ссылку на указатель на строки. Вычитываем оттуда linesCount строк, и помещаем в параметр указатель за эти строки.
E>А в dst записывае результат, и сам dst передвигаем за результат.

Думаешь это перестало быть декларацией ?

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

Что значит сложные, в алгоритме ? Так здесь вообще код не помощник. Юнит-тесты строятся когда алгоритм известен.

E>Вот ты написал, что надо разбить сложную функцию на простые и всё починится.

Не починится. Нужно что бы каждая функция тестировалась.

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

E>Попробуй объяснить на примере этой задачи твою методу?

Какой этой задачи ? Я пока что не видел задачи, только кусочки деклараций.

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

E>Уже два дал.
E>1) Взрыв QSort
E>2) Сжатие по двум осям RLE картинки

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

Был ще пример у AV, он тоже дошел до логирования и привлечения тестеров

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

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

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

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

Ты сам все сделал, когда рассказал про необходимость полуавтоматических инструментов

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

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

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

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

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

Может конкурентов не шибко много ? Я ж не в курсе деталей.

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

Некаменный это компьютер. Я ж говорил — бумага это только симптом, когда нужен повод отдохнуть

I>>Конечно не решаются. При этом от бумаги с кодом толку еще меньше будет,
E>Почему это, обязательно с кодом? С материалами по задаче. Если задача про код, то с кодом, а если про что-то другое, с этим самым другим...

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

I>>потому что для таких дел есть специальные инструменты.
E>Какие? Не поделишься?

Средтсва моделирования, вычисления, визуализации и тд

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

I>>>Думаешь это как то коррелирует с твоими мыслями ?
VV>>Вам кажется, что Вы можете читать мои мысли?
I>А про чтение ничего и не было

То есть Вы признаете, что не можете их читать?

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

E>>IMHO, в таких условиях НАЧИНАТЬ анализ как-то поздновато. Я, например, в аналогичных обстоятельствах обычно знаю несколько мест, которые надо срочно пристально курить.
I>А это по твоему не анализ, да ?
По моему это не соответсвует термину "НАЧИНАТЬ"...

I>По бумажке каждому, да ? Code Collaborator нужен если две части тимы в разных странах сидят например.
По вопросу/куску кода каждому. Способ коммуникации -- это один вопрос, а инструмент для анализа -- другой.

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

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

I>Прямо как в анекдоте — газетку подстели, что бы выше быть. Вобщем? предлагаю завершить ?
Ну если тебе больше нечего по существу сказать, то да, наверное.

А так я всё ещё жду мастер-класса..
Можно в отдельной ветке, например. И в другом форуме.
Только тут ссылку дай, пожалуйста.

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

I>Я пока еще задачу то не видел. Или ты хочешь, что бы я написал и алгоритм, и тесты и конвертеры ?
Ну это же модельная задача? Довольно простая.
Я так тебя понял что можно распилить одну сложную функцию на много простых и тогда тесты смогут ГАРАНТИРОВАТЬ правильность кода.
Вот и покажи как распилить. Если тебе трудно написать функцию, которую надо пилить, то я сам могу её написать. Просто я не думаю, что это сложно как-то очень, и, насколько я тебя понял, код самой монолитной функции не нужен, так как ты всё равно предлагаешь её переписать.

E>>Это я не понял. Что такое "реальные данные" для библиотеки обработки изображений?
I>Изображения из тех которые надо обрабатывать.
Ну ты понимаешь, что такое "библиотека"? Нужно уметь обрабатывать ЛЮБЫЕ картинки. Ну я бы, например, выбрал несколько штриховок и случайных заполнений, картинки какие-нибудь, буквы из растризованных шрифтов, тексты, ну скриншоты можно попробовать...

I>Думаешь это перестало быть декларацией ?
Это вообще не надо реализовывать. Это, как раз, просто. Нужно реализовать функцию, которая сжимает вдвое по обеим осям!

I>Что значит сложные, в алгоритме ? Так здесь вообще код не помощник. Юнит-тесты строятся когда алгоритм известен.
Ну в общем случае ты не знаешь где у тебя ошибка в алгоритме или в реализации. Надо гарантировать работоспособность ПО, то есть выявить ошибки и там и там.

I>Не починится. Нужно что бы каждая функция тестировалась.
Ну это понятно. Но проблема не в этом.

I>Какой этой задачи ? Я пока что не видел задачи, только кусочки деклараций.

Ну что тебе не понятно? Представление картинки понятно? Если нет, то задавай вопросы.

Если представление понятно, то задача сформулирована формально. Пишем функцию, которой на вход даём картинку 2N x 2M, а на выходе хотим картинку N x M. При этом исходную картинку разбиваем на клетки 2х2 пиксела и вместо каждой клетки в результат пишем тот цвет, которых в клетки больше.
Если в клетке чёрных и белых по 2, то можешь сам выбрать, что делаем в этом случае.
Варианты:
1) Пишем чёрное
2) Выбираем такой цвет, чтобы в результате было как можно меньше смен чёрного белым
3) Выбираем такой цвет, чтобы в результате былоо как можно меньше поверхностного шума
4) Выбираем цвет в соответствии с каким-то паттерном заполнения. Например так, чтобы из "шахматной доски" в результате тоже получилась "шахматная доска"

В этой постановке задачи что-то не понятно?

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

I>В одном тебе пояснил CreatorCray,
Чего?
Что-то он мне ничего не пояснил.

I>в другом ты сам признался что необходимы полуавтоматические средства для того, что бы бумажка заработала.
Зачем? Я вроде как формально описал постановку задачи без автоматических и полуавтоматических средств. IMHO и для её решения они не нужны. Во всяком случае МНЕ...
Но я так понял, что ты владеешь каким-то методами, которыми я не владею. Ну так покажи же наконец всю мощь своего кунг-фу?


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

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

Ну и этот случай тоже. И что?

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

I>Ты сам все сделал, когда рассказал про необходимость полуавтоматических инструментов

Это РАЗНЫЕ этапы. Предварительная локализация баги -- полуавтоматические инструменты, логи и т. д.
Поиск и исправление сложного бага в предварительно локализованном куске -- бумажка...

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

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

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

Те, кому интересно, могут пойти работать в какую-нибыдь подходящую организацию. Например в "Алмаз-Антей", или как оно там зовётся?
Но интересны и более открытые варианты...