DRAKON.SU

Текущее время: Вторник, 19 Июнь, 2018 07:36

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 112 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 15 Февраль, 2018 00:09 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 151
TAU писал(а):
ВРЕМЯ - это СУТЬ изменений. А вовсе не "изменяющийся сигнал". Принципиально невозможно ввести время всего лишь как еще одну из "входных" переменных. Знаете, почему? Потому что в управляющем алгоритме семантически важно место, в котором находится с точки зрения его логики, ...


Цитировать Wikipedia это хорошо, но можно какую-нибудь цитату, где говорилось бы про то, что "время принципиально невозможно ввести"? Ну или что-нибудь на эту тему?

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

Собственно, цитата (которую TAU уже приводил
Wikipedia писал(а):
However, external input and output communication of real computers, which enable interactivity, cannot be modeled by a Turing machine. This is, because a Turing machine requires all input available initially on its tape, no further input or change of input during the course of computation is possible.


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

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

Я предполагал, что операции ввода-вывода мы всё-таки рассматриваем (говорим не о простой-простой МТ, а о каком-нибудь её расширении, где всё-таки допустимы операции ввода-вывода), и утверждение TAU относилось к тому, что "управляющие" алгоритмы какие-то особенные и время это прямо что-то совсем уникальное. Но тут у TAU ошибка. Уникально НЕ время, а IO.

---


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


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

Во-первых, там написано не о "принципиальной разнице", а о возможном делении. Можно выделить, а можно и не выделять. Семантика может отличаться, а может и не отличаться.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 09:31 

Зарегистрирован: Суббота, 16 Февраль, 2008 07:58
Сообщения: 230
Откуда: Россия, Стерлитамак
Любопытный спор. Вроде понятны обе позиции, но "чья взяла", не понятно.

Владимир Ситников писал(а):
Уникально НЕ время, а IO.


А возможно IO без времени? Как Вы себе это представляете? Все входы и выходы одновременно срабатывают?

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

Может действительно, в упр. алгоритмах важно не само время, а взаимодействие и время, как его какая-то составляющая?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 09:34 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3695
Откуда: Москва
От модератора

К оппоненту следует относиться с уважением, даже если он, по вашему мнению, допускает ошибки.

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

Критиковать надо не оппонента, а излагаемые им аргументы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 09:52 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 151
..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 10:01 

Зарегистрирован: Среда, 03 Май, 2017 09:55
Сообщения: 151
adva писал(а):
А возможно IO без времени? Как Вы себе это представляете? Все входы и выходы одновременно срабатывают?
Например: https://en.wikipedia.org/wiki/Turing_ma ... o-machines
Т.е. в отличие от простой машины, C или O машина просто тупо остановится и будет ждать пинка для продолжения.

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

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

Есть ли великий смысл в том, чтобы разделять "задачи на движение" и "задачи на проценты"? Вопрос риторический.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 14:10 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
TAU писал(а):
если программа на Хаскелле обменивается информацией с внешним миром в ходе своего выполнения - она выходит за рамки чистого функционального программирования и "вычислимости по Тьюрингу".
Перечисленные аспекты формальных моделей не имеют практической ценности для разработчиков алгоритмов!
Сами по себе эти модели имеют право на существование, но не являются адекватным инструментом для нас. О чём тогда весь спор?

Цитата:
3. ВРЕМЯ - это СУТЬ изменений. А вовсе не "изменяющийся сигнал". Принципиально невозможно ввести время всего лишь как еще одну из "входных" переменных.
Это именно изменяющийся ВНЕШНИЙ сигнал. Который программа ВСЕГДА получает из внешних источников (таймеры, часы реального времени, счётчик тиков процессора).

Цитата:
Потому что в управляющем алгоритме семантически важно место, в котором находится с точки зрения его логики, "фокус выполнения" в данный момент времени
Нет, не важно. Важно другое:
Цитата:
его выполнение должно быть синхронизировано с внешними для него, протекающими в объекте управления, процессами.
Теперь смотрите, как эта синхронизация достигается.
А именно, в 99,999% случаев она достигается через перечисленные выше внешние источники. То есть, по существу, через ввод/вывод.
Стало быть, время с алгоритмической точки зрения - это именно входной сигнал, ничего более.

Цитата:
ПРОЦЕСС - это НЕ ФУНКЦИЯ.
Конечно, нет. Для чего это тривиальное утверждение?
Функция используется для преобразования процессов.

Цитата:
Функция от набора текущих значений входных параметров и предыдущей истории состояний - это по смыслу совсем не то, что "просто" функция в обычном понимании, вне времени и истории отображающая элементы множества А в элементы множества Б. Вот эта самая предыдущая история состояний - она должна включать предысторию развития процессов в объекте, которым управляем, и выполнения самого управляющего алгоритма - корень различия.
"Вся предыдущая история" объекта управления не просто не важна, она ещё и недоступна - иначе чем через вектор входных сигналов X.
А история самого алгоритма полностью и однозначно формирует его пространство состояний S, и именно из него вычисляется следующее состояние.
Поэтому имеем именно "отображение элементов множества А в элементы множества Б". Причём однозначное. То есть не что иное, как функцию.


Цитата:
Математической основой всего перечисленного, как правило, служат графовые модели - системы переходов (конечные автоматы, сети Петри).
Графы - да, но они отнюдь не сводятся к сетям Петри и даже к конечным автоматам.
Например, графами описываются дифференциальные уравнения, которые в управляющих алгоритмах играют отнюдь не последнюю роль. :wink:

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


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


Владимир Ситников писал(а):
Есть ли великий смысл в том, чтобы разделять "задачи на движение" и "задачи на проценты"? Вопрос риторический.
Вот-вот! :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 15:51 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 461
TAU писал(а):
Позвольте мне)

Спасибо за ссылки!

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

Спасибо за внятное объяснение.

Итак, позиции в споре у нас следующие:
Владимир Ситников:
1. Качественных отличий управляющих от вычислительных алгоритмов нет.
2. Управляющий алгоритм — это обычная функция, которая имеет время в качестве одного из параметров.

TAU:
1. Качественные отличия управляющих от вычислительных алгоритмов есть.
2. Управляющий алгоритм не может быть сведён к функции, потому что:
- Огромную роль играет вывод (воздействие на объект управления).
- Входом управляющего алгоритма является (кроме входных данных) ещё и предыдущая история состояний.
(иными словами, время — это не столько значение функции time(), сколько последовательность событий)

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

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

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

1. Искусственное разделение управляющего алгоритма на функциональную и "грязную нефункциональную" части критически важно для надёжности.
Чтобы такое разделение грамотно провести, нужно сначала понять, что имеешь дело с управляющим алгоритмом.
Это ужас как важно! Ракеты не должны падать, игры не должны вылетать, виндовс с линуксом не должны получать по новой уязвимости в неделю.

2. Значительная часть программного кода, с которым я работаю — обёртки вокруг алгоритмов управления.
Если бы средства разработки рассматривали управляющие алгоритмы как первоклассные сущности, меня и моих коллег на 90% мог бы заменить кодогенератор.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 18:00 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
Степан Митькин писал(а):
1. Качественные отличия управляющих от вычислительных алгоритмов есть.
Есть. Но не настолько принципиальные, чтобы вокруг них весь этот огород городить.

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

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

Цитата:
(иными словами, время — это не столько значение функции time(), сколько последовательность событий)
Несущественно.

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

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

Цитата:
1. Искусственное разделение управляющего алгоритма на функциональную и "грязную нефункциональную" части критически важно для надёжности.
Чтобы такое разделение грамотно провести, нужно сначала понять, что имеешь дело с управляющим алгоритмом.
Это ужас как важно! Ракеты не должны падать, игры не должны вылетать, виндовс с линуксом не должны получать по новой уязвимости в неделю.
Вы вот это серьёзно сейчас написали?!
Вы серьёзно думаете, что ракеты падают из-за того, что кто-то не понимает, как писать управляющий алгоритм?! Или забыл "выделить функциональную часть"?!
Ну, тут никаких фейспалмов не хватит...

Цитата:
2. Значительная часть программного кода, с которым я работаю — обёртки вокруг алгоритмов управления.
Если бы средства разработки рассматривали управляющие алгоритмы как первоклассные сущности, меня и моих коллег на 90% мог бы заменить кодогенератор.
А какой из этого следует вывод, что ж не продолжаете?
Он простой: если 90% занимаются бесполезным делом, значит, в подразумеваемой вами области программирования творится полный и форменный бардак.
Вот с этим, пожалуй, можно и согласиться. :(


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 19:55 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 461
Alexey_Donskoy писал(а):
Вы серьёзно думаете, что ракеты падают из-за того, что кто-то не понимает, как писать управляющий алгоритм?! Или забыл "выделить функциональную часть"?!

Серьёзно. Я сам ракетного кода отродясь не видал. Но я видел много другого кода.
Мой вывод: все компьютерные программы одинаковые. Понты у программистов разные, а суть софта везде одна.

Насчёт сложности тестирования алгоритмов управления. Возьмём пример из мирной отрасли, из финансов.
Изучаю серверный код, мой коллега Пётр мне терпеливо объясняет: "Вот тут мы ждём снэпшоты. Когда снэпшот приходит, мы подписываемся. Когда все снэпшоты пришли, мы шлём первый апдейт."
Возникают вопросы: А если снэпшот битый придёт? А если пользователь откажется от всего до завершения процесса?
А если какой-то из снэпшотов не придёт вообще? А если в это время другой пользователь придёт?
А если рестарт фида? А если-если-если... и т.п. Простой пример, а вопросов много.
Очень хрупкий софт. Что делать?
1. Осознать, что имеешь дело с алгоритмом управления. Это самое сложное.
2. Выявить типы принимаемых сигналов, состояния, объект управления.
3. Применять соответствующие приёмы программирования.
4. Применять соответствующие приёмы тестирования.

А если человек знает только классы да юнит-тесты - добра не жди. Всё будет как всегда.

Alexey_Donskoy писал(а):
Он простой: если 90% занимаются бесполезным делом, значит, в подразумеваемой вами области программирования творится полный и форменный бардак.

Здесь у меня с вами полное согласие.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 20:51 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
Степан Митькин писал(а):
Alexey_Donskoy писал(а):
Вы серьёзно думаете, что ракеты падают из-за того, что кто-то не понимает, как писать управляющий алгоритм?! Или забыл "выделить функциональную часть"?!
Серьёзно.
Ну очень напрасно.
Вот же только недавно обсуждали: viewtopic.php?p=101181#p101181
Целый комплекс причин, включая неочевидные ошибки матмодели...

Цитата:
Мой вывод: все компьютерные программы одинаковые.
Если бы это было так, не было бы данного сайта и сообщества! ;)
Даже чисто с точки зрения синтаксиса - одни языки требуют более точного мышления, дисциплинируют и уменьшают вероятность ошибок, а другие просто провоцируют их.

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

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

Цитата:
1. Осознать, что имеешь дело с алгоритмом управления. Это самое сложное.
Это как раз элементарный, базовый навык.
Это вопрос профпригодности, в конце концов.

Цитата:
2. Выявить типы принимаемых сигналов, состояния, объект управления.
Да. Это рутинный технический вопрос.

Цитата:
3. Применять соответствующие приёмы программирования.
Их не так много, кстати.

Цитата:
4. Применять соответствующие приёмы тестирования.
С этим гораздо хуже. Я таки с трудом представляю комплекс для адекватного тестирования того же ракетного софта. И да, он вполне может оказаться намного сложнее и дороже самого тестируемого софта.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 23:16 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Цитата:
Я таки с трудом представляю комплекс для адекватного тестирования того же ракетного софта. И да, он вполне может оказаться намного сложнее и дороже самого тестируемого софта

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

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

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

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

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

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

Для более подробного ознакомления могу рекомендовать книги под редакцией Сырова и Микрина.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 23:18 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Степан Митькин писал(а):
Я сам ракетного кода отродясь не видал

Степан, в Вашей статье на Хабре о Драконе есть пример, тксккзть, "ракетного кода" :wink: .


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 15 Февраль, 2018 23:25 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Степан Митькин писал(а):
Математический энтузиаст может сказать:
Из управляющего алгоритма можно выделить функцию:
Она будет принимать:
1. Входные данные, включая текущее значение времени.
2. Внутреннее состояние, включая историю предыдущих состояний.
Она будет возвращать:
1. Описание воздействий на объект управления.
2. Новое состояние.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Февраль, 2018 00:50 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
TAU писал(а):
Ну что же, небольшой ликбез (хотя для некоторых он и бесполезен, у медиков есть диагноз "необучаемость" - но форум же читают и другие люди...).
Знаете, уважаемый, вы конкретно уже достали. Вместе с очень правильными и полезными вещами вам случается ляпнуть несусветную псевдоакадемическую чушь - так воспринимайте критику конструктивно, а не занимайтесь вместо этого оскорблениями. Всё ж таки люди читают.

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

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

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

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Февраль, 2018 08:00 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 74
С грустью я смотрел на эту замечательную дискуссию и не хотел вмешиваться.
Еще в студенчестве, в 1968г., писал философский реферат "О понятии алгоритма".

В журнале "Программная инженерия" Т. 7, № 12, 2016. — С. 531–538
есть моя статья на эту тему:
Классификация программ, ориентированная на технологию программирования.

Может быть, мой материал хоть как-то поможет.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Февраль, 2018 10:12 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
Владимир Шелехов писал(а):
философский реферат "О понятии алгоритма".
:D

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

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

Цитата:
Программа принадлежит (к классу программ-функций), если она не взаимодействует с внешним окружением; точнее, если возможно перестроить программу таким образом, чтобы все операторы ввода данных находились в начале программы, а весь вывод собран в конце программы. Если подобная перестройка программы принципиально невозможна, ее следует пытаться определять в виде реактивной системы.
Логично.
Маленькое замечание: в больших расчётных задачах взаимодействие с окружением хотя и не является теоретически необходимым, но часто бывает нужным практически. Строго говоря, даже кнопка "Старт", нажимаемая пользователем после ввода исходных данных в форме, уже переводит программу в другой класс! :wink: А ещё есть прогрессбары, взаимодействие с ОС (например, ProcessEvents), конпка "Стоп", реализация пошагового режима с визуализацией промежуточных состояний расчёта и т.д. и т.п.
Не говоря уж о том, что любое GUI-приложение (не консольное!) под Windows уже по определению строится как реактивная система. :wink:

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

Цитата:
Инварианты реактивных систем принципиально отличаются от инвариантов циклов и инвариантов классов императивных программ.
Упс. И здесь "принципиальное отличие" вылезло! Неплохо бы конкретизировать критерии.

Цитата:
Автоматическая вычислимость является неотъемлемым свойством программы.
Соглашусь.
Только добавлю, что алгоритм, вообще говоря, тоже обладает этим свойством! :wink:


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Февраль, 2018 13:58 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 174
Имхо, А.Д. Закревский адекватно представил исторически сложившееся представление об отличии вычислительных и управляющих алгоритмов -- см. начальные страницы в выдержке по ссылке:
https://forum.oberoncore.ru/viewtopic.php?p=77233#p77233

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Февраль, 2018 14:55 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 951
Откуда: Россия, Чебоксары
PSV100 писал(а):
отражает границу отличения в "репертуаре" исполнителя -- операцию "ожидания"
Вообще-то исполнитель может и не иметь аппаратной операции ожидания - тогда её приходится реализовывать программно.
Так что по сути ничего не меняется - принципиальной разницы нет.
В структуре алгоритма - разница, безусловно, есть. Но это тривиальный технический вопрос реализации, не более того...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Февраль, 2018 18:13 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 174
Alexey_Donskoy писал(а):
PSV100 писал(а):
отражает границу отличения в "репертуаре" исполнителя -- операцию "ожидания"
Вообще-то исполнитель может и не иметь аппаратной операции ожидания - тогда её приходится реализовывать программно.
Так что по сути ничего не меняется - принципиальной разницы нет.
В структуре алгоритма - разница, безусловно, есть. Но это тривиальный технический вопрос реализации, не более того...

Но почему же нет разницы? Это и есть та разница, на которую вы указывали (но без конкретики в том случае):
Alexey_Donskoy писал(а):
TAU писал(а):
могут описываться не только вычислительные алгоритмы. А, например, управляющие

Чем одно от другого отличается? Только исполнителем.

Вы эту разницу не считаете "принципиальной". Да, фактически, можно сказать, что имеющаяся в литературе (или в IT в целом) классификация алгоритмики и есть уточнение частных случаев общей формулы, вами ранее указанной: S[n+1]=f(X[n],S[n]).
Однако, к примеру, выше Владимир Шелехов представил свою статью о классификации программ. В дополнение, он же первично глобально выделяет или разделяет программирование на логическое и прочее:
http://forum.drakon.su/viewtopic.php?f=140&t=5581&p=100107#p100122

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

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

2) операции действий (последовательность, выбор, повтор или циклы/рекурсии) раскладываются и во времени.

И базовая операция "ожидание" есть основа для пунктов выше (вне зависимости от природы исполнителя и реализации операции).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Февраль, 2018 19:25 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 336
Alexey_Donskoy писал(а):
Знаете, уважаемый, вы конкретно уже достали. Вместе с очень правильными и полезными вещами вам случается ляпнуть несусветную псевдоакадемическую чушь - так воспринимайте критику конструктивно, а не занимайтесь вместо этого оскорблениями

Попробуйте воспринять конструктивно - а не переходя на личности оборотами вроде "детский сад" - то, что вам пытаются сказать здесь уже не я один, а множество людей:

Время - не просто "еще один аргумент в векторе входных параметров". ПРОЦЕСС - это не "мгновенно, вне времени" вычисляемая ФУНКЦИЯ.

И это не "псевдоакадемическая чушь" - а истина. К коей я пытаюсь по мере сил стремиться.

Отличия эти вполне принципиальны, на что указывал еще сам Тьюринг, описавший "машину выбора"
Цитата:
(choice machine)
whose motion is only partially determined by the configuration ... When such a machine reaches one of these ambiguous configurations, it cannot go on until some arbitrary choice has been made by an external operator

дополнительно к своей исходной модели алгоритма, а вовсе не "тривиальная техническая вещь".

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

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


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 112 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2018, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB