Comments 7
Спасибо за исследование, интересно.
Мне тоже в последнее время приходится реализовывать конечные автоматы. Главная проблема — это то, что программа не содержит описания набора состояний и переходов между ними в кратком и явном виде. Логика программы оказывается разбросанной по разным, слабо связанным между собой, частям. Вот эту бы проблему решить.
Мне тоже в последнее время приходится реализовывать конечные автоматы. Главная проблема — это то, что программа не содержит описания набора состояний и переходов между ними в кратком и явном виде. Логика программы оказывается разбросанной по разным, слабо связанным между собой, частям. Вот эту бы проблему решить.
Спасибо за фидбэк. Может быть я и реализую как-нибудь автомат, у которого логика будет сосредоточена в одной таблице состояний/событий. Проблема будет в том, что хочется всё уместить в одну таблицу, но в этом случае (особенно если код функций помещать в ту же самую таблицу, например, с помощью лямбд) таблица станет сильно разбухшей. Но сама тема мне интересна и, может быть я найду ещё какие-нибудь решения, пусть не идеальные, но годные в качестве какой-то «рыбы» для последующего применения. Тогда либо дополню эту статью, либо напишу новую.
В языках HDL конечные автоматы хорошо описывать :) В одном блоке вся логика переходов между состояниями, и в других блоках уже описание работы каждого состояния :)
Я почитаю, как описываются КА в System Verilog и поспрашиваю у коллег. Спасибо за наводку.
Ну, разве что для общего развития :) Для обычных процессоров все равно так не сделать как делается в HDL.
Мне было бы интересно узнать, можно ли придумать осмысленный способ комбинирования нескольких автоматов в один. При этом так, чтоб это было не ручное комбинирование, а какое-то формально-логическое, т.е, допустим, есть у нас автомат А1 (с состояниями а, б, в) и автомат А2( с состояниями г, д). Есть разные способы комбинирования этих автоматов (прямое произведение состояний, расширение одного из состояний одного автомата состояниями другого автомата, использование одного автомата в качестве планировщика, а второго — в качестве планируемой программы и т.д.). Возможно, можно придумать что-то типа алгебры автоматов (или она уже придумана), т.е. задать несколько операций на множестве автоматов, позволяющих получать новые осмысленные автоматы из имеющихся. Если можно, тогда можно было бы даже сделать что-то типа языка программирования на основе автоматов: т.е. вместо функций или классов в нём определялись бы разные автоматы, автоматы, использующие другие автоматы и т.д… вся программа была бы одним большим автоматом. Не знаю, насколько этот подход мог бы быть плодотворным, но просто интересно было бы попробовать.
Sign up to leave a comment.
Лаконичная реализация конечных автоматов в Matlab, Octave, C