Это текст, которым я в процессе проектирования автомата описываю алгоритм, неформально но однозначно. А как полученную диаграмму состояний обратить в алгоритм, это уже вопрос освещённый.
там же сложность в том, что в одном случае стрелка означает одно, в другом другое. легко запутаться.
над стрелками однозначные подписи, это психологический аспект: это кажется непривычным и поэтому малопонимаемым вообще, но это не так
я учту то что Вы написали, я отвечу статьёй с картинками, так будет понятней.
мы же говорим об автоматной многозадачности? если вкрадце, то можно рассматривать автоматы как классы, обращение к которым идёт только через кольцевые буферы(каналы связи между процессами) которых может быть сколько угодно. Один автомат — один процесс. Не нужно составлять диаграмму состояний которая охватит все биты микроконтроллера — перечитайте раздел «Артефакты автоматной схемотехники», там же ответы на ваши вопросы, можно сказать, между строк. Но будет статья и я подчеркну этот факт, спасибо за интерес
Вот здесь как предугадал, что вы напишите про диаграммы состояний. нет единой диаграммы состояний — есть сообщество программ — автоматов и всё. обмен данными через буферы, синхронизация через флаги, никаких проблем
+ про часы я пожалуй сделаю пример
1. прерывания.
они плохо кладутся в диаграмму состояний.
это в общем дополнение к коменту выше — не составляется единый автомат всего программного процесса — всё разбивается на ряд подавтоматов, часть из которых висит в прерывании часть в фоне, обмен межу которыми через структуры данных — кольцевые буферы самый универсальный вариант
про часы интересный пример, я возможно использую его для иллюстрации
многопоточность. как её впихивать в состояния?
хороший вопрос. для обмена прерывание-фон активно используются кольцевые буферы для обмена данными. автоматы висят в прерываниях (как показано на рис 7 )
по мне, как пользователю подобных автоматов, нет особой разницы и те и те автоматы, просто для символьных одни условия, для функциональных другие. но само построение одинаково.
Позвольте пример — если даже не рассматривать тему символьных автоматов вообще, то автоматное программирование это удобный способ записи алгоритмов
Я как практикующий автоматный программист почти не составляю символьные, кроме как для примеров, но я могу при помощи диаграммы состояний записать алгоритм(автомат), который по заданному коду будет составлять таблицу(то есть автомат, которой строит другие автоматы) для распознавания любого кода. И вот те автоматы будут состоять из таблицы составленной компьютером, то есть речь не идёт об ошибках, которые может допустить человек а потом можно и не увидеть. Но быстродействие варианта к примеру для рис 12 не сравнится по быстродействию с быстродействием switch. Но если нет преимуществ, тогда зачем? Поясню, использование этой конструкции не противоречит автоматному программированию, но зачем?
Другое дело функциональные программные автоматы — их можно показать как пример 1 — пример 8 и среди них т.н. базовая конструктивная реализация самое то. Это из моей практике, могу подтвердить коллегам, что очень практичная в использовании и скоростная как я не знаю что.
*такую программу можно нужно реализовывать не через switсh, а через таблицы, это не только работает работает быстрее, но и:
*эти таблицы составляются автоматически, я приведу пример. Диаграмму состояний я нарисовал как пример. Для символьных автоматов диаграммы в процессе разработки не нужны. Я приведу программу, которая составляет таблицы
* автоматы распознающие коды, точнее определяющий один из нескольких возможных это интересная тема, у меня есть. Вообще символьным автоматам я собираюсь посвятить отдельную статью.
* диаграммы состояния составляются для функциональных автоматов. В этом случае диаграмма состояний замечательно описывает процесс. Например рисунок 3 в тексте статьи.
И позвольте задать Вам вопрос как читателю. Достаточно ли я провёл разделение автоматов на символьные и функциональные, или оно не выглядит столь фундаментальным? Дело в том, что я хочу направить внимание читателей на то, что акцент будет на функциональные автоматы и описание при помощи диаграммы состояний именно алгоритмов, а не символьных автоматов, которые получаются алгоритмически и хранятся в виде таблиц
«схема порождает код» — как изображено, ровно так и будет реализовано. а иначе зачем? не красоваться же.
Тогда поясните фразу
— то что если схема порождает код — значит ошибок на этом участке нет и всё точно,
у Вас не заметно 2 важных аспекта
— то что если схема порождает код — значит ошибок на этом участке нет и всё точно,
Не уверен, что правильно Вас понимаю, поясните пожалуйста что значит «схема порождает код»?
— то что схема позволяет строить более сложные переходы проще. на моей блок схеме добавлена буква Е.
И что получается, автомат который теперь определяет 2 кода: bacab и bacEb? Или пардон?
причина в том что автоматное программирование довольно нишевое, и не везде его можно и не всегда целесообразно применять
Если не попадать под влияние распространённых стереотипов, о которых рассказано в пункте «Артефакты автоматной схемотехники» автоматное программирование очень похоже на «естественное» программирование. Основное отличие — в проектировании. Я это буду демонстрировать на примерах.
list<T>::iterator I1 = list.begin();
list<T>::iterator I2 = list.begin();
I2++;
list<T>::iterator Istop = list.end();
while(I2 < Istop)
{
list.swap(I1, I2);
I1++; I1++;
I2++; I2++;
}
// Если количество элементов нечётное, меняем последний с первым
if(I1 < Istop)
{
list<T>::iterator I2 = list.begin();
list.swap(I1, I2);
}
в результате ни один элемент не останется на прежнем месте, да и закономерность будет нарушена. То что закономерность сохранится через 1 элемент — не противоречит условию задачи, там не сказано насколько должна быть нарушена закономерность. А может просто «развернуть» список концом вперёд и тогда закономерность снова не останется прежней, более того, она инвертируется? Задача недоформулирована, как будто подразумевается что речь пойдёт о перемешивании методом Монте-Карло, и студент выберет это решение как само собой разумеющееся. Для олимпиадной задачи эта очень куцая.
Интересное наблюдение. Может быть если сделать отверстия более регулярными — в виде сетки это будет не так страшно, поскольку
википедия:: После разговора с лицом, страдающим трипофобией, и наблюдая, как происходит подобная негативная реакция, показывая образы ядовитых животных, исследователи пришли к выводу, что эта фобия — это «бессознательная рефлекторная реакция» основанная в «примитивной части его мозга, которая связывает образ с чем-то опасным
История показывает, что «своих не бьют» не является железным правилом, а окончание школы КГБ не означает участие в какой-либо чекистской группировке. Не факт конечно, что с ним так поступят, может удастся убедить «поделиться» с ребятами, «настоящими чекистами» и не прибегая к расправе. В любом случае, он слишком жирный для того, чтобы чувствовать себя в безопасности.
Когда у них плохо пойдут дела, им компенсирует государство. Но не просто так, конечно же. Предполагаю, что не исключён такой вариант, что «Касперский» станет государственным или окологосударственным. А Евгения Касперского (не)жалко — в процессе «отжимания» его могут обвинить в чём угодно от порнографии до терроризма. Вопрос только в том, когда у окологосударственных рейдеров нагуляется аппетит на Каспера. Это не вангование, но тренд же в России именно такой.
это называлось не чекисты а ОБХСС а в остальном очень похоже на правду. видимо это не местные заскоки, как пишет автор выше, — такая удручающая атмосфера беспросветности и страха непонятно перед чем. а то что
в те годы был популярен принцип «тащи с работы каждый гвоздь»
это было не от желания нажиться нетрудовым путём, а от того, что реально всё было в дефиците.
над стрелками однозначные подписи, это психологический аспект: это кажется непривычным и поэтому малопонимаемым вообще, но это не так
я учту то что Вы написали, я отвечу статьёй с картинками, так будет понятней.
+ про часы я пожалуй сделаю пример
это в общем дополнение к коменту выше — не составляется единый автомат всего программного процесса — всё разбивается на ряд подавтоматов, часть из которых висит в прерывании часть в фоне, обмен межу которыми через структуры данных — кольцевые буферы самый универсальный вариант
хороший вопрос. для обмена прерывание-фон активно используются кольцевые буферы для обмена данными. автоматы висят в прерываниях (как показано на рис 7 )
Позвольте пример — если даже не рассматривать тему символьных автоматов вообще, то автоматное программирование это удобный способ записи алгоритмов
Я как практикующий автоматный программист почти не составляю символьные, кроме как для примеров, но я могу при помощи диаграммы состояний записать алгоритм(автомат), который по заданному коду будет составлять таблицу(то есть автомат, которой строит другие автоматы) для распознавания любого кода. И вот те автоматы будут состоять из таблицы составленной компьютером, то есть речь не идёт об ошибках, которые может допустить человек а потом можно и не увидеть. Но быстродействие варианта к примеру для рис 12 не сравнится по быстродействию с быстродействием switch. Но если нет преимуществ, тогда зачем? Поясню, использование этой конструкции не противоречит автоматному программированию, но зачем?
Другое дело функциональные программные автоматы — их можно показать как пример 1 — пример 8 и среди них т.н. базовая конструктивная реализация самое то. Это из моей практике, могу подтвердить коллегам, что очень практичная в использовании и скоростная как я не знаю что.
можнонужно реализовывать не через switсh, а через таблицы, это не только работает работает быстрее, но и:*эти таблицы составляются автоматически, я приведу пример. Диаграмму состояний я нарисовал как пример. Для символьных автоматов диаграммы в процессе разработки не нужны. Я приведу программу, которая составляет таблицы
* автоматы распознающие коды, точнее определяющий один из нескольких возможных это интересная тема, у меня есть. Вообще символьным автоматам я собираюсь посвятить отдельную статью.
* диаграммы состояния составляются для функциональных автоматов. В этом случае диаграмма состояний замечательно описывает процесс. Например рисунок 3 в тексте статьи.
И позвольте задать Вам вопрос как читателю. Достаточно ли я провёл разделение автоматов на символьные и функциональные, или оно не выглядит столь фундаментальным? Дело в том, что я хочу направить внимание читателей на то, что акцент будет на функциональные автоматы и описание при помощи диаграммы состояний именно алгоритмов, а не символьных автоматов, которые получаются алгоритмически и хранятся в виде таблиц
Тогда поясните фразу
лучше с примером
Не уверен, что правильно Вас понимаю, поясните пожалуйста что значит «схема порождает код»?
И что получается, автомат который теперь определяет 2 кода: bacab и bacEb? Или пардон?
Если не попадать под влияние распространённых стереотипов, о которых рассказано в пункте «Артефакты автоматной схемотехники» автоматное программирование очень похоже на «естественное» программирование. Основное отличие — в проектировании. Я это буду демонстрировать на примерах.
в результате ни один элемент не останется на прежнем месте, да и закономерность будет нарушена. То что закономерность сохранится через 1 элемент — не противоречит условию задачи, там не сказано насколько должна быть нарушена закономерность. А может просто «развернуть» список концом вперёд и тогда закономерность снова не останется прежней, более того, она инвертируется? Задача недоформулирована, как будто подразумевается что речь пойдёт о перемешивании методом Монте-Карло, и студент выберет это решение как само собой разумеющееся. Для олимпиадной задачи эта очень куцая.
Может быть для второго этапа 3d принтер и подойдёт? во время диспансеризации составлять 3d модель всего тела и печатать перед приходом пациента?