DRAKON.SU

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

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

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

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

То есть, пока не видно необходимости введения понятия "абстрактного (абсолютно абстрактного) исполнителя".
Если только в каком-то непонятном фигуральном смысле?

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

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

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

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

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

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

Эти классы исполнителей каждого уровня (i)
явно или неявно (сознательно или бессознательно) представлены понятиями исполнителя,
которые имеют следующие компоненты:
1) Ni: Имя класса - имя понятия (которое представляет этот класс).
2) Vi: Объем понятия - некоторое множество исполнителей.
3) Qi: Качество понятия - множество общих признаков, общих для всех элементов (исполнителей) этого множества.

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

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

Можно только пытаться догадываться, что бы это значило:
о каких конкретно классах исполнителей идет речь?
Соображать из каких-то контекстов (в голове) - у всех по своему.

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

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

---------------------------
С термином "абстрактный" необходима осмотрительность в его применении.
Есть хороший пример некорректного (неуместного) применения признака "абстрактный":

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

2) На самом деле на первом этапе выполняется
вполне конкретный структурный синтез вполне конкретной структуры необходимого дискретного процесса, заданного исходными условиями.

3) А на втором этапе выполняется синтез структуры аппаратной реализации этого процесса:
-- с двоичным кодированием состояний автомата комбинациями состояний двоичных элементов памяти - для экономии аппаратуры (раньше это было остро актуально);
-- с полной потерей наглядного соответствия двух отображаемых структур - в сети связей аппаратуры;

4) Если под каждое состояние выделить отдельный элемент памяти:
-- аппаратурные затраты заведомо возрастут;
-- но сейчас такое крохоборство в общем случае не столь актуально,
а в программной реализации конечных автоматов - тем более;
-- обеспечивается явное соответствие (явный изоморфизм) отображения структуры процесса и структуры аппаратной реализации;
-- упрощается синтез в целом и проблема понимания и объяснения схемы реализации автомата.

----------------------------------------------
То есть снова здорово: Мы с Вами упорно держимся каждый своих установок.
Ну и ладно - мы представляем схемы рассуждений друг друга.
Можем сопоставлять свои подходы (и результаты).

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

(продолжение)

У всех могут быть разные интересы (вплоть до противоположных).


-----------------------------------
Что не определяется в семантике - это точно (а точнее - не определяется в основной целевой семантике).
Но принадлежит алгоритму как предписанию.


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


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

А от основного (целевого) смысла алгоритмов
структурная теория алгоритмов, наоборот, по возможности абстрагируется разными способами:
она оперирует обобщенными структурными классами алгоритмов - в это ее мощь
(как у обобщенной алгебры - по сравнению с конкретной арифметикой).

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

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

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

Но.

На любом уровне иерархии абстракций необходимо говорить о тезаурусе и языке.

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

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

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

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

Прошу заметить, что абстракция - это относительная, а не абсолютная категория!

Ну так не держитесь, кто заставляет-то?
Я же не держусь - у меня идёт чистая импровизация. Но предмет обсуждения настолько прост, что всё время почти одинаковые выводы получаются!

Вы очень искусно обошли самое главное в моих предыдущих постах:
Поэтому над чётко отдавать себе отчёт, что разницы между текстовым и не текстовым представлением нет - они оба есть всего лишь представления!

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

У нас с Вами получается разговор слепого с глухим.
Всяк на своем стоит.Ну да:
"Я же на возражаю" - возразил он.

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

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

----------------------------------
Но предварительно полезно подвести по крайней мере один важный итог (пока он не замылился).

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


-------------------------
Ну и к стати говоря:

1) На всех уровнях явно или неявно присутствуют дискретные процессы определенного типа.

2) Их выполняют некоторые объекты-исполнители определенного типа
(процессоры - в широкой интерпретации термина).

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

4) Такие модели - описания (предписания) дискретных процессов могут быть 2-х типов
(примерная схема):
4.1) Алгоритмические описания (предписания) - в разных форма представления:
с явным выделением потока управления и потока данных - это главная специфика;
4.2) Разные дискретные модели:
-- автоматы логического управления - комбинационные и последовательностные;
-- конечные автоматы - последовательные и параллельные (коллективы автоматов)
и их обобщения - магазинные автоматы и т.п.;
-- сетевые (параллельные) модели - сети Петри, сетевые графики и т.п.

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

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

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

очень проблематичное (лучше сказать некорректное) в двух отношениях:
1) В отношении выражения "абстрактный исполнитель".
2) В отношении схемы вывода понятия алгоритма из понятия программы:
-- традиционно явно или неявно используется обратное соотношение:
понятие программы выводится из понятия алгоритма;
-- алгоритмы использовались (человеком-исполнителем) еще до появления программирования:
например, алгоритм (правило) Евклида никто не называет программой Евклида;
-- классическая теория алгоритмов возникла (в 30-х годах) еще до появления ЭВМ и программирования и т.п.

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

И еще (пока не замылилось).
Да Вы же сами говорите:


Быть не должно (???)
А если возьмем ER-диаграмму, например, в СУДБ типа MS Eсcess:
1) Просто для изучения БД - здесь действительно нет императива.
2) А если мы скажем:
По щючьему велению, по моему хотению: БД создайся - то есть кликнем команду создания базы данных.
И сформируется заданная ER-диаграммой структура базы данных - для наполнения и последующего ведения БД.
Здесь явно появился императив, и он был исполнен (какой-то нечистой силой? - без алгоритмов?).

За этот пример тоже большое спасибо.
Пригодится.

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

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

Кстати, об этих настроениях:

Прозревайте, и увидите, что можно говорить по-другому, а кое о чём и вовсе говорить не нужно

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

Предмет обсуждения прост и яйца выеденного не стоит.
Но вы по-прежнему продолжаете нагружать предмет лишним содержанием, пытаетесь применить его в том контексте, где он не является адекватным.

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

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

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


Как хотите, мне не интересно.
Я не вижу никаких проблем с goto. Если у большинства исполнителей так или иначе есть команда условного (и безусловного) перехода, то отображение этой системы команд вполне адекватно. И больше говорить-то вроде не о чем.
Да, Дейкстра. Да, оптимизация (когнитивная, а также для автоматизации всяких хитрых штук вроде верификации и доказательства). Но это всё отображения.

Методологии тут не усматриваю. Хороший язык, есть некоторые полезности (частные, локальные в основном) - и всё. На методологию не тянет никоим образом.

Да пожалуйста. Смысл в классификации очевидного?

Хилая классификация. Донаучная ещё.
Хотите классифицировать - рассматривайте области определения, применимости, классы решаемых задач, потоки преобразования информации. А вы - "общие признаки". Да капля в море.

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

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

Что может быть скрыто в дифуре?
- Формальная связь одних процессов с другими.
- Количественные и качественные соотношения.
- Динамика переходных процессов.
...


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

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

Констатирую непонимание термина "абстрагирование"...

Какое отношение имеет этот прискорбный факт к научному исследованию проблематики?

Констатирую непонимание термина "предписание", она же "программа".

Вообще не в тему.
Скатились в жонглирование словами, не терминами даже.

Процесс абстрагирования!

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

Констатирую и акцентирую:
У нас с Вами получается разговор слепого с глухим.
И еще акцентирую - аналогичная рекомендация:
Прозревайте. Наконец-то.

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

Но мы можем продолжать бодаться на другой теме - на тему типа:
"алгоритм есть программа для абстрактного исполнителя" - это абсурд.

Именно поэтому я буду настаивать на ряде тезисов.

"Алгоритм есть программа для абстрактного исполнителя" - это кратко выраженная суть.

Возражений по существу от вас не поступило (если вдруг не заметил, ткните в цитату).

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

Далее. То, что может декодировать этот исполнитель, по определению является программой для него (то есть набором команд, предписаний). Возражения есть?

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

Что непонятного?

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

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

На теме Трансляция ДРАКОН-схем в программный код С++"
есть пост viewtopic.php?f=62&t=5168#p90489

И далее viewtopic.php?f=62&t=5168#p90493:

И далее viewtopic.php?f=62&t=5168#p90507:

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

А далее предлагается поработать (головой) по вопросу:
Алгоритм есть программа для абстрактного исполнителя
А предварительно - по вопросу:
(продолжение следует)

В этом посте ставится вопрос:
В чем разница между алгоритмом и программой ???
(3 знака вопроса означают: вопрос на засыпку)

И там предписание, и тут предписание.
Но какая же разница между терминами?:

1) Это термины разного представления их смысла:
-- алгоритм - это предписание по (внешнему) определению термина:
по приданному ему смыслу;
-- программа - это предписание по (внутреннему) смыслу морфологии термина:
по встроенному смыслу,заложенному в сам термин.

2) В первом приближении - это термины равноценные по их общему смыслу:
это предписания.

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

-------------------------------------
3.1) Термин "Алгоритм".

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

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

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

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


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

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

--------------------
2) Термин "программа":

2.1) Время и обстоятельства появление его, видимо, точно неизвестно
(автору этого поста, по крайней мере);

2.2) В начале 20-го века и далее он использовался, в частности, для формулировки партийных установок:
-- программа минимум и программа максимум большевиков;
-- программа КПСС и т.п.

2.3) В целом в настоящее время:
"Данное понятие непосредственно связано с поянтием алгоритма"
(но здесь не говорится конкретно, как связано).

2.4) Компьютерная программа:

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

Просьба к модераторам всё-таки перенести сюда сообщения с viewtopic.php?p=90486#p90486 до конца той темы.

andr, данная тема возникла на фоне неуёмного стремления В.Д.Паронджанова поставить алгоритм во главу угла всей интеллектуальной деятельности (видимо, чтобы обосновать применение Дракона где только можно и даже где не нужно).

И тут же обнаружилась интересная штука... Но по порядку.
Очевидны следующие предпосылки.

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

Рассмотрим примеры.

Перфокарта для механического пианино однозначно рассматривается как программа для него (ну, вернее, программой является код, а сама перфокарта - её носителем, но это уже мелочи). В то же время никто не рискнёт назвать эту штуку алгоритмом.

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

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

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


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

Что мы видим здесь общего:
- разница в степени детализации (или абстракции, если с другой стороны смотреть);
- алгоритм рассматривается как метаинформация по отношению к программе.

Отсюда и вытекает моё определение алгоритма как программы для наиболее абстрактного исполнителя.


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

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

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

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


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

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

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

Во-вторых:
неуёмное стремление В.Д.Паронджанова поставить алгоритм во главу угла всей интеллектуальной деятельности
(видимо, чтобы обосновать применение Дракона где только можно и даже где не нужно).

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

2) Желательно было убедиться поконкретнее - обосновать применение Дракона:
-- где нужно?
-- где не нужно? - а то как бы нас всех не засосало в неуемном стремлении.

3) Этот вопрос как раз и относится к дракон-методологии.
Лучше бы ее там и обсуждать - на теме:
Дракон-методология
И конкретнее, а не просто на уровне эмоций общего недовольства.

==================
Я все-таки предлагаю конкретно решить вопрос:
С алгоритмами здесь достаточно ясно.
Есть в принципе, общая точка опоры.
Или нет?
А с программами - это следующий отдельный разговор.

Иначе у нас с Вам будет бесконечные бодания с тенью:
у каждого со своей.

Книга в тему: Эмпахер А. Сила аналогий

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


После прочтения рекомендую подумать к каким устройствам относится логарифмическая линейка.

Хочу сразу предупредить. Переводчик там тупит и буксует. Не перепутайте слова переводчика со словами автора.

Какие-то у Вас детские вопросы - из школьных тестов по информатике, что ли?

И в какую тему книга?
Выражайтесь, пожалуйста, точнее.

Если тема "Что же такое алгоритм?", то причем тут аналоговые устройства?

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

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

Рекомендую еще раз почитать эту книгу и подумать:
логарифмическая линейка умеет думать, мыслить то-есть?

Уважаемый Alexey_Donskoy привёл очень хороший пример, на котором можно чётко увидеть разницу между алгоритмом и программой.



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

Алгоритм описывает звук какой частоты, длительности и в каком порядке будет воспроизведён механическим пианино для извлечения мелодии «Широка страна моя родная».

Более того, этот алгоритм (в отличии от перфокарты) полезен и музыкантам, и мастерам, которые собираются делать «мехпианины» и программистам : )

Важной особенностью алгоритма является прямое указание цели, которая должна быть достигнута в результате действий исполнителя. Так как алгоритм описывает будущие действия исполнителя, то он, по сути, является предсказанием: «Если будут выполнены такие-то и такие-то действия, в таких-то и таких-то условиях, то будет достигнута такая-то цель».

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


Итого:

Алгоритм — описание порядка действий исполнител(я/ей), для достижения определённой цели.

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


На примере с Прологом вообще всё просто. Алгоритм один на все случаи жизни и зашит в пролог-машину. Программа состоит из одной команды «фас» (goal), после которой начинает пожирать данные. Повторюсь, алгоритм обработки данных один и зашит внутри пролог-машины.