Не соглашусь. Математически вы правы, но автомат в данном случае не столько математическая сущность сколько прагматичный подход к практическому созданию алгоритмов. Если честно, меня затруднило бы решить расписанный мной пример в виде машины Тьюринга )
Но программа реализует цифровое устройство, деление между программной частью и аппаратной частью условно, процессор микроконтроллера выполняющий программу это цифровой автомат. Просто чувствуется то что вы мыслите на другом уровне абстракции. Программирование микроконтроллеров специфическая сфера, мы разрабатываем именно цифровые устройства в самом что ни на есть прямом смысле,
Но операционный автомат — это логические устройство (алгоритм)
всё верно, логическое устройство выполняет ряд преобразований и функция Out_symbol выполняет те же преобразования которые у нас бы делали пара сдвиговых регистров в железе. Причём активно используются самые простые типы операций, и, или сдвиги, целочисленные операции, много однотипных вычислений, что оптимально для запуска на видео
процессорах на сколько я понимаю суть вопроса.
Грубо говоря, управляющий автомат в софтвере — это драйвер устройства.
да это верно, вы прекрасно поняли суть. И драйвер много работает именно с битами и байтами, именно на таком уровне как это показано в примере. Микроконтроллер содержит огромное количество готовых встроенных устройств — таймеры цап-ацп, приёмопередатчики, и там такой подход совершенно естественен.
— преобразовать входную строку в структуру данных, описывающую, что и куда рисовать
— передать эту структуру данных в рендер, который занимается отрисовкой
пожалуйста про входную строку в структуру данных, описывающую, что и куда рисовать подробнее, я кажется понимаю о чём вы пишите, но не уверен что не думаю о другом.
Я знаком с этим продуктом, если вы знакомы с этим продуктом и взвешенно оцените статью, увидите, здесь речь немного о разных вещах. Там реализация, а здесь сам смысл проектирования. На самом деле с реализацией проблем не возникает, я покажу разные способы. IAR Visual State это дополнение к тому что я говорю, а не антагонист
такую схему непросто переложить в код без внутреннего состояния
это в точку, но когда я написал
на самом деле Out_text_block реализована как обычный алгоритм
я немного слукавил. На самом деле в этой программе есть явно выделенные состояния. Они заданы метками Type_1 и т.д. Взгляните на этот вопрос математически, программа находится на участке между Type_1 и Type_2 только когда автомат в состоянии Тип 1, и так далее. Это однозначное соответствие. Представьте что вместо метки Type_1, у нас определена функция Type_1 и в программе есть указатель на функцию Current_state (переменная текущего состояния), а вместо операторов goto Type_2 используется конструкция Current_state = Type_2. Я обязательно рассмотрю этот аспект, он изначально заложен в замысел статьи.
Человеческий разум устроен так, что ему проще понимать алгоритмы, которым скармливают данные на входе и получают данные на выходе
в точку, во второй статье важное место уделено именно этому аспекту, надеюсь, вам будет действительно интересно,
код, невозможно понимать и дорабатывать без документации (к тому же, графической документации!) —
.
Дело в том что при таком подходе графическая документация в виде диаграммы состояний предшествует созданию программы, считайте что у вас всегда под рукой. Скажите а функция Out_text_block когда у вас есть диаграмма состояний, насколько понятна?
модификация такого кода может привести к пересмотру хранимого состояния, т.е. придется держать в уме весь код, который этим состоянием пользуется
я буду рассматривать модификацию этого кода и вы сможете оценить этот процесс
состояние перед началом работы нужно инициализировать — этот код тоже «хрупкий» и потребует частых доработок при внесении изменений в логику. А ошибки в нем приведут к сложным багам.
Такое опасение имеет право на существование, но так получилось что я использую автоматы много лет и во многих проектах, и могу вас уверить, что такая проблема в общем не стоит остро. Автоматный подход не просто требует более внимательного отношения к проектированию программы, он и является элементом внимательного проектирования программы.
Всё что вы пишите это важно, я постараюсь освещать эти моменты подробно, сейчас конечно в коментах это вкратце поэтому если что-то не понятно пожалуйста пишите, я отвечу развёрнуто второй статьёй.
Реализация графа состояний подозрительно напоминает генеренный код — быть может, её и правда можно генерировать по графу состояний?
Многолетняя практика. Автоматическая генерация не самоцель. Она требует слишком детальной проработки диаграммы состояний. Диаграмма состояний должна быть ясной и без излишеств, диаграмма состояний не блок-схема, чем понятней диаграмма состояний тем проще и совершенней код. То что моя программа напоминает генеренный код прямое следствие автоматного подхода — иначе просто и не сделать, автоматный подход сам наталкивает на такую реализацию. Но обратите внимание — схемы со сдвигами это тоже немаловажная часть. Повторюсь, такой подход сам наталкивает на такие реализации.
Программа, спроектированная как автомат, будет, конечно же, наиболее эффективной по цпу и памяти, но и наиболее сложной для понимания, так что, имхо, это только техника оптимизации, но не общая техника программирования
если я смогу своими статьями раскрыть внутреннюю простоту этого подхода я окажу огромную услугу программистам будущего )), все ваши вопросы закономерны, это твердыни которые словно какое то кривое зеркало искажает красоту и естественность автоматного подхода
Плюс вопрос, тоже важно ) обратили ли вы внимание что в статье делается акцент не на реализацию программы как автомата, а её проектирование, как автомата. И что на самом деле Out_text_block реализована как обычный алгоритм? Или я недостаточно акцентировал на этом внимание? Потому что в этом соль и есть, это не ещё один велосипед про UML/Boost/Statechart
Дело в том что диаграмма состояний строится не для иллюстрации кода а до его создания, поэтому в данном случае она в наличии обязательна.
ответьте пожалуйста на вопрос это важно для меня, если бы у вас перед глазами была диаграмма состояний рис 18 и соответствующий ей код,(и выкладки по сдвигам и прочее — это тоже рисуется до разработки исходника и хранится с ним) вам было бы сложно разобраться в нём и, например, внести дополнения, или чего-то не хватает ещё?
Спасибо за ваши замечания, мне важно видеть какие моменты вызывают недоумение у читателя, я с этого и начну следующую часть. Все состояния перечислены на соответствующих диаграммах, и в тексте даны их описания, просто я не хотел загромождать текст лишней информацией, но я могу добавить, приведите если не сложно, с какими именно состояниями у вас возникли сложности, возможно действительно не хватает описаний.
— весь код непосредственно иллюстрирует применение автоматного программирования для проектирования программ, а битовые сдвиги это неотъемлемая часть операционного автомата. И операционный автомат напрямую определяет то, каким будет управляющий автомат. Я верю что вы разбираетесь в автоматах состояний, но субъективно ощущается что знания у вас несколько из другой сферы, попробую объяснить. Судя по комментарию, для вас автомат это только то что непосредственно попадает под формальное определение по запросу C++ finite state machine lib, и до что вы никогда не сталкивались на деление автоматов на операционные и управляющие (может я ошибаюсь, не примите близко к сердцу) и таким образом ваше знание становится камнем преткновения: вы видите то что этот текст не повторяет то что вы привыкли слышать по этому вопросу и это вызывает подсознательную реакцию «что-то не то». Но поймите, автоматы более комплексная сфера знаний чем кажется на первый взгляд. Автоматы могут использоваться в частности для анализа символьных последовательностей и это тоже FSM, но автоматы это также и способ проектирования цифровых логических устройств, и это тоже автоматы, но акцент здесь на другое, и с этой точки зрения автомат это ряд технологических подходов. В статье я рассматриваю автомат именно с этой позиции, т.е. проектирование программного обьекта как цифрового устройства.
Потому что мой основной IDE это IAR а Builder 6 это то, чем я довольно хорошо владею для создания проектов для ПК. Я стал переносить пример на Qt но возникли сомнения в том что если не Qt то кто, и в то же время хотелось выложить статью здесь и сейчас, поэтому решил не заморачиваться. Спасибо вам за идею насчёт Builder 10 Starter Edition Free. Если можно пару слов — вы используете её? И как Starter Edition? Не мешает работе? У меня сейчас выбор между Qt и чем нибудь из Embarcadero, можете вкратце посоветовать его или отсоветовать?
К сожалению не получилось всё изложить в одной статье и в то же время хотелось сообщить читателям, что это не всё ), поэтому родилась такая фраза вводящая в заблуждение. Прошу не рассматривать её как указание на то что в этой статье нет описания преимуществ. Обзор подразумевает некую сводку преимуществ. А описание преимуществ уже содержитсяздесь, так как главное преимущество — проектирование программы, данная статья показывает процесс проектирования «вживую», насколько это возможно, как последовательность этапов. А как вы оцените описание самого процесса, вы могли проследить мою авторскую мысль, или где то были какие то непонятности?
Это и есть практика нас, обычных embedderов )). Этот модуль использован во множестве реальных проектов это краеугольный «кирпичик». И для курсовой это отличное задение, его можно использовать как тест на профпригодность, поэтому начинаю именно с него. Поэтому «бесконечно далеко» вызывает лишь искренне недоумение )))
Билдер в данном случае нужен для демонстрации работы модуля на ПК, сам модуль никак не завязан на Билдер, и использовался с другими IDE поэтому ваша критика как будто отчасти имеет почву но она немного мимо.
В дальнейшем я планирую давать примеры в Qt но этот пример было быстрее сделать так.
напишите подробнее пожалуйста, о какой маске идёт речь
Это не глобальные переменные, это члены класса Display, они общедоступны для функций членов и сокрыты для доступа извне.
всё верно, логическое устройство выполняет ряд преобразований и функция Out_symbol выполняет те же преобразования которые у нас бы делали пара сдвиговых регистров в железе. Причём активно используются самые простые типы операций, и, или сдвиги, целочисленные операции, много однотипных вычислений, что оптимально для запуска на видео
процессорах на сколько я понимаю суть вопроса.
да это верно, вы прекрасно поняли суть. И драйвер много работает именно с битами и байтами, именно на таком уровне как это показано в примере. Микроконтроллер содержит огромное количество готовых встроенных устройств — таймеры цап-ацп, приёмопередатчики, и там такой подход совершенно естественен.
пожалуйста про входную строку в структуру данных, описывающую, что и куда рисовать подробнее, я кажется понимаю о чём вы пишите, но не уверен что не думаю о другом.
это в точку, но когда я написал
я немного слукавил. На самом деле в этой программе есть явно выделенные состояния. Они заданы метками Type_1 и т.д. Взгляните на этот вопрос математически, программа находится на участке между Type_1 и Type_2 только когда автомат в состоянии Тип 1, и так далее. Это однозначное соответствие. Представьте что вместо метки Type_1, у нас определена функция Type_1 и в программе есть указатель на функцию Current_state (переменная текущего состояния), а вместо операторов goto Type_2 используется конструкция Current_state = Type_2. Я обязательно рассмотрю этот аспект, он изначально заложен в замысел статьи.
в точку, во второй статье важное место уделено именно этому аспекту, надеюсь, вам будет действительно интересно,
.
Дело в том что при таком подходе графическая документация в виде диаграммы состояний предшествует созданию программы, считайте что у вас всегда под рукой. Скажите а функция Out_text_block когда у вас есть диаграмма состояний, насколько понятна?
я буду рассматривать модификацию этого кода и вы сможете оценить этот процесс
Такое опасение имеет право на существование, но так получилось что я использую автоматы много лет и во многих проектах, и могу вас уверить, что такая проблема в общем не стоит остро. Автоматный подход не просто требует более внимательного отношения к проектированию программы, он и является элементом внимательного проектирования программы.
Всё что вы пишите это важно, я постараюсь освещать эти моменты подробно, сейчас конечно в коментах это вкратце поэтому если что-то не понятно пожалуйста пишите, я отвечу развёрнуто второй статьёй.
Многолетняя практика. Автоматическая генерация не самоцель. Она требует слишком детальной проработки диаграммы состояний. Диаграмма состояний должна быть ясной и без излишеств, диаграмма состояний не блок-схема, чем понятней диаграмма состояний тем проще и совершенней код. То что моя программа напоминает генеренный код прямое следствие автоматного подхода — иначе просто и не сделать, автоматный подход сам наталкивает на такую реализацию. Но обратите внимание — схемы со сдвигами это тоже немаловажная часть. Повторюсь, такой подход сам наталкивает на такие реализации.
если я смогу своими статьями раскрыть внутреннюю простоту этого подхода я окажу огромную услугу программистам будущего )), все ваши вопросы закономерны, это твердыни которые словно какое то кривое зеркало искажает красоту и естественность автоматного подхода
ответьте пожалуйста на вопрос это важно для меня, если бы у вас перед глазами была диаграмма состояний рис 18 и соответствующий ей код,(и выкладки по сдвигам и прочее — это тоже рисуется до разработки исходника и хранится с ним) вам было бы сложно разобраться в нём и, например, внести дополнения, или чего-то не хватает ещё?
— весь код непосредственно иллюстрирует применение автоматного программирования для проектирования программ, а битовые сдвиги это неотъемлемая часть операционного автомата. И операционный автомат напрямую определяет то, каким будет управляющий автомат. Я верю что вы разбираетесь в автоматах состояний, но субъективно ощущается что знания у вас несколько из другой сферы, попробую объяснить. Судя по комментарию, для вас автомат это только то что непосредственно попадает под формальное определение по запросу C++ finite state machine lib, и до что вы никогда не сталкивались на деление автоматов на операционные и управляющие (может я ошибаюсь, не примите близко к сердцу) и таким образом ваше знание становится камнем преткновения: вы видите то что этот текст не повторяет то что вы привыкли слышать по этому вопросу и это вызывает подсознательную реакцию «что-то не то». Но поймите, автоматы более комплексная сфера знаний чем кажется на первый взгляд. Автоматы могут использоваться в частности для анализа символьных последовательностей и это тоже FSM, но автоматы это также и способ проектирования цифровых логических устройств, и это тоже автоматы, но акцент здесь на другое, и с этой точки зрения автомат это ряд технологических подходов. В статье я рассматриваю автомат именно с этой позиции, т.е. проектирование программного обьекта как цифрового устройства.
Билдер в данном случае нужен для демонстрации работы модуля на ПК, сам модуль никак не завязан на Билдер, и использовался с другими IDE поэтому ваша критика как будто отчасти имеет почву но она немного мимо.
В дальнейшем я планирую давать примеры в Qt но этот пример было быстрее сделать так.