DRAKON.SU

Кстати есть замечательный учебник:
Н. К. Верещагин, А. Шень. Лекции по математической логике и теории алгоритмов
брать тут: http://www.mccme.ru/free-books/

В частности в третьей части все разжевано про рекурсивные функции: http://www.mccme.ru/free-books/shen/she ... art3-2.pdf

Йес-йес-йес!!!
Пусть "ценой собственной репутации", но этого человека удалось подвигнуть вести конструктивный диалог без лишнего умничанья!

Объяснение хорошее, вполне понятное, спасибо.
Тезисы понятны и, я бы даже сказал, очевидны. И "формализм понятен", хотя с ФП я так и не знаком.
(И за ссылки спасибо, пригодятся!)

Есть одно но.
Весь этот формализм определён в дискретной области. Требование счётности множества об этом однозначно свидетельствует, например.

А что делать с задачами, которые решаются не в дискретной парадигме, а в аналоговой?
Очевидно, всю совокупность методов решения таких задач вы отказываетесь признавать хоть сколько-нибудь алгоритмической?

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

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

Посмотрим, что это за нечто такое и откуда оно берётся.
Распишем цепочки подробнее.
Что мы имеем в дискретной парадигме?
Аналоговая модель, наш дифур + (численный метод) => алгоритм => программа для ЦВМ.
То есть применяя один из численных методов, мы преобразуем модель в соответствии с требованиями данного метода (представление в нормальной форме, разложение на систему дифуров 1 порядка и т.п.), переходим к уравнениям в конечных разностях и получаем алгоритм их численного интегрирования.
Затем алгоритм тем или иным способом транслируется в код исполнителя - получается программа.

А что в аналоговой?
Аналоговая модель, наш дифур + (нормализация) => шаблон программы + (масштабирование) => программа для АВМ.
То есть мы преобразуем модель в соответствии с требованиями данного метода (представление в нормальной форме, разложение на систему дифуров 1 порядка и т.п.) - в результате получаем некий шаблон аналоговой программы (где. например, каждый дифур моделируется операционным усилителем).
Затем полученный шаблон транслируется в код исполнителя (выбираются конкретные усилители, производится масштабирование сигналов в соответствии с возможностями исполнителя - получается программа для АВМ.

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

Причём то, что мы легко в дискретном случае называем алгоритмом, представляет собой не что иное, как абстрактную программу (численный метод, записанный в применении к решаемому дифуру). От чего абстрагирована эта программа? Да от особенностей исполнителя. Далее, естественно, требуется перевести эту абстрактную программу в код исполнителя. В теории и практике CS об этом процессе говорят как о реализации алгоритма. Но, если говорить обобщённо, мы просто имеем один или несколько этапов трансляции программы.
Алгоритм неуловимо испарился, затерявшись где-то в формализме численного метода, к которому добавилась часть для вычисления нашего конкретного дифура!

А в аналоговом случае мы опять-таки имеем промежуточную абстрактную программу, в которой дифур 1 порядка решается операционным усилителем, а такая-то нелинейность - такими-то добавками. Но эта первоначальная штуковина пока абстрагирована от конкретного исполнителя. Вот когда мы будем знать, что на нашей АВМ максимум напряжения ОУ - 100В, мы сможем путём масштабирования провести трансляцию программы в код конкретного исполнителя.

Согласны, что формальное описание процесса решения задачи в аналоговой и дискретной парадигме тождественно?
Тогда вам неминуемо придётся назвать первую (абстрактную) версию аналоговой программы алгоритмом (пусть аналоговым).
Либо, напротив, совсем отказаться от термина "алгоритм" и говорить о степени абстрактности/детализации программы.

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

Но пара вопросов у меня к вам есть.
В чем ваш интерес к аналоговому в плане алгоритмов?
Чем вас цифровые исполнители не устраивают?



Нет. Ибо я не вижу формального описания.

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

Устраивают, как данность, как вес предмета на Земле, который трудно обойти и с которым приходится считаться.

Тем не менее, насколько мне известно, никто не доказал принципиального преимущества цифрового исполнителя.
Скорее даже наоборот, если смотреть на природу!


Ну и, как я понимаю, развёрнутые тезисы возражений у вас не вызвали, просто вы не видите необходимости в подобных философских упражнениях?


P.S. Ну что за манера добавлять текст сообщения, на которое уже отвечают.

Слишком многого хотите от форумной дискуссии и экспромта. Но если хотите, можете сделать сами.

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

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

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



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

Ну вот к примеру вопрос: Являются ли вычислительные возможности МТ фундаментальным ограничением вселенной? Это проблема. И это философский вопрос заслуживающий внимания на мой взгляд.
А натягивание алгоритмов на аналоговое просто не интересно, т.к. не видно смысла в этом.



ps Читали Дойча "Структура реальности"?

Может быть, предсказание результатов эксперимента в условиях квантовой неопределённости?

О, это великолепная тема!

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

Это пока только догадки. Пенроуз на эту тему писал.
Пруфов пока никаких нет, на сколько мне известно.


ps У меня тоже есть один личный бред. Из него в частности получается, что таки да, это ограничение вселенной. Т.е. преодоление возможностей МТ - это то же, что преодоление скорости света. Озвучу возможно после обдумывания в отпуске.

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

А зря....

Надо всё-таки определить используемые понятия... и их соотношения...

Вот возьмём ТАУ. Можно ли понимать её как синоним теории управления (кибернетики)? Вроде да, она даёт подход к моделированию управления. Но какой? Через передаточные функции. А ведь уже давно установлена потеря точности описания деятельности человека при выборе такого формализма...
Так что можно предположить, что тут соотношение такое же, как между теорией информации в целом и "по Шеннону". Сам он, кстати, называл её "математическая теория связи"... что должно больше соответствовать... Теория информации включает в себя также и вопросы ценности (которые начали разрабатывать Хартли, Харкевич). И учёт неопределённостей, например как у Зверева через "информационные ноли" (а это уже не только математика, но и формальная логика).
Вот и ТАУ - это "математическая теория определённого по крайней мере субъектно управления" (для исполнителя с известной моделью). А теория управления пошире... она о целенаправленных системах вообще, в т.ч. и таких, для которых адекватной математической модели "решаемой численно/символьно" мы предложить не можем...

Теперь рассмотрим формулу программирования Донского отсюда. Тоже бы её уточнил, введя как аргумент функции "программировать" совокупность исполнителей в течение ЖЦ программы. Тогда исполнители фазы построения создают описание поведения исполнителей фазы применения. В частном случае типы для разных фаз совпадают (создание для себя/такого же). Исполнитель определяется языком. Задачу создания можно рассматривать как перевод описания с языка создания на язык применения.
Тогда можно заметить следующее. На практике, как правило, автор это один субъект, а переводчик - другой (а читатель/исполнитель - третий). Возможно их совпадение. Например, это должно следовать из концепции примененения ББ "программирующими ИТ-непрофессионалами" для автоматизации задач своей основной предметики. Но это требует наиболее продуманной организации той самой "метаинформации" о предметиках/задачах! Отсюда и регулярные обращения следующих такой концепции к проблеме "разработки И документирования"... И в то же время это же позволяет максимально задействовать для организации индивидуальный аппарат мышления! Отсюда и нерешённость проблемы как системной, в целом в результате таких обращений - проще всё-таки сосредотачиваться на основной деятельности, лишь выделяя частные проблемки организации и пытаясь их формализовать по мере сил (и что-то реализовать автоматизированно)... а в целом всё-таки поддерживать организацию мысленно, на своём внутреннем языке... В то же время разделение труда ещё никто не отменял... Собственно об этом говорилось здесь. Можно и "суперкомпиляцию" привлечь для объяснения, наверное...

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

Пока никто не дал пояснений по вопросу, выделенному красным цветом.

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

На вольном досуге в августе было время подумать по этому поводу.
Просмотрел несколько статей [1, 2, 3, 4] по теории алгорифмов (алгоритмов) из сборника трудов А.А. Маркова, 2-й том.
В каждой статье – очень краткое ("эскизное") изложение и постепенная доводка
сути предлагаемой теории алгоритмов на базе так называемых нормальных алгорифмов
и ее назначения для приложений в конструктивном математическом анализе
(для строгого обоснования классического анализа),
что подробно изложено в фундаментальных книгах [5] и [6].

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

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

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

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

=======================
Во-втретьих, необходимо поработать с обобщениями определений алгоритма.

Для обобщений алгоритмов на любые процессы преобразования информационных объектов и потоков:
их потенциальная осуществимость аргументируется аналогичным образом.

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

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


ЛИТЕРАТУРА

1. Марков А.А. Теория алгорифмов. / Труды матем. ин-та им. В.А. Стеклова. – 1951. – Т. 38. – С. 176-189. // Марков А.А. Избранные труды. Т. II. Теория алгорифмов и кон-структивная математика, математическая логика, информатика и смежные науки. – М.: Изд-во МЦНМО, 2003. С. 32 – 43.

2. Марков А.А. О неразрешимых алгорифмических проблемах. – М.: Математический сборник. – 1952. – С. 34- 42. / Марков А.А. Избранные труды. Т. 2. – М.: Изд-во МЦНМО, 2003. – С. 56-63.

Ссылка (А.А. Марков [2], с.3)
3. Марков А.А. Теория алгорифмов. / Труды матем. ин-та им. В.А. Стеклова. 42. – М.-Л.: Изд. АН СССР, 1954.

4. Марков А.А. Математическая логика и вычислительная математика. / Вестн. АН СССР. – 1957. – Т. 27, № 8. С. 21-25. / Марков А.А. Избранные труды. Т. 2. – М.: Изд-во МЦНМО, 2003. – С. 32-43.

5. Марков А. А., Нагорный Н. М. Теория алгорифмов. – М.: Наука, 1984. – 432 с.

6. Кушнер Б. А. Лекции по конструктивному математическому анализу. М.: Наука, 1973. – 448 с.

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

Теперь по тексту.

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

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

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


А вот и нет.
Попробую привести пару примеров.

Дано пространство состояний: кошелёк с количеством монет N и палочка. (N - варьируемые исходные данные, чтоб были для полноты картины ).
Алгоритм: взмахнуть палочкой над кошельком.
Результат исполнения алгоритма: в кошельке 2*N монет.

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

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


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

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


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


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



Теперь вот ещё важный момент.
Чуть-чуть изменим первый пример: вместо депозитного будет КРЕДИТНЫЙ договор.
Такой вариант пространства состояний, как ни странно, куда лучше удовлетворяет условиям задачи (не требуется время), хотя по содержанию (характеру процесса и отдалённым последствиям в пространстве состояний) будет в некотором смысле противоположным!

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

А у меня такое впечатление, что я еще немного поумнел.

1) До того я считал, что не нужно указывать свойство алгоритма:
потенциальная осуществимость заданного им процесса (и следовательно самого алгоритма).
Это, мол, и козе понятно, и нужно рассматривать просто осуществимость.
А здесь много оттенков:
соответствие системы команд алгоритма системе команд исполнителя,
ресурсная обеспеченность исполнителя и т.п.

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

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


Здесь можно уточнить определение алгоритма - в разных вариантах.

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

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

Искомый результат - соответствует направленности (целенаправленности) выч. процесса.

Здесь возможны эквивалентные соответствия терминологии (с разными оттенками):
исходные данные (аргументы) функции ~ входные данные алгоритма ~ начальные данные процесса;
результат решения функции ~ выходные данные алгоритма ~ конечные данные процесса.

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

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

Там дальше не очень понятно, что конкретно означает пространство состояний и процесс его преобразования.
Преобразование пространства состояний?:
1) Это, например, пересчет прямоугольной (или косоугольной) системы координат в цилиндрическую или сферическую? (трехмерную или многомерную):
для промышленного робота, например, с ангулярной системой координат.
2) Или это преобразование обобщенного (комбинированного) состояния системы (траектория перемещения) в заданном пространстве состояний?
3) Или что-то еще? Я не математик и не физик - что-то не врубаюсь.
4) Депозит и кредит - вообще не улавливаю алгоритмическую разницу (экономически не подкованный).

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

Но это в следующем посте - итак перегрузка текста.

Ну это очевидно ожидаемый результат, чего о нём говорить-то!

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

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

Это уже на потенциальную осуществимость не влияет никак, только на практическую.

Зачем?

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

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

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

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

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

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

Например, да.

Тоже да.

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

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

Как бы я выше достаточно написал для того, чтобы не задаваться подобными вопросами?

Я же говорил - не путать!
В первом случае принципиально невозможно найти подходящее пространство состояний при заданном виде процесса (алгоритме), а во втором - невозможно найти подходящий процесс (алгоритм) в заданном пространстве состояний.

http://walwalru.blogspot.ru/2014_08_01_archive.html
У преподавателя школы нет проблемы с определением понятия алгоритм.

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

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

Это уже прикладная классика - школа академика Ершова А.П.
Надо будет зайти в магазин и посмотреть учебники информатики:
как сейчас в школе определяют алгоритм?
По моим предположениям - примерно также (с авторскими вариациями).

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

Надо будет на досуге внимательно посмотреть тему:
Новый учебный год с Драконом. 2-й класс.

Например, два определения одного автора:

1-е определение - 1951 год [1, с. 32]:
"В математике принято понимать под алгорифмом вычислительный процесс,
совершаемый согласно точному предписанию
и ведущий от могущих варьироваться исходных данных и искомому результату".
То есть:
алгоритм - это вычислительный процесс, выполняемый согласно точному предписанию ... .

2-е определение - 1984 год [2, с. 9]:
"В математическом обиходе под алгорифмом (алгоритмом) принято понимать"
"точное предписание, определяющее вычислительный процесс,
ведущий от варьируемых исходных данных к искомому результату".
То есть:
Алгоритм - это точное предписание, определяющее вычислительных процесс, ...

Вроде бы примерно одно и тоже, но с точностью до наоборот.

Литература
1. Марков А.А. Теория алгорифмов. / Труды матем. ин-та им. В.А. Стеклова. – 1951. – Т. 38. – С. 176-189. // Марков А.А. Избранные труды. Т. II. Теория алгорифмов и конструктивная математика, математическая логика, информатика и смежные науки. – М.: Изд-во МЦНМО, 2003. С. 32 – 43.
2. Марков А. А., Нагорный Н. М. Теория алгорифмов. – М.: Наука, 1984. – 432 с.




На работе подвернулась книга:
Семакин И.Г. Информатика. Структурированный конспект базового курса. - М.: Лаборатория Базовых Знаний, 2004. - 168 с.
Определение алгоритма (с. 140):
алгоритм - это понятное и точное предписание (инструкция) исполнителю
выполнить конечную последовательность действий (команд)
приводящих от искомых данных к конечному результату.
То есть:
алгоритм - это предписание ... .

Где-то у меня были пособия по подготовке к ЕГЭ по информатике:
там тоже, по-видимому, "алгоритм - это предписание ...", иначе я бы обратил внимание.
Надо будет посмотреть дома.

-----------------------------
Лучше, конечно, отредактировать определение алгоритма для 2-го класса, типа:
алгоритм - это точное предписание совершить последовательность действий ... .
В соответствии с ЕГЭ: алгоритм - это предписание ... .
Но необходимо оговорить разные формы представления алгоритмов.

А воз и ныне там...



Все, что в принципе можно описать, кодируемо двоичным числом. Так?
Двоичное число == натуральное число.

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

Али вы думали, что ЧРФ ради смеха на натуральных числах строят?

Сколько не фантазируй о "пространствах состояний", а от чисел и вычислений никуда не уйдешь.
Это просто бесполезное занятие.

Только в дискретной модели.

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

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


Вы чего-то недопонимаете. Любое преобразование информации называется вычислением.
В машинах Тьюринга, алгорифмах Маркова, лямбда-исчислении и машинах Колмогорова никаких чисел нет. Однако это все вычисления.


Вы сначала в своей голове порядок наведите...