DRAKON.SU

1. Тогда давайте четко скажем: алгоритм - для человека, программа - не для человека.
Ибо только человек может ЧИТАТЬ с осмыслением.
То есть мы разделяем не классы эквивалентных программ, а классы исполнителей.

2. Говоря о переводе, мы соглашаемся с мнением Майерса - "Надежность ПО".
Там о возникновении ошибок именно так и сказано: ошибки перевода.
И я с ним согласен. Ибо мы разделили исполнителей, теперь нужно перевести алгоритм (мы же говорим об алгоритме, а не о совокупности алгоритмов - системе) с языка читателя на язык исполнителя.
Этот процесс мы и называем разработкой. А фактически это перевод в систему команд другого исполнителя.
Никакого нового знания тут не возникает (мы же говорим об известном алгоритме).
За исключением тех самых недокументированных возможностей исполнителя, которые неизвестны переводчику...

Система алгоритмов понимается в смысле сети работ?..
Видимо, придётся восстановить примеры (были в теме про Гостинец) где-то на территории, свободной от спецпропаганды...

Ещё раз. Человек-Читатель-Разработчик в общем случае НЕ ЯВЛЯЕТСЯ исполнителем.
Создателем - да, является. Исполнителем - может быть, но не обязан.

Вы говорите об известном алгоритме (потому что у Вас учебные задачи перед глазами)
А я не говорю об известном алгоритме.
Я говорю исключительно о разработке нового алгоритма.
Вернее, я говорю о процессе поиска решения задачи, в котором МОЖЕТ ВОЗНИКНУТЬ подзадача разработки алгоритма (вплоть до его физической реализации для конкретного исполнителя).

При этом с "переводом" всегда возникает неоднозначность.
Можно вернуться к изначальному моему примеру и снова это увидеть.
Так, разработчик пишет абстрактный алгоритм, в котором есть пункт "скопировать массив памяти". И для понимания смысла задачи, для технического задания - этого вполне достаточно.
Затем возникает подзадача реализации (предполагаем, что конкретный исполнитель уже выбран).
И здесь, в зависимости от выбранного исполнителя, эта задача может быть сведена к одноранговой операции перевода (вызову системной функции, например).
А может и потребовать углубления по уровню - то есть необходимость новой разработки в рамках решения подзадачи (где сначала требуется разработать новый, неизвестный алгоритм поэлементного копирования, а затем уже озаботиться его переводом на язык исполнителя).

Вот как раз в условиях подобной неоднозначности определение Ткачёва об эквивалентности теряет всякий смысл.
Оно, конечно, хорошо выделить эквивалентную абстракцию для ряда исполнителей... Да только ряд этот оказывается настолько разнообразен, что практически значимой эквивалентности никак не получается.
И, подозреваю, что эта проблема отнюдь не из разряда "построение абстракций" vs. "чего тут думать, прыгать надо", а носит принципиальный характер.

А создатель не должен анализировать работу исполнителя по алгоритму? И/или формально определять алгоритм для формализованной же им модели исполнителя?..

А так - да, согласен с разделением целеполагателей для системы-решателя задачи...

Да полно Вам.
Вон, сколько тут на форуме многостраничных тем, в которых в элементарных задачах умудряются делать (и находить) серьёзные алгоритмические ошибки!

То есть, как говорится, "должен, но не обязан"!

И, наконец, есть ещё элемент интуитивного искусства. Как, к примеру, гроссмейстер не обязательно просчитывает все варианты (особенно при блиц-игре), а использует трудноформализуемую интегральную оценку позиции...
Также и здесь - очень многие "создатели", в полном соответствии с теорией умотипов Ткачёва, на самом деле занимаются комбинированием ранее усвоенных паттернов в надежде на авось. А потом, после ряда набитых шишек, уже при тщательном исполнении сотворённого совершают массу открытий!

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

Да, и о подзадаче и трудностях перевода. Это можно понимать так, как описано здесь: viewtopic.php?p=75076#p75076 ?.. Т.е. что задача разработки алгоритмов встаёт обычно в рамках задачи разработки модели деятельности, сводимой (возможно, приближённо) к системе алгоритмов?.. А насчёт интуитивного решения проблемы перевода - так, как у Фридланда там цитируется?

Само собой.

Слишком много слов... Я не имею желания досконально разбираться по ссылкам... Просто отмечу, что "сводимость к системе алгоритмов" вообще ни при чём, это левый какой-то критерий, из пальца высосанный.
Просто если есть в какой-то задаче требуемый порядок действий, логично озаботиться его формализацией (в виде алгоритма). Вот и всё. Ничего сверх того.

Ох, достал, достал. Ну не читал я никакого Фридланда, и необходимости в том не вижу.

Подозреваю, это общая беда "околонаучного стиля мышления": Википедия требует ссылки на АИ, научные издания требуют ссылки, ВАК требует ссылки... А умение думать почему-то никто не требует. Видимо, потому что это не так-то просто Вот и делегируют такую оценку сторонним авторитетам, по ссылкам их перечисляя... Так можно далеко уйти.

Не, просто если я буду всё это дублировать - как бы флуд не получился...

А если в виде одного алгоритма не получается - тогда как?..
А сводимость - это не критерий, а необходимость... если надо достичь строгости программы... Вот как раз Фридланд и считает, что критерия такого общего нет - делаем и смотрим... С чем согласен в силу своего самостоятельного мышления...

Кстати, насчёт ссылок - правда Ваша... причём если Википедия ещё пытается требовать, чтобы, применив алгоритм прохода по ссылкам, можно было получить целостную картину, насколько каждый автор мыслил самостоятельно , то издания (в т.ч. рецензируемые) видимо, не всегда...

Вообще спор на тему "идентичен ли алгоритм программе или нет ?" с точки зрения ЕСПД
(источник немного устаревший, но все еще достаточно авторитетный) смысла не имеет - там
это разные вещи:

Мне это всё действо что-то напоминает до боли. Ах, да!. Джонатан Свифт! Остроконечники и тупоконечники.

Если посмотреть на предмет спора, то надо ответить на два вопроса:

1. Кто ставит проблему?
2. Кто решает проблему?

Ответ один - человек. А что собой представляет проблема? Это намерения и контрнамерения. Для того, чтобы решить проблему, необходимо рассчитать усилия (подставьте подходящие синонимы), чтобы преодолеть какие-то контрусилия в достижении намерения (надеюсь, понятно, хотя не совсем точное выражение).

А все ли люди одинаковы? Нет. Это однозначно. У каждого своя сумма знаний, опыта, диапазона усилий, интеллекта и т.д. Человек решает проблему, исходя из имеющихся ресурсов. Хотя бы только это предопределяет множественность решений задач.

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

Есть у нас программист, которому алгоритмы легче писать на С. Он по-другому не умеет. Но это - алгоритм. Его виртуозность просто поражает. Если ему дать блок-схему, то он тут же набросает кусок программы и покажет узкие места или ошибочность через конкретную реализацию.

Вот такие дела...

Т.е. покажет через формальный текст (и, возможно, мысленно установит тоже)?..

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

Дык это тогда к Потопахину тоже...


Да понятно в общем... Вот тут о Востоке говорили... что напоминает о схеме выстраивания сил "мы сами, наши враги и наши союзники"...

Имелось в виду, что лучше, чем "дракон-читатель", такой исполнитель, который не просто может "камерально проверить" решение (программу, инструкцию) с графовой записью потока управления (ну или вообще независимо от того, какая часть её содержания в какой форме записана)?.. Но и сам его строить, что ли?
Тогда он должен рассматривать описание решения как "эвроритм" - т.е. "описание, уточняемое в ходе исполнения человеком за счёт его разумности" в смысле этой работы ?.. И будет проектировать решение по заданным целям и возможностям? Типа как технолог: "А, ты здесь вон как сделал<продукт>! Тогда дальше пойдём вот так<в процессе производства>..." ((C) Грабин)?..

Тогда исполнителю не помешает "творческая база процессов". Организованная, например, по такой модели. Так?

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

-------------------------------------------
На С/С++ (например) пишется программа - для исполнения машиной.
А графическая форма (в данном случает Дракон-схема) - она не для машинного исполнения:
пока ни одна машина прямо по Дракон-схемам не работает (или уже где-то работает?).
Это алгоритм, а не программа.
Он для человека, который может решать разные задачи:
-- для постановки задачи написания (вербального) текста программы:
вручную или автоматической (или полуавтоматической) трансляцией;
-- для разных других задач ..., например, для исполнения будущей программы вручную
(для простых программ);
-- для лучшего понимания алгоритма решаемой задачи !!!
(здесь небольшая порочная тавтология, но это понятно - что бы не вдаваться ...)

Для лучшего понимания, чем по вербальному тексту:
вот это очень важно, исключительно важно (архиважно, как любил говорить Ильич).
В этом отношении указанные две разные формы - это две большие разницы.

--------------------------------------------------------------
И здесь выплывает каверзный вопрос:
а в чем разница между алгоритмом и программой ???

Есть мнение, что программа - это алгоритм.
Можно согласиться, но нужно уточнить:
это машинный алгоритм - в смысле - для исполнения машиной.
Причем для формального исполнения тупым автоматом - без понятия.
Правда на языке высокого уровня решаются задачи понимания программы - но это для человека - с понятием.
А для машины язык высокого уровня не нужен, ей нужна трансляция на низкоуровневый язык
(фактически в машинный код).
То есть программа, как машинный алгоритм - это особый (очень важных) подкласс класса алгоритмов (как предписаний).

----------------------------
Когда создавался язык программирования Алгол (Algol: Algorithm Language) предполагалось,
что он будет использоваться не только для написания программ для ЭВМ,
но также для обсуждения алгоритмов, изучения алгоритмов, обмена алгоритмами и т.п.
И вот это второй слой функций не оправдал ожиданий - это дело не пошло.

Короче говоря, требуются графические языки для представления алгоритмов:
например, визуальный Дракон-язык.
А почему?
А потому, что в двухмерной графической форме можно отобразить в явной форме
все связи операторов по потоку управления (и при желании - по потоку данных).
А в линейном (одномерном) тексте программ эти связи отражаются косвенно:
посредством синтаксических кодировок.
В этом заключается большое преимущество визуального языка (Дракон):
обеспечивает явное понимание структуры алгоритма.
Это особенно актуально для параллельных алгоритмов и параллельного программирования,
особенно для взаимодействующих процессов
со сложными промежуточными взаимосвязями между ними.

------------------------------
Это попутные замечания к начальной фразе уважаемого Rifat-а:
для последующего обсуждения проблемы goto - в этом плане сопоставления двух форм.

Предварительно можно заметить:
в параллельных алгоритмах (и для параллельного программирования)
роль goto возрастает и развивается, особенно для взаимодействующих процессов.
В частности, в той или иной форме существуют параллельные goto.
Например, семафоры Дейкстры.

Вопрос всплывает на форуме с завидным упорством.
Почитайте, что ли, с самого начала: Что же такое алгоритм?

Это потому, что это сложный многоаспектный вопрос (со множествами смыслов).
В разных случаях могут выплывать не поверхность (в осознание) разные аспекты, существенные в разных отношениях.

Такие ссылки на большие темы не очень продуктивные.
Нет возможности долбать (от начала и до конца) 7 страниц дискуссий по разным случайно возникающим поводам.
(Хотя там, конечно, есть ценный материал для систематического анализа).

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

И можно подумать, что там (на Вашей теме) есть ответы на все проблемные аспекты Вашего вопроса "Что же такое алгоритм?".
А мы с Вами участвовали в обсуждении этого вопроса еще где-то на какой-то другой теме:
тоже по каким-то поводам, и, наверно, не сильно повторялись.

Лучше было бы, если бы Вы, уважаемый Алексей, сообщили конкретно:
то ли в моем вышеприведенном посте есть повторы известного, то ли что-то не так.
А так получается просто отметание всего изложенного.
-----------------------------

Есть существенное уточнение утверждения:
Во-первых.
Графически (посредством Дракона) - "нетекстом" представляется алгоритм.
На исходным кодом на С/С++ представляется программа.
Вроде бы это тот же алгоритм, но не совсем тот:
это машинный алгоритм - из машинного подкласса общего класса алгоритмов.
Что-то не меняется, а что-то меняется:
есть определенная (первая) разница.
Или, как говорят в Одессе - это (первые) две большие разницы.

Во-вторых.
Фигурируют разные (знаковые) формы:
программа представлена в текстовой одномерной (линейной) форме,
а алгоритм представлен в графической двухмерной форме.
Опять что-то не меняется, а что-то сильно меняется:
есть большая (вторая) разница.
А именно - по явному или неявному (закодированному) отображению ситемы связей структуры потока управления (и потока данных).
Или, как говорят в Одессе - это (вторые) две большие разницы.

----------------------------------
Итого:
две разницы (или две пары больших разниц).

По первой разнице на Вашей теме в принципе, по-видимому, что-то есть
(хотелось бы получить точные ссылки).
А по второй разнице там ничего нет (мне кажется, или я ошибаюсь?).

===============================================
А для чего начинался весь этот разговор?

1) Эти две разницы имеют существенное отношение к проблеме "goto".

2) Нецелесообразно полностью выметать "goto" из языков - даже в традиционном последовательном программировании и в традиционной последовательной алгоритмизации.

3) А в параллельном программировании и в параллельной алгоритмизации в разной форме представления:
-- активно используются "gоto", особенно для синхронизации взаимодействующих процессов;
-- существуют параллельные (множественные) goto.

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

Если самое короткое резюме - то алгоритм есть программа для абстрактного исполнителя.

Много чего не так.
Например:

Это неверно.
Всё как раз наоборот.
Программа - обобщающий класс.
Алгоритм - частный случай программы. Мало того, что описывающий только её процедурные свойства, так ещё и исполнитель абстрактный, оторванный от реального железа.

То есть алгоритм есть метаинформация по отношению к программе, и отношение это имеет следующие свойства:
- (в классике обычно) рассматривается только процедурный слой;
- (в классике обычно) подразумевается последовательный исполнитель (даже параллельность не меняет дело, потому что всё равно сводится к набору последовательных исполнителей);
- алгоритм допускает множество разных реализаций;
- с другой стороны, задачу можно решить множеством разных алгоритмов.
Ну что ещё? Какие свойства вас интересуют и, главное, зачем?

Главное, что следует упомянуть: трансляция алгоритм-программа возможна в обе стороны, и в обоих случаях она не является однозначной. Кроме того, она и возможна-то не всегда
Именно это рассуждение заставляет утверждать, что алгоритм от программы в ряде случаев не отличается решительно ничем, кроме исполнителя. То есть это всего лишь одни и те же предписания на разных языках...


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

Вы можете наложить структурные ограничения на операции преобразования алгоритмов, тогда будет казаться, что несчастное запрещённого goto загнали на уровень семантики, но впечатления эти будут ложны: упомянутые ограничения и есть по существу синтаксис.
Не знаю, пригодится ли вам это рассуждение (я, скажем, вообще не понимаю, зачем оно затеяно). Но вот так как-то

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

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

Очень оригинальная точка зрения.
Есть информация к размышлению.
Но хотелось бы знать:
1) Что значит"абстрактный исполнитель": абстрактный (отвлеченный) от чего?
2) Они (абстрактные исполнители) существуют в природе?

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

Это вполне реальный (реально существующий в природе) класс реальных исполнителей
(абстрактным является понятие это класса исполнителей,
в отличие от более конкретных представлений о конкретном Иванове, Петрове, Сидорове и т.п.).
И дети такие предписания называют алгоритмами, а не программами.
Они неправильно поступают?

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

А для машины эти алгоритмы дети переписывают по другому,
и называют их программами.
Они неправильно поступают?

Они могут ввести такие программы в машину и выполнять.
Это программная реализация алгоритмов-предписаний для обычных персональных (например) компьютеров.
Это также вполне реально существующий класс исполнителей таких алгоритмов-программ
(абстрактными являются понятия таких исполнителей).

---------------------------------------------
Появляются вопросы:
1) Детишки в школе неправильно различают алгоритмы и программы?
2) Где здесь абстрактные исполнители школьного алгоритма и школьной программы для ПК?

(продолжение следует)

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

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

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

От излишних деталей технической реализации исполнителя.
Причём процесс имеет место на всех когнитивных уровнях:
- абстрагируясь от формы электрических сигналов, работаем с битами, байтами и интерфейсами;
- абстрагируясь от кодов команд процессора, работаем с ассемблером;
- абстрагируясь от архитектуры процессора в значительной мере, вместо ассемблера получаем ЯВУ;
- абстрагируясь от архитектуры процессора в полной мере и от синтаксиса ЯВУ в значительной мере, работаем с алгоритмом;
- абстрагируясь от конкретики алгоритма, работаем с математической моделью;
- абстрагируясь от математической модели, работаем с задачами.

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

Возвращаясь к пресловутому алгоритму, смотрим на эту иерархию и видим, что алгоритм - это всего лишь попытка максимально абстрагироваться от деталей реализации исполнителя.
Естественно, абстрагирование - процесс очень плохо формализуемый.
В самом грубом приближении, нам достаточно выкинуть всё, что связано с конкретной формальной системой команд.
Однако чудес не бывает, и исполнитель (например, человек) тогда будет вынужден выполнять команды неформальные ("поди туда не знаю куда"), а это тупик для инженерии.
Соответственно, приходится выделять какие-то инварианты:

- обязательность действий;
- последовательность действий;
- формализованная реакция на бинарные вопросы (да/нет).

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

Правильно. Им дали термин, они и пользуются. Дали бы другой - употребляли бы его.

Выделил ключевые моменты.
Насчёт "правильности" вы можете ответить сами - они просто соответствуют конкретной технологии программирования.

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

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

Возвращаясь к моей теме про алгоритм, замечу в качестве резюме: всё определяется задачей. Нас будет интересовать класс задач, для которых:
- задача может быть решена путём программирования;
- задача допускает выбор различных исполнителей и, соответственно, технологий программирования;
- одна из возможных технологий позволяет получить промежуточный результат - программу, абстрагированную как от уровня модели (детализированную, описывающую процесс преобразования пространства состояний модели), так и от конкретного исполнителя (это и есть наш алгоритм). При этом:
- программа под названием "алгоритм" уже формально предписывает порядок действий, но пока ещё оставляет за кадром вопрос выбора наиболее подходящего исполнителя (допускает выбрать разные). Обратите внимание, что ценность этого промежуточного этапа заключается именно в откладывании выбора подходящего исполнителя (если исполнитель уже есть и замене не подлежит, данный этап может быть полезен только из-за имеющихся наработок предыдущего опыта (ряда готовых решений).