DRAKON.SU

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

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

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

Представления с акцентом на потоках данных - DFD, FBD, Ptolemy, G в LabView, и прочая - упускают весьма важный аспект для множества систем - время. Последовательность. Без рассмотрения коего мы упускаем часть семантики.

Могу порекомендовать свою книгу по графическим языкам

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

И опять напомню, что речь идёт не о представлениях, а о модели.
Разве в дифуре нет времени?

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

И давайте не путать принципиально различные подходы.
DFD действительно упускает часть семантики (время). И это сделано намеренно.
FBD (равно электрическая или логическая схемы) семантику содержат в полном объёме (потому как представляют адекватную модель физической системы).

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

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

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

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


Кстати о формуле типа дифура - вопрос на засыпку (мы уже с ним кувыркались):
является ли формула дифура алгоритмом?

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

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

Все это может показаться диким вывертом - софистика с правдоподобной обманкой.
Однако это полезное расширение традиционного (первобытного) понятия алгоритма.

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

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

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

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

Так вот получается, что в дифуре есть последовательность - линейный (полный) порядок.

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

Следовательно, этот дифур - это уже параллельный алгоритм - в обобщенном плане:
для исполнителя с транслятором.

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

Так что делать?
Какой вариант надо выбирать?
Это уравнение (система уравнений) с потенциальным параллелизмом.
Получается - это не вполне определенный алгоритм.
Тогда его надо доопределять - для конкретного решения задачи:
приставить к нему исполнителя с транслятором + с планировщиком задач.

Ну так это так и делается - каждый день.

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

И идёт это сопоставление от рассмотрения ПРОГРАММЫ - как бы этаким оптимальным образом её ПРЕДСТАВИТЬ, чтобы понятно и удобно было.

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

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

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

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

Наглядный пример: карта - существенные структурные свойства местности, и над ней можно решать самые различные задачи. Пролей воду - она потечёт по градиенту высоты. Укажи две точки А и Б - построим алгоритм движения из А в Б. И так далее, и тому подобное.

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

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

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

Все это особенно (на порядок) актуально для параллельных алгоритмов и программ.

Или, как у нас уже было на форуме:
-- с одной стороны (в одной проекции) - круг;
-- с другой стороны (в другой проекции) - квадрат;
-- а наискосок (в изометрии, например) - цилиндр.

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

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

И они полезны также в сборе в их явной взаимосвязи.
Например:
http://forum.oberoncore.ru/viewtopic.php?p=93258#p93258

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

------------
Правда в технических алгоритмах есть качественно новая специфика:
во-первых, помимо потоков информационных данных существуют потоки материальных данных;
во-вторых, промежуточные информационные потоки данных могут отсутствовать.
в-третьих, материальные потоки данных всегда крайне желательно отображать во взаимосвязи с потоками управления.
Например:
http://forum.oberoncore.ru/viewtopic.php?p=93285#p93285 Предпоследняя картинка (один из способов).

=======================================
Давайте разберемся по порядку.

Это понятное дело.

Тоже понятное дело.

И это тоже.

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

А для чего такие описания:
-- для исследований;
...
-- для любования на них;
...
-- для практического применения - методом решения дифференциальных уравнений.

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

Но сам дифур (формула) для опытного вычислителя:
это алгоритм?
это руководство к действию?
Вот в чем вопрос.

=======================================
Для сравнения - более простой случай.

1)
Задана расчетная формула (вычисление пл. трапеции):
s = (((a + b) / 2) * h).

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

В данном случае эта формула является алгоритмом для такого школьника?
Руководством к действию?
Вот в чем (первый) вопрос.

2)
После эквивалентных преобразований получается формула:
s = ((a + b) * (h / 2)).

Ситуация качественно поменялась.
Обученный школьник сообразит - есть два (последовательных) варианта вычислений,
и он вычислит:
-- либо сначала (a + b), затем (h / 2), затем - перемножит результаты;
-- либо сначала (h / 2), затем (a + b), затем - перемножит результаты;

Дообученный (предположим) школьник сообразит дополнительно - есть параллельный порядок вычислений:
сначала параллельно вычислить (a + b) и (h / 2), затем перемножить результаты.
Но для этого ему надо привлечь соседа по парте.
Имеет смысл, если вычисления (вручную) с большими числами и с большой точностью,
и позарез надо быстро.

Еще (дополнительно дообученный) школьник сообразит,
какой вариант из этих трех выбрать,
и решит задачу.

А в данном случае эта формула является алгоритмом для такого школьника?
Руководством к действию.
Вот в чем (второй) вопрос.

--------------
Это хорошие головоломки для задачи: что такое алгоритм.

Ну, пошла другая крайность. Что ж, разводить философию так разводить!

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

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

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

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

Дык, синтез не всегда получается успешным. Частенько упускаются существенные вещи.

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

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

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

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

А кто сказал, что её надо вычислять? А может, аналитически преобразовать надо? Или каллиграфически на плакате изобразить?

Разумеется, нет. Это всего лишь исходная матмодель, см. выше задачи, для которых она может пригодиться.

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

Это у Вас философия, уважаемый Алексей.
Вы рассуждаете о дифурах вообще - без конкретики и, в целом, таким же образом достаточно активно на сайте.

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

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

----------------------------------------------------------
Вы сами затронули разговорным мимоходом одни принципиальный вопрос.

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

А затем разбираются конкретно (без философии в общих словах) два простых примера расчетных формул :
s = (((a + b) / 2) * h)
и
s = ((a + b) * (h / 2)).

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

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

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

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

-------------------------------------
Дальше нет смысла продолжать бодаться по разным частностям - все равно мы с Вами останемся каждый при своем мнении.

Но появился еще одни принципиальный вопрос (даже два в одном)

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

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

2
Очень странное утверждение.

Предположим, аппаратно реализованы в виде специальных автоматов следующие простые уравнения (функции):
s = ((a + b) * (h / 2)) - аналоговая реализация
или
y = (x1 & x2) V (x3 & x4) - для ясности аналоговое логическое устройство в непрерывной логике (Min, Max).

Эти уравнения имеют потенциальный параллелизм.
Он неизбежно (неотвратимо) реализуется в аналоговой технике для любых многоместных функций.
Вычислительные ветви (a + b) и (h / 2) в первом устройстве, (x1 & x2) и (x3 & x4)
работают параллельно.

-------------------------------------
Последние выкладки поддерживают идею в ТАУ:
уравнения, которые закладываются в системы автоматического управления (аналогового типа)
это тоже алгоритмы.
Какой ужас - в квадрате !!!

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

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

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

Странным оно вам кажется потому, что вы валите в одну кучу существенно различные системные уровни.
Смотрите выше: дифур появляется в (2), а последовательность (действий) - только в (5)
Если, конечно, вы говорите не про какую-то совсем другую последовательность. Но тогда какое отношение она имеет к теме?

Опять рассматриваете конкретную частную задачу. Зачем? Это очевидный до элементарности мелкий технический вопрос, который к теме отношения не имеет.

Это вовсе не принципиальный, а даже некорректный вопрос. Ибо в нём смешиваются разные системные уровни (2) и (5).
Не понимаю, зачем вам нужно это смешивание, с таким упорством, многие посты и годы?

Блин, вы вообще способны различить банковский счёт и бумажную купюру? Бланк (шаблон документа) и заполненный бланк (конкретный документ)?!
Неужели так трудно понять, что бланк - это модель, уровень (2), а документ (алгоритм управления) - уровень (5)?!

Более того, они вообще могут буквально совпадать по форме (с точностью до символов) - но оставаться при этом совершенно разными сущностями!

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

Вас уличаю, вас, а не кого другого. Ибо вы неверно трактуете все процитированные утверждения.

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

Нет, я не имею его в виду. Такой автомат принципиально ничем от более универсального компьютера не отличается. Разница будет в деталях на уровнях (4) и (5).

Это очень грустно, что странно для вас.
Тут те же системные уровни: (2) - модель, (3) - метод, (4,5) - особенности метода.

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

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

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

Именно, на Ваш взгляд.

Вспоминаю такие Ваши выкладки.
Совершенно не против.

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

Чувствуется какое-то учение - явная тенденция.
Но что, принимать это на веру? - тогда это будет вероучение какое-то.

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

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

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

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

Что за бред, какое там учение. Элементарная логика и системный анализ.
Задавайте конкретные вопросы - я давно и подробно на них отвечаю, если что.
Но то, что ответы вам не нравятся - проблема не моя. Можно и на километры лекцию раскатать - что изменится?

Ни в коем случае, только думать и рассуждать.

Некорректный вопрос.
Как можно общее "встроить" в подмножество, в частный случай?

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

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

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

Золотое правило системотехника:
не говори (не пиши), чего не знаешь - лучше сначала спроси.

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

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

---------------------
Особое (ключевое) значение - анализ параллельных (и последовательных) алгоритмических систем,
включая взаимно согласованные составляющие виды:
1)
Знаковые алгоритмические системы - алгоритмы как (обобщенные) тексты директивного типа
в разных взаимно согласованных и взаимно обратимых знаковых формах представления (разного назначения), разного исполнения:
-- структурные формулы и структурограммы - схемы схемы (блок-схемы, штрих-схемы, граф-схемы),
структурные программные диаграммы и т.д.;
-- псевдокоды алгоритмов - уйма для связи алгоритмов с разными языками программирования;
-- числовые и графические протоколы исполнения (временные диаграмы - линейные и сетевые) и т.п.
2)
Системы реализации (осуществления, воплощения) алгоритмов:
а)
Заданные алгоритмами (и отображаемые в них) дискретные процессы - последовательные и параллельные (в разных режимах):
(целевые) процессные алгоритмические системы.
б)
Предполагаемые алгоритмами, а во можно прямо отображаемые и даже организуемые ими
(инструментальные) исполнительные объектные алгоритмические системы.

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

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

Как видно, не игнорируем

Скорее это недостоверное предположение.

-------------------------------------------
На форуме мы обсуждаем алгоритмы и их программную (в основном) реализацию.
Повторяю свое предложение Вам:

Замечательно.
Только какое отношение это всё имеет к обсуждаемой первичности матмодели (дифура) и вторичности методов работы с ней (в том числе алгоритмов)?

Аналогично. Вы опять перебираете частные технические аспекты, которые относятся по моей классификации к 3-5 уровням.
Где уровень номер (2)?! Когда вы обратите на него внимание?

Ещё раз - мы НЕ обсуждаем весь этот фронт работ. Пусть он хорош, но решительно мимо темы в нашем случае.

Ох, когда же вы перестанете повторять некорректные тезисы и предложения?!
Я уже показал вам детально, в каком месте находится тот фронт работ и теорию алгоритмов, о которых вы говорите. Они вполне логично и адекватно вписываются в мою модель.
Если вас это не убеждает, ничем не могу более помочь.

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

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

А у меня свой работающий профессиональный системный анализ:
-- системотехника АСУ (АСУП, АСУТП) - и сам работал, и участвовал в формировании учебной специальности системомотехника АСУ (еще с начала 70-х и далее):
полезно - когда учишь других, сам начинаешь понимать кое-что;
-- системная аналитика САПР - и сам работал, и участвовал в формировании учебной специальности системного аналитика САПР (с середины 90-х и далее);
-- с конца 70-х пошла системотехника ГПС - гибких производственных систем и РТС - роботизированных технологических систем (грохнулась на перестройке, но еще теплится у нас).

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

Зачем мне Ваш самодеятельный (или нет?) системный анализ? - неизвестно для чего конкретно.
Тем более, что Вы всегда уводите проблему от алгоритмов в строну - какие-то Ваши личные конкретные представления за общими словами.

Вот-вот.
Говорите о системном анализе, но подкладываете какой-то любимый огрызок оного.

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

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

И в связи с этим снова повторяю свое предложение Вам:
И тогда с удовольствием будем в ней разбираться.

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

Однозначно.

Ох, человек так ничего и не понял...

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

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

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


======================================
Забыл ответить на предыдущей Ваш пост:
http://forum.oberoncore.ru/viewtopic.php?p=98171#p98171
Термин "схема" как устройство со схемой (с чертежом) - это технический жаргон
(подсунутый нам, наверное, англосаксами).

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

-----------------------------------------------------
Есть, например, термины:
"логическая схема алгоритма" (ЛСА)
или
"параллельная логическая схема алгоритма" (параллельная ЛСА, ПЛСА).

Как это понимать - свежему читателю со стороны (и вообще):
-- то ли схема типа блок-схема алгоритма (с логикой);
-- то ли какое-то устройство из области схем (устройств) логического управления - в привязке к алгоритмам;
например (логическая схема алгоритма восстановления):
http://www.shematic.net/page-19.html
-- то ли что еще.

На самом деле ЛСА и ПЛСА - это особые символьные записи последовательных или параллельных алгоритмов:
особые структурные формулы алгоритмов с поперечными стрелками нелинейных условных и безусловных переходов.
Это высокоуровневое описание низкоуровневых программ и микропрограмм (еще более низкоуровневых).

Ничего подходящего в инете сходу не нашел, кроме (между Рис. 6.3 и Рис. 6.4):
http://www.studfiles.ru/preview/3498176/

Термин "схема" для ЛСА был введен по общему смыслу
(еще в начале 50-х):
"изложение, изображение, представление чего-либо в самых общих чертах, упрощённо (например, схема доклада)"
https://ru.wikipedia.org/wiki/Схема
[url]https://ru.wikipedia.org/wiki/Схема[/url]
https://ru.wikipedia.org/wiki/Схема_(математика)
[url]https://ru.wikipedia.org/wiki/Схема_(математика)[/url]
Причем это термин был введен в противопоставление
уже известным в то время блок-схемам программ.

---------------------------------------------------------------------------------------------------------
Им (ЛСА и ПЛСА) ставятся в соответствие так называемые граф-схемы алгоритмов.
Это блок-схемы алгоритмов - в мелком исполнении блоков операторов и ромбов лоигческих условий (переключателей) с простановкой в них соответствующих символов ЛСА.
Там же (между Рис. 6.3 и Рис. 6.4):
http://www.studfiles.ru/preview/3498176/

-----------------------------------------------------------------------------------------------
Им (ЛСА и ГСА) ставятся в соответствие матричные схемы алгоритмов (МСА):
Там же:
http://www.studfiles.ru/preview/3498176/

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

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

Но после появления и распространения теории графов термин "граф-схема" в теории алгоритмов
требует уточнения, типа:
Граф-схемы алгоритмов - это диаграммы графов алгоритмов, выполненные в технике теории графов:
узлы и дуги, узлы обозначаются малыми кружками.
Например:
http://mk.cs.msu.ru/images/d/d2/Dm-mag-lect5i-selezn.pdf

Фактически такие граф-схемы используются в теории параллельного программирования:
ярусно-параллельные формы (ЯПФ) алгоритмов и программ.
Например (Ярусно-параллельная форма для программы примера 1):
https://www.irgups.ru/web-edu/sites/files/20151006103407.pdfНо там какая-то недоделанная ЯПФ - нет связей узлов (но интересный источник)
или (ярусно-параллельная форма алгоритма)
http://www.intuit.ru/studies/courses/4447/983/lecture/14919?page=3
http://www.studfiles.ru/preview/2954979/
или (с. 418)
http://www.unn.ru/pages/issues/vestnik/99999999_West_2012_5(2)/63.pdf

Диаграммы графов дополняются матрицами смежности графов
(в строгой постановке задачи идут, обычно, в паре с ними).
Например:
https://ru.wikipedia.org/wiki/Матрица_смежности
[url]https://ru.wikipedia.org/wiki/Матрица_смежности[/url]

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

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


=================
К сожалению не могу представить хорошую явную формульную (ЛСА и ПЛСА) и схемную демонстрацию вставками в этот пост
(приходится ограничиваться "формульным" и "схемным" словесным "трепом").
Прошу пардону.
Или ссылками на другие источники.

На попытки вставок получаю сообщение типа:
"У Вас исчерпан ресурс ...".
Сначала - по вставкам на закачку книг.
А затем на страничные вставки.
В правилах конференции ничего не нашел по этому поводу.
Надо думать, как дальше быть.

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

Или если информация, сама является дифуром, по отношению к физическим объектам, т.е. уровнем 2, то почему к ней должны быть такие же дифуры, и опять на уровне 2? Вроде бы логично, что дифуры для инфы, будут уровнем ниже, т.е. 3? Сами призываете не смешивать уровень 5 и 2, а сами не смешиваете уровни 2 и 3 ?

В каком месте?
И какую информацию? Это ещё то понятие, вокруг него копий сломаны миллионы, а воз и ныне там.

Нет, не логично.

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

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

(3) Задачу вычисления процесса во времени (и управления им) ставим? Да, одна и та же задача в физической и информационной системе.

(4) Использовать универсальный вычислитель собираемся? Да. И там, и там.

(5) Параллельное вычисление функций (сигналов) есть? Есть.
Следовательно, функциональный подход использовать вполне целесообразно.
О чём и шла речь в моей первой записи в этой теме.

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


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



Ну все просто, как показывает опыт. Берем Дракон и загоняем "обмен веществ" под его стандарты. На это не нужен бюджет. Ну... Разве что 800 рублей на ИС Дракон.



DSL нельзя назвать эргономичным. Адекватным - только для узких специалистов.



AI затронули. ) Сейчас самая модная тема для стартапов в биржевой сфере. ) И знаете, на Дракон посматривают. Как на форму логики для AI. Я больше не могу сейчас сказать.



Вернусь к теме мобильного телефона - он тоже сплошная математика. Только вот тыкаешь в иконку с трубкой и появляется список звонков. Тыкаешь в кнопочку F и появляется фейсбук. Какая математика?... Вы о чем? ))) Я все таки в этом контексте упомяну тот факт, что Буран улетел в космос БЕЗ ПИЛОТОВ в далеком конце 20-го века. И все на Драконе.

Более того, Вы удалили важнейшую часть моего комментария. В двух словах я говорил о том, что матмодель сама по себе может быть декларативным кварком. Но все, что будут делать с ней потом - это АЛГОРИТМ.


[/quote]

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