Здравствуйте, Sclown, Вы писали:
S>Как вам кажеться, что лучше поясняет алгоритм — блок схема или алгоритм?
Я имел ввиду — блок схема или исходный код на некотором языке....
Здравствуйте, SergH, Вы писали:
S>>И вообще строите лы вы блок-схемы своих алгоритмов?
SH>Редко.
Если не секрет, то в каких?
Я обратил внимание, что строю блок-схемы, только если заставляют. А так страюсь пояснять все в диаграммах типа UML...
Стало интересно — как делают остальные...
Здравствуйте, Sclown, Вы писали:
S>Если не секрет, то в каких?
Для себя — когда сам не до конца понимаю, что же оно делает и как
Для документации — если нужно более-менее подробно пояснить алгоритм функции, не сводящийся к последовательности действий, а содержащий ветвления и циклы.
S>Я обратил внимание, что строю блок-схемы, только если заставляют. А так страюсь пояснять все в диаграммах типа UML...
Есть такая диаграмма — activity. Может я её не совсем верно использую, но очень похожа на блок схему
Здравствуйте, Sclown, Вы писали:
S>Я имел ввиду — блок схема или исходный код на некотором языке....
Блок схема обычно более абстрактна, она не содержит всяких лишних подробностей. Из неё обычно выкинуты непринципиальные в данном рассмотрении части функции (обработка ошибок, запись в лог, просто куски кода). Это позволяет понять, что функция делает и немного — как (куда и когда передаётся управление). Если нужны подробности, всё равно придётся смотреть код, но уже заранее зная, что он делает, понять его будет легче.
Здравствуйте, Sclown, Вы писали:
S>Здравствуйте, Sclown, Вы писали:
S>>Как вам кажеться, что лучше поясняет алгоритм — блок схема или алгоритм? S>Я имел ввиду — блок схема или исходный код на некотором языке....
По моему лучше всего алогритм записанный на псевдокоде.
Схемы тоже часто полезны, но не блок-схемы, а скорее иллюстрации некторых моментов или
процессов в сложном алгоритме.
Здравствуйте, Sclown, Вы писали:
S>И вообще строите лы вы блок-схемы своих алгоритмов?
"Блок-схема алгоритма" — это пережиток Фортрана/Ассембрера, поскольку напрямую отражает control flow и условные переходы в программе. Очень просто взять блок-схему и напрямую закодировать ее с помощью goto. Но попробуй приведи ее к структурному виду даже времен Алгола — читай — к структурным блокам. Фактически, у нас не останется ромбиков с переходами, а будут только прямоугольники, следующие один за другим. А закодировать алгоритм по традиционной блок-схеме (с переходами и control flow) сейчас — это примерно то же, что и переписать программу с Фортрана-4 на Си, исключив при этом все goto, то есть выделив циклы и блоки с условиями.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, Sclown, Вы писали:
S>Как вам кажеться, что лучше поясняет алгоритм — блок схема или алгоритм? S>И вообще строите лы вы блок-схемы своих алгоритмов?
Я не строю алгоритмы, для которых нужны блок-схемы.
Я строю такие алгоритмы, чтобы нужны были диаграмы UML.
Здравствуйте, McSeem2, Вы писали:
MS>"Блок-схема алгоритма" — это пережиток Фортрана/Ассембрера, поскольку напрямую отражает control flow и условные переходы в программе. Очень просто взять блок-схему и напрямую закодировать ее с помощью goto. Но попробуй приведи ее к структурному виду даже времен Алгола — читай — к структурным блокам. Фактически, у нас не останется ромбиков с переходами, а будут только прямоугольники, следующие один за другим. А закодировать алгоритм по традиционной блок-схеме (с переходами и control flow) сейчас — это примерно то же, что и переписать программу с Фортрана-4 на Си, исключив при этом все goto, то есть выделив циклы и блоки с условиями.
Мне вспоминается, как один препод заставял все "вызовы вспомогательных алгоритмов" записывать в специальном блоке. Я возражал. Ведь "вспомогательный алгоритм" — это то же самое вычисление, и записывать обращение к нему нужно в обычном вычислительном блоке. Тогда я предлагал и обращения к "вспомогательному алгоритму" '+' так же записывать в специальном блоке. Препод отвечал, что, мол, арифмитические, логические операции и операция присваивания — элементарные операции, потому их нужно записывать в арифметическом блоке, а, скажем, сортировка — сложная операция, которая требует вызова вспомогательного алгоритма. Сразу видно фортрановское мышление . Лично мне стало ясно, что препод ни Ады, ни C++, ни Лиспа (и ещё кучи хороших языков) в глаза не видел.
По-моему, тот факт, что до сих пор в некоторых вузах информатика преподаётся через блок-схемы — величайший позор российского образования. ИМХО, очень правильный подход в MIT'овском учебнике по лиспу (это который "Structure and Interpretation of Computer Programs") — сначало даётся введение в программирование без побочных эффектов, в абстракцию на уровне процедур и данных, и только потом изучают императивное программирование. Только убедительная просьба не разводить флейм по этому поводу — есть "ФП", "Философия" и "Религиозные Войны".
K>По-моему, тот факт, что до сих пор в некоторых вузах информатика преподаётся через блок-схемы — величайший позор российского образования.
Это да. Помнится, делал я лабы по сям... Сами лабы заняли полчаса. А вот блок-схемы к
ним я делал весь день! У меня опосля этого вся левая половина лица дёргалась в
нервном тике.
Здравствуйте, Sclown, Вы писали:
S>Как вам кажеться, что лучше поясняет алгоритм — блок схема или алгоритм? S>И вообще строите лы вы блок-схемы своих алгоритмов?
Иногда, разбираясь в своём коде несколькомесячной давности, я рисую схемы. Но это не блок-схемы (которые показывают, где и куда передаётся управление), а скорее схемы зависимости данных.
Я рисую большой прямоугольник для всей функции и вверху у него маленькие точечки/кружочки по числу входных параметров. Подписываю их. Затем на каждую операцию рисую овальчик с подписью, какая функция здесь вызывается, провожу линии от входных переменных к операции, и от операции к выходным переменным. (Если результат одной операции непосредственно используется как аргумент другой операции, то соответственно дуга идёт от первой операции ко второй.) В конце концов все результаты функции (возвращаемое значение и значения выходных параметров) оказываются на нижнем краю прямоугольника функции (или блока кода).
На такой схеме хорошо видно, какие данные для чего считаются, и какие данные раньше были нужны, а теперь уже не очень. Иногда по ней можно понять, что некий блок внутри функции хочет выехать из неё и стать отдельной функцией, и какие у неё будут входы и выходы.
Сложности возникают с условными операторами и циклами. До них лучше не спускаться, а считать их некими макроблоками с определённой семантикой. (Это, в частности, заставляет задуматься, а не заменить ли этот for на вызов алгоритма max_element, или на accumulate, или на transform).
Впрочем, это всё помогает постольку, поскольку анализируемый код близок к функциональному — с минимумом побочных эффектов и недетерминизма и выполняет некие расчёты. Если же код ближе к объектно-ориентированному, то больше помогают UML’ные диаграммы классов/объектов и диаграммы следования (sequence diagrams).
Здравствуйте, Centaur, Вы писали:
C>Я рисую большой прямоугольник для всей функции и вверху у него маленькие точечки/кружочки по числу входных параметров. Подписываю их. Затем на каждую операцию рисую овальчик с подписью, какая функция здесь вызывается, провожу линии от входных переменных к операции, и от операции к выходным переменным. (Если результат одной операции непосредственно используется как аргумент другой операции, то соответственно дуга идёт от первой операции ко второй.) В конце концов все результаты функции (возвращаемое значение и значения выходных параметров) оказываются на нижнем краю прямоугольника функции (или блока кода).
Если не читал А.П.Ершова "Введение в теоретическое программирование", то очень рекомендую порыться в библиотеке. Там и про циклы и про IF в применении к твоим диаграммам написано, и при этом весьма понятным языком.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sclown, Вы писали:
S>Как вам кажеться, что лучше поясняет алгоритм — блок схема или алгоритм? S>И вообще строите лы вы блок-схемы своих алгоритмов?
Не знаю, нужны ли они, но расскажу, как мне довелось с ними работать
Заказчик прислал описание алгоритма, примерно 10 страниц и блок-схему его же, примерно 20 страниц. Я сначала блок-схемы проигнорировал и начал программировать по описанию. Когда в описании я нашел некорректности (задача была очень плохо формализуема), то я ему об этом написал и мы согласовали изменения. После этого я получил от него измененную блок-схему. Тут до меня дошло, что если код я напишу не по блок-схеме, а просто как мне захочется, базируясь на описании, то это не пойдет. Пришлось вникать в эту блок-схему и писать строго по ней.
Некорректностей я нашел штук 20 (тут нет никакой вины разработчиков алгоритма, невозможно было все предусмотреть все случаи, оставлось только пробовать и смотреть, что получается), и каждый раз мне аккуратно присылали новую блок-схему и я аккуратно проверял, соответствует ли она моему коду или нет...
Я их и до этого не любил, а после этого просто возненавидел
Здравствуйте, konsoletyper, Вы писали:
K>Мне вспоминается, как один препод заставял все "вызовы вспомогательных алгоритмов" записывать в специальном блоке. Я возражал. Ведь "вспомогательный алгоритм" — это то же самое вычисление, и записывать обращение к нему нужно в обычном вычислительном блоке. Тогда я предлагал и обращения к "вспомогательному алгоритму" '+' так же записывать в специальном блоке. Препод отвечал, что, мол, арифмитические, логические операции и операция присваивания — элементарные операции, потому их нужно записывать в арифметическом блоке, а, скажем, сортировка — сложная операция, которая требует вызова вспомогательного алгоритма. Сразу видно фортрановское мышление . Лично мне стало ясно, что препод ни Ады, ни C++, ни Лиспа (и ещё кучи хороших языков) в глаза не видел.
Не собираясь защищать преподавателя, заставляющего студентов писать блок-схемы (лично я их противник), все же хочу отметить, что концепция вызова вспомогательного алгоритма как в Фортране, так и в С/C++ ничем не отличаются. Подпрограмма — она и есть подпрограмма, хоть в Фортране, хоть в Паскале, хоть в С++. Так что фортрановское мышление здесь ни при чем, и делать на основании этого вывод, видел он другие язвыки или нет, не стоит.
Здравствуйте, azzx, Вы писали:
K>>По-моему, тот факт, что до сих пор в некоторых вузах информатика преподаётся через блок-схемы — величайший позор российского образования.
A>Это да. Помнится, делал я лабы по сям... Сами лабы заняли полчаса. А вот блок-схемы к A>ним я делал весь день! У меня опосля этого вся левая половина лица дёргалась в A>нервном тике.
А я помню договорился с аспирантом — и не делал. А потом поссорился с лектором и он аннулировал последнюю лабу без блок-схем (правда потом он мне всё равно автоматом поставил).
Здравствуйте, Sclown, Вы писали:
S>Как вам кажеться, что лучше поясняет алгоритм — блок схема или алгоритм? S>И вообще строите лы вы блок-схемы своих алгоритмов?
Единственное примерение блок-схем я вижу в документациях по аппаратуре: когда нужно сказать как общаться с устройством (при этом реализация на ассемблере) блок-схемы очень помогают (именно как документация). И псевдокод тут им уступает, я бы сказал.
А вообще блок-схемы — фигня полная
konsoletyper wrote:
> Мне вспоминается, как один препод заставял все "вызовы вспомогательных > алгоритмов" записывать в специальном блоке. Я возражал. Ведь > "вспомогательный алгоритм" — это то же самое вычисление, и записывать > обращение к нему нужно в обычном вычислительном блоке. Тогда я предлагал > и обращения к "вспомогательному алгоритму" '+' так же записывать в > специальном блоке. Препод отвечал, что, мол, арифмитические, логические > операции и операция присваивания — элементарные операции, потому их > нужно записывать в арифметическом блоке, а, скажем, сортировка — сложная > операция, которая требует вызова вспомогательного алгоритма. Сразу видно > фортрановское мышление . Лично мне стало ясно, что препод ни Ады, ни
Да вряд ли. Имеется в виду, наверное, вычислительная сложность. А в большинстве языков арифметич., логич. операции
обычно выполняются константное время, вне зависимости от операндов, а вот сортировка — зависит от количества сортируемых
элементов. В общем, если по блок-схеме рассчитывать сложность алгоритма, то чёткое разделение на элементарные/сложные
операции имеет большое значение.
Posted via RSDN NNTP Server 2.0
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Смотря в каком виде представлен "алгоритм" из конца предложения 
У меня опосля этого вся левая половина лица дёргалась в
1.1.4 stable rev. 510
