При замыкании кнопки, диод включается на 4 секунды и выключается. Цикл остановился, кнопка замкнута, диод не горит. Ждем размыкания кнопки.
При размыкании кнопки происходит тоже самое- диод включается на 4 секунды и отключается. Цикл остановился, кнопка разомкнута, диод не горит. Ждем замыкания кнопки.
=================================
...Сперва определим состояния автомата...
Исходное состояние: кнопка разомкнута, светодиод не горит, обозначим А.
Дальше - только по нажатию кнопки переходим в стостояние В - кнопка включена, светодиод - тоже.
Теперь зависит от того, что наступило раньше - отпускание кнопки или таймаут. Если таймаут - состояние С - ждем отпускания кнопки.
Если кнопка - в ТЗ этот вариант отсутствует, так что возможны варианты:
- состояние D - светодиод продолжает гореть, но таймаут либо обновляется, либо - нет.
- состояние Е - светодиод гаснет.
В принципе можно считать состоянгие Е равным состоянгию А, но в общем случае это неверно. Например, состояние Е может быть "Ошибка", когда мы перестаем реагировать на кнопку. И это - не единственный альтернативный вариант.
Вернемся к состоянию D. Если мы дождались таймаута, светодиод, видимо, следует погасить, а нам перейти в состояние либо А, либо Е. А если кнопку вновь нажали, то... мы ведь знаем, что бывает не только одиночный щелчок мышью, но и двойной... и никто не запрешает 3-ний или 60-ной. В общем, если кнопку вновь нажали до наступления таймаута, неизбежно появляется состояние F. И каждый раз, когда кнопка будет нажиматься или отпускаться до достижения таймаута, это будет приводить к очередному новому состоянию.
В общем получается, что если ТЗ сформулировано некорректно, то это ведет к увеличению таблицы состояний до бесконечности.
Нет, это у светодиода состояния два, а у системы, состоящей из кнопки, светодиода и таймаута, состояний гораздо больше - вплоть до бесконечности, как показано постом выше.
Нет, это у светодиода состояния два, а у системы, состоящей из кнопки, светодиода и таймаута, состояний гораздо больше - вплоть до бесконечности, как показано постом выше.
пост выше показывает только. что вы склонны додумывать условия задачи, а это может завести далеко :)
Мой вариант максимально прост и ПОЛНОСТЬЮ соответвует начальной формулировке ТЗ, думаю Влад не откажется подтвердить.
Это здоровая стремление взрослого человека к упрощению! ;) При этом удовлетворяются написанные условия задачи, а "хрустальный шар", как обычно - в ломбарде.
Но, к сожалению, уже редуцированное решение не иллюстрирует главного - запоминание в номере состояния всех составляющих. Поэтому я буду считать, что естественным дополнением к условиям автора является тривиальная реакция на кнопку, а именно - если отпущена раньше таймаута - гаснет, если нажата раньше таймаута - перезапуск на 4 сек.
Как там было? "здоровая стремление взрослого человека к упрощению!"?
Если мы при любой операции с кнопкой автоматически будем забывать состояние таймаута, двойной щелчок нам не реализовать. Никак. А он - есть!
Цитата:
Так мы проиллюстрируем основы проектирования автоматов.
Итак у нас два компонента системы - диод и кнопка. Каждый может быть в двух состояниях, произведение этих множеств и есть множество состояний системы:
где вы видите в ТЗ задание реализовать двойной щелчок?
Он не противоречит ТЗ. Не надо выдумывать дополнительных ограничений, которых в ТЗ не было. Реакция на отпускание кнопки до истечения таймаута в ТЗ не прописана. Значит, при анализе необходимо предусмотреть все возможные варианты. Если мы этого не сделаем, а решим как-то дополнить ТЗ собственными предположениями, запросто может оказаться, что после уточнения ТЗ со стороны "заказчика" вся наша конструкция окажется противоречащей последней версии ТЗ.
И еще один момент: попытка предусмотреть все варианты неизбежно приведет нас к обнаружению любой ошибки в ТЗ, если она там имеется. А вводя дополнительные ограничения, не обозначенные "заказчиком", мы рискуем либо не обнаружить ошибок, либо обнаружить их слишком поздно.
Мой вариант максимально прост и ПОЛНОСТЬЮ соответвует начальной формулировке ТЗ, думаю Влад не откажется подтвердить.
Влад в посте №42 это уже опроверг.
ну хорошо, я не собираюсь устраивать тут битву в стиле Архата. Если Влад захочет, он скажет сам.
Мое ИМХО, что ваш разбор автомата далек от начальных условий, и главное - совершенно лишен той простоты и ясности, ради которой собственно и используются КА в программах.
Не надо выдумывать дополнительных ограничений, которых в ТЗ не было. Реакция на отпускание кнопки до истечения таймаута в ТЗ не прописана. Значит...
могу только ответить вашими же словами - "не надо выдумывать того, что не было в ТЗ". Если "Реакция на отпускание кнопки до истечения таймаута в ТЗ не прописана." - значит никакой реакции выдумывать не нужно.
Ув. Андриано! Я где-то написал, что нуждаюсь в комментировании?
Смотри - если ты хочешь задать вопрос: "А как быть с таймером?" , то вопрос законный, и ты не стесняйся - задавай! (ниже - ответ)
Ты ведь сам, несколькими постами выше про "автоматы Андриано" написал, что не имеешь квалификации для комментирования? Хочешь ее получить - я открыт, просто слушай, читай, учись. Хочешь ставить под сомнение мою квалификацию? - не нужно, я ведь не навязываю тебе ничего.
-----------------------------
По формальным признакам, автоматы с перезапускаемым таймером не являются КА. Именно потому, что перезапускаемый таймер - это аналог памяти. Поскольку ограничения на разрешение таймера не наложены, такой автомат перестает быть конечным.
В целях настоящего исследования, мы будем игнорировать эту неопределенность. Метод игнорирования - таймер не имеет дробных значений, время у нас квантуется только интервалами таймера. Таким образом мы сохраняем конечность количества состояний.
При програмирование у нас не стоит задача точно придерживаться модели КА. Использовать наработанные методы КА, использовать некоторые доказанные факты про КА - это очень полезно и удобно. Но искуственно заставлять себя "бегать в мешке" - увольте. Важно уметь почувствовать грань, когда мы еще КА, а когда уже "машина Тьюринга". ;)
Евгений, пошу прощения за оффтоп (можно выпилить этот пост), но дабы пресечь возможные нападки Великого и Ужасного Чма - хочу сказать вам и Деду Семёну огромную спасибу за то, что помогли взглянуть на ситуацию со стороны, и не принимать безоткатных, скажем так, решений. Поэтому - немного остыл, и решил продолжать наслаждаться (без шуток) приятной компанией. Спасибо вам за участие ;)
Евгений, пошу прощения за оффтоп (можно выпилить этот пост), но дабы пресечь возможные нападки Великого и Ужасного Чма - хочу сказать вам и Деду Семёну огромную спасибу за то, что помогли взглянуть на ситуацию со стороны, и не принимать безоткатных, скажем так, решений. Поэтому - немного остыл, и решил продолжать наслаждаться (без шуток) приятной компанией. Спасибо вам за участие ;)
Евгений, пошу прощения за оффтоп (можно выпилить этот пост), но дабы пресечь возможные нападки Великого и Ужасного Чма - хочу сказать вам и Деду Семёну огромную спасибу за то, что помогли взглянуть на ситуацию со стороны, и не принимать безоткатных, скажем так, решений. Поэтому - немного остыл, и решил продолжать наслаждаться (без шуток) приятной компанией. Спасибо вам за участие ;)
С возвращением, а Великий пока ушел.
но обещал вернуться :D:D если будем плохо себя вести и не кушать кашку
Хочешь ее получить - я открыт, просто слушай, читай, учись. Хочешь ставить под сомнение мою квалификацию? - не нужно, я ведь не навязываю тебе ничего.
Я весь во внимании и тщательно конспектирую.
Итак, для того, чтобы откомментировать пост на форуме, жизненно необходимо:
1. Письменное заявление комментируемого (желательно - в трех экземплярах) о том, что он нуждается в комментировании.
2. Справка установленного образца о том, что комментирующий обладает квалификацией для комментирования.
3...
А огласите весь список, пожалуйста.
И - да, я нисколько не сомневаюсь в твоей квалификации. Но по моим наблюдениям, некоторые из людей с очень высокой квалификацией страдают от убеждения в собственной непогрешимости. Вот так - людей. А человеку свойственно - что?
Цитата:
По формальным признакам, автоматы с перезапускаемым таймером не являются КА. Именно потому, что перезапускаемый таймер - это аналог памяти. Поскольку ограничения на разрешение таймера не наложены, такой автомат перестает быть конечным.
В целях настоящего исследования, мы будем игнорировать эту неопределенность. Метод игнорирования - таймер не имеет дробных значений, время у нас квантуется только интервалами таймера. Таким образом мы сохраняем конечность количества состояний.
А я было уже испугался. Ожидал примерно следующего: "Сейчас для иллюстрации решим одну задачку. Но в задачке - таймер, а таймеры выходят за пределы концепции КА, поэтому мы будем решать совершенно другую задачу..." Но, слава Богу, этого не случилось.
А по поводу "бесконечности" автомата с перезапускаемым таймером - я с ходу не могу сообразить, почему. Я немного подумаю, и если не справлюсь, спрошу позже. На первый взгляд кажется, что если у таймера есть конечный набор интервалов, то, даже если эти интервалы не квантуются, а находятся между собой в иррациональном соотношении, автомат не должен становиться бесконечным.
Евгений, пошу прощения за оффтоп (можно выпилить этот пост), но дабы пресечь возможные нападки Великого и Ужасного Чма - хочу сказать вам и Деду Семёну огромную спасибу за то, что помогли взглянуть на ситуацию со стороны, и не принимать безоткатных, скажем так, решений. Поэтому - немного остыл, и решил продолжать наслаждаться (без шуток) приятной компанией. Спасибо вам за участие ;)
Я тоже поздравляю с возвращением!
Тем более, что ... ну не надо все принимать так близко к сердцу. Не стоит оно того.
Тем более - расставаться с приятной компанией из-за одного не очень приятного человека. ;)
Мы не в школе и ты не "неудобный мальчик с вопросами". Бесконечное число состояний получается потому, что между любыми двуми числами есть бесконечно много других регулярных (которые можно решить конечным автоматом) чисел. Память бесконечна - автомат бесконечен. Поэтому вводим квантование, чтобы память сделать конечной.
Хочешь учиться - учись. Я указал базис. Если готов - я буду терпеливо читать лекции по математике, теории множеств, теории доказательтств и пр. и пр., если цель настоящего раздела - только КА в прикладном значении, то много придется принять на веру.
...Каюсь, я забыл в какой области ты специалист, поэтому "зеркальный" пример не смогу придумать. Но фраза "я немного подумаю и решу" - она несколько странная. Еще раз, рамки изложения требуют многое принимать на веру. Иначе мы застрянем в деталях и никуда не продвинемся.
--------------------
Сейчас интереснее обсудить именно "слияние" автоматов. Потому, что простейший "антидребезг" - это тоже КА, он выдает готовые события кнопки, которые мы используем в """главном" автомате. А еще, наприме, даллас: в основном автомате используем температуру, а получаем ее в служебном автомате, реализующим протокол.
мне кажется, Вы в третьей строчке таблицы упустили реакцию на истечение таймера? И еще - ну это просто придирки... вы пишете, что последний элемент структуры - ссылка на следующий, а по вашей записи получается. что на предыдущий... или в этом есть какой-то тайный смысл?
Что касается получившихся структур SSolution - их число и смысл подозрительно напоминают те состояния, что я получил вчера, преобразуя автоматы. Ведь в итоге, фактически, у вас получился автомат Мура - верно? Вот боюсь, опять скажете, что я не прав....
Сейчас интереснее обсудить именно "слияние" автоматов. Потому, что простейший "антидребезг" - это тоже КА, он выдает готовые события кнопки, которые мы используем в """главном" автомате. А еще, наприме, даллас: в основном автомате используем температуру, а получаем ее в служебном автомате, реализующим протокол.
мне так и хочется написать - "а чего тут обсуждать?" :)
Ну вот у меня в текущем проекте есть основной автомат и есть кнопки. Автомат кнопок читает состояние кнопки, отрабатывет задержку антидребезга, потом оценивает время нажатия, чтобы отличить короткое от длинного. По результатам работы он выставляет флаги Clicked() или Holded() . А в "главном автомате" те состояния, в которых учитываются сигналы кнопок - просто читают эти флаги и сбрасывают после прочтения.
И с температурой. в общем-то, так же. Понадобиоась температура - скинули запрос автомату Далласа. Когда тот готов выдать значение - он ставит флаг и копирует температуру в "регистр". Основной автомат видит флаг и забирает значение.
Вы в третьей строчке таблицы упустили реакцию на истечение таймера?
Так и есть.
b707 пишет:
вы пишете, что последний элемент структуры - ссылка на следующий, а по вашей записи получается. что на предыдущий... или в этом есть какой-то тайный смысл?
Ну, я же не могу ссылаться на имя, которое ещё не определено. Компилятор не поймёт. Потому здесь списки записываются "снизу вверх".
b707 пишет:
Что касается получившихся структур SSolution - их число и смысл подозрительно напоминают те состояния, что я получил вчера, преобразуя автоматы. Ведь в итоге, фактически, у вас получился автомат Мура - верно?
да, нет. Количество структур точно соотетствует количеству непустых ячеек таблицы (если исправить ошибку, которую Вы заметили). В каждлой структуре содержатся вход, выход и новое состояние - типичный автомат Мили.
В каждлой структуре содержатся вход, выход и новое состояние - типичный автомат Мили.
Женя! Позже обсудим. Я просто дополнение кидаю, что для удобства описания нужно делать в разделе "выходного алфавита", или "действий", не одно , а список действий. Так будет реально удобнее. ССылка на то, что это вынесем в выходную функцию - "размазывает" описание по коду.
Ну и прости, но я как тот вшивый, что все о бане и о бане: супрерпозиция автоматов. Без этого очень ограниченно применение.
В каждлой структуре содержатся вход, выход и новое состояние - типичный автомат Мили.
а можно я поспорю? поправьте меня, в чем я не прав.
Насколько я понял из двух дневного обучения, главное отличие автомата Мили от автомата Мура - в первом действия на переходах, значит зависят и от исходного состояния и от входного сигнала, во втором - только от текущего состояния. Из чего, вроде, следует, что в автомате Мили может быть несколько вариантов действий в зависмости от входного сигнала при переходе из одного и того же состояния, а в автомате Мура - всегда строго один набор действий для одного состояния.
То преобразование, что вы сделали - вы фактически из каждой пары (состояние, входной сигнал) создали новое псевдосостояние со строго одним выходом, одним входом и одним переходом. То есть я не прав - это еще не автомат Мура. Но уже и не Мили, а что-то среднее между ними.
хотя нет, вижу прореху в своих рассуждениях. Автомат Мили выдает действие только при переходе по входному сигналу, автомат Мура - независимо ни от чего. Так что да, вы правы, это таки автомат Мили... хотя и с намеренно избыточным числом состояний для упрощения кода.
PS Надеюсь, мы тут не на лекции и не обязаны только слушать, а можем задавать вопросы и рассуждать, даже если наша "квалификация не дотягивает"? :)
Все это не так просто...но интересно...сначала начинал с switch case, теперь стараюсь переходить на таблицы переходов в зависимости от состояний, по идее тот же КА. Но есть у меня проблемка, больше относящаяся к синтаксису С++ :
Для некоторых действий из таблицы состояний необходимо выполнять дополнительные функции /действия. Сейчас приходится в switch структуре при выполнять нужное.
Как в C++ выполнить процедуру по адресу? Т е я бы в таблицу состояний КА записал бы функцию /адрес и она бы выполнилась. Просьба написать пример.
лег, понимаешь, в постель, надел кислородную трубку от нового концентратора (на 11.11 урвал), а тут такое. Но слава Б..у, всё-таки Мили! Прям от сердца отлегло!
спокночи всем.
супрерпозиция автоматов. Без этого очень ограниченно применение.
Ну, суперпозиция там есть (в библиотеке), только убогая - простенькая, но есть. А вот несколько выходов - нету. Потому в посте 17 у меня есть выход "завести таймер" и есть выход "завести таймер и включить свет" - не от хорошей жизни :)
Итак, снизу вверх.
s30: Если светло, то выключить свет и перейти в состояние MODE_DAY (всё!) Иначе перейти к s31
s31: Если обнаружено движение, то завести таймер и перйти в состояние MODE_NIGHT_LIGHT_ON (мы и так в нём) (всё) иначе перейти к s30
s30: Если истёк таймер, то выключить свет и перейти в состояние MODE_NIGHT (всё)
Т.е. здесь написано просто в точности то, что написано в таблице. Ничего другого. Это точная таблица. И работает именно на переходах.
По поводу Ваших замечаний. Вот Вы же ошибку нашли, значит поняли как списки устроены. Ну, давайте ещё раз пройдемся.
Да нет необходимости, мне кажется я ваш код понимаю на 100%. Мои замечания были немного о другом. Просто вчера, когда мы с Вами обсуждали типы автоматов. я потом нашел статью, как перевести Мили в Мура - и проделал эту операцию на вашем автомате. И там тоже процедура начинается с выделения пар (состояние/переход) - очень похоже на то, что вы делали в #47. Но сейчас я понял, что похожесть только внешняя, а смысл другой.
Вы наверно думаете, что я все время отвлекаюсь на ерунду... но эта ерунда помогает мне понять и то, что вы обьясняете.
Да, почему ерунду - это собственно суть дела. Понимать надо твёрдо, и тогда программироваться само будет.
у меня пока теория с программированием не очень сходятся... в том смысле, что все показанные примеры я бы и без всякой этой теории не затруднился запрограммировать на конечном автомате. Может не очень красиво, на select-case или на коллбеках - но работало бы.
Так что я пока не ощутил, что дает знание теории. Скорее гимнастика ума. Хотя очень интересно. Очень люблю учиться :) - применять знания не люблю... а учиться :)
Евгений, я внимательно перечитал сообщение №47, и у меня возникли вопросы.
Зачем в функцию mealyMachine передается параметр? Могу предположить, что для того, чтобы, если в программе имеется несколько разных КА, все их обрабатывать единственной универсальной функцией. Но номер состояния описан как глобальная переменная. Т.е. у всех автоматов может быть только одно состояние. Если изменяется состояние одного автомата, то синхронно с ним изменяется и состояние всех остальных. При этом, если количество состояний разных автоматов различно, то неизбежно некоторые автоматя будут попадать в недопустимые состояния.
Зачем в функцию mealyMachine передается параметр? Могу предположить, что для того, чтобы, если в программе имеется несколько разных КА, все их обрабатывать единственной универсальной функцией. Но номер состояния описан как глобальная переменная. Т.е. у всех автоматов может быть только одно состояние.
согласен c andriano. ИМХО, правильнее было бы хранить указатель на текущее состояние внутри самого автомата - например, в первом (нулевом) элементе массива
мужики, В слишком серьёзно отнеслись к моему примеру. Это совсем не решение - пример, демонстрирующий технику работы с таблицей, заданной массивом списков. Эту функцию пример исполняет, а другого от него не требуйте. Это только мпример, а вовсе не программа для использования.
Если по уму писать, то там не только состояние, но и таблица у каждого автомата своя. И вот как раз здесь очень правильное место для применения ООП, потому что, если иерархию классов построить так. чтобы класс-потомок мог расширять таблицу (и алфавиты) класса-родителя, то, например, из автомата "блинк" легким движением руки делается автомат "мигать заданное время" или "мигать до какого-то события", причём всё это наследованием с ре-юзаньем кодов и данных родителя.
Уважаемый Б707! Ты сетуешь, что можно и без знаний написать код для примеров? Ну так оно всегда так.
Но примеры дают технику, пользуясь которой легко написать любой автомат.
Автоматным подходом решается любая задача, в которой решения не зависят от дальнего контекста. И решается лучше, чем любым иным методом. Автоматы очень простая и хорошо изученная штука и их легко проверять на "правильность".
...Есть кнопка и диод.
При замыкании кнопки, диод включается на 4 секунды и выключается. Цикл остановился, кнопка замкнута, диод не горит. Ждем размыкания кнопки.
При размыкании кнопки происходит тоже самое- диод включается на 4 секунды и отключается. Цикл остановился, кнопка разомкнута, диод не горит. Ждем замыкания кнопки.
=================================
...Сперва определим состояния автомата...
Исходное состояние: кнопка разомкнута, светодиод не горит, обозначим А.
Дальше - только по нажатию кнопки переходим в стостояние В - кнопка включена, светодиод - тоже.
Теперь зависит от того, что наступило раньше - отпускание кнопки или таймаут. Если таймаут - состояние С - ждем отпускания кнопки.
Если кнопка - в ТЗ этот вариант отсутствует, так что возможны варианты:
- состояние D - светодиод продолжает гореть, но таймаут либо обновляется, либо - нет.
- состояние Е - светодиод гаснет.
В принципе можно считать состоянгие Е равным состоянгию А, но в общем случае это неверно. Например, состояние Е может быть "Ошибка", когда мы перестаем реагировать на кнопку. И это - не единственный альтернативный вариант.
Вернемся к состоянию D. Если мы дождались таймаута, светодиод, видимо, следует погасить, а нам перейти в состояние либо А, либо Е. А если кнопку вновь нажали, то... мы ведь знаем, что бывает не только одиночный щелчок мышью, но и двойной... и никто не запрешает 3-ний или 60-ной. В общем, если кнопку вновь нажали до наступления таймаута, неизбежно появляется состояние F. И каждый раз, когда кнопка будет нажиматься или отпускаться до достижения таймаута, это будет приводить к очередному новому состоянию.
В общем получается, что если ТЗ сформулировано некорректно, то это ведет к увеличению таблицы состояний до бесконечности.
состояния два - "диод горит" и "диод не горит"
Нет, это у светодиода состояния два, а у системы, состоящей из кнопки, светодиода и таймаута, состояний гораздо больше - вплоть до бесконечности, как показано постом выше.
состояния два - "диод горит" и "диод не горит"
Нет, это у светодиода состояния два, а у системы, состоящей из кнопки, светодиода и таймаута, состояний гораздо больше - вплоть до бесконечности, как показано постом выше.
пост выше показывает только. что вы склонны додумывать условия задачи, а это может завести далеко :)
Мой вариант максимально прост и ПОЛНОСТЬЮ соответвует начальной формулировке ТЗ, думаю Влад не откажется подтвердить.
Это здоровая стремление взрослого человека к упрощению! ;) При этом удовлетворяются написанные условия задачи, а "хрустальный шар", как обычно - в ломбарде.
Но, к сожалению, уже редуцированное решение не иллюстрирует главного - запоминание в номере состояния всех составляющих. Поэтому я буду считать, что естественным дополнением к условиям автора является тривиальная реакция на кнопку, а именно - если отпущена раньше таймаута - гаснет, если нажата раньше таймаута - перезапуск на 4 сек.
Как там было? "здоровая стремление взрослого человека к упрощению!"?
Если мы при любой операции с кнопкой автоматически будем забывать состояние таймаута, двойной щелчок нам не реализовать. Никак. А он - есть!
Так мы проиллюстрируем основы проектирования автоматов.
Итак у нас два компонента системы - диод и кнопка. Каждый может быть в двух состояниях, произведение этих множеств и есть множество состояний системы:
И еще третий компонент - состояние таймаута.
Собственно, дальше комментировать бессмысленно.
пост выше показывает только. что вы склонны додумывать условия задачи, а это может завести далеко :)
Напротив, я не склонен додумывать дополнительные ограничения, которых нет в условии задачи, а обдумать все вытекающие из ТЗ варианты.
Мой вариант максимально прост и ПОЛНОСТЬЮ соответвует начальной формулировке ТЗ, думаю Влад не откажется подтвердить.
Влад в посте №42 это уже опроверг.
Если мы при любой операции с кнопкой автоматически будем забывать состояние таймаута, двойной щелчок нам не реализовать. Никак. А он - есть!
где вы видите в ТЗ задание реализовать двойной щелчок? - ну что за балаган? не хотите участвовать - так не мешайте...
Собственно, дальше комментировать бессмысленно.
где вы видите в ТЗ задание реализовать двойной щелчок?
Он не противоречит ТЗ. Не надо выдумывать дополнительных ограничений, которых в ТЗ не было. Реакция на отпускание кнопки до истечения таймаута в ТЗ не прописана. Значит, при анализе необходимо предусмотреть все возможные варианты. Если мы этого не сделаем, а решим как-то дополнить ТЗ собственными предположениями, запросто может оказаться, что после уточнения ТЗ со стороны "заказчика" вся наша конструкция окажется противоречащей последней версии ТЗ.
И еще один момент: попытка предусмотреть все варианты неизбежно приведет нас к обнаружению любой ошибки в ТЗ, если она там имеется. А вводя дополнительные ограничения, не обозначенные "заказчиком", мы рискуем либо не обнаружить ошибок, либо обнаружить их слишком поздно.
Мой вариант максимально прост и ПОЛНОСТЬЮ соответвует начальной формулировке ТЗ, думаю Влад не откажется подтвердить.
Влад в посте №42 это уже опроверг.
ну хорошо, я не собираюсь устраивать тут битву в стиле Архата. Если Влад захочет, он скажет сам.
Мое ИМХО, что ваш разбор автомата далек от начальных условий, и главное - совершенно лишен той простоты и ясности, ради которой собственно и используются КА в программах.
Не надо выдумывать дополнительных ограничений, которых в ТЗ не было. Реакция на отпускание кнопки до истечения таймаута в ТЗ не прописана. Значит...
могу только ответить вашими же словами - "не надо выдумывать того, что не было в ТЗ". Если "Реакция на отпускание кнопки до истечения таймаута в ТЗ не прописана." - значит никакой реакции выдумывать не нужно.
Собственно, дальше комментировать бессмысленно.
Ув. Андриано! Я где-то написал, что нуждаюсь в комментировании?
Смотри - если ты хочешь задать вопрос: "А как быть с таймером?" , то вопрос законный, и ты не стесняйся - задавай! (ниже - ответ)
Ты ведь сам, несколькими постами выше про "автоматы Андриано" написал, что не имеешь квалификации для комментирования? Хочешь ее получить - я открыт, просто слушай, читай, учись. Хочешь ставить под сомнение мою квалификацию? - не нужно, я ведь не навязываю тебе ничего.
-----------------------------
По формальным признакам, автоматы с перезапускаемым таймером не являются КА. Именно потому, что перезапускаемый таймер - это аналог памяти. Поскольку ограничения на разрешение таймера не наложены, такой автомат перестает быть конечным.
В целях настоящего исследования, мы будем игнорировать эту неопределенность. Метод игнорирования - таймер не имеет дробных значений, время у нас квантуется только интервалами таймера. Таким образом мы сохраняем конечность количества состояний.
При програмирование у нас не стоит задача точно придерживаться модели КА. Использовать наработанные методы КА, использовать некоторые доказанные факты про КА - это очень полезно и удобно. Но искуственно заставлять себя "бегать в мешке" - увольте. Важно уметь почувствовать грань, когда мы еще КА, а когда уже "машина Тьюринга". ;)
Евгений, пошу прощения за оффтоп (можно выпилить этот пост), но дабы пресечь возможные нападки Великого и Ужасного Чма - хочу сказать вам и Деду Семёну огромную спасибу за то, что помогли взглянуть на ситуацию со стороны, и не принимать безоткатных, скажем так, решений. Поэтому - немного остыл, и решил продолжать наслаждаться (без шуток) приятной компанией. Спасибо вам за участие ;)
Евгений, пошу прощения за оффтоп (можно выпилить этот пост), но дабы пресечь возможные нападки Великого и Ужасного Чма - хочу сказать вам и Деду Семёну огромную спасибу за то, что помогли взглянуть на ситуацию со стороны, и не принимать безоткатных, скажем так, решений. Поэтому - немного остыл, и решил продолжать наслаждаться (без шуток) приятной компанией. Спасибо вам за участие ;)
С возвращением, а Великий пока ушел.
Евгений, пошу прощения за оффтоп (можно выпилить этот пост), но дабы пресечь возможные нападки Великого и Ужасного Чма - хочу сказать вам и Деду Семёну огромную спасибу за то, что помогли взглянуть на ситуацию со стороны, и не принимать безоткатных, скажем так, решений. Поэтому - немного остыл, и решил продолжать наслаждаться (без шуток) приятной компанией. Спасибо вам за участие ;)
С возвращением, а Великий пока ушел.
но обещал вернуться :D:D если будем плохо себя вести и не кушать кашку
С возвращением, а Великий пока ушел.
но обещал вернуться :D:D если будем плохо себя вести и не кушать кашку
:)))))))) :)))))))
Welcome back!
Я где-то написал, что нуждаюсь в комментировании?
...не имеешь квалификации для комментирования?
Хочешь ее получить - я открыт, просто слушай, читай, учись. Хочешь ставить под сомнение мою квалификацию? - не нужно, я ведь не навязываю тебе ничего.
Я весь во внимании и тщательно конспектирую.
Итак, для того, чтобы откомментировать пост на форуме, жизненно необходимо:
1. Письменное заявление комментируемого (желательно - в трех экземплярах) о том, что он нуждается в комментировании.
2. Справка установленного образца о том, что комментирующий обладает квалификацией для комментирования.
3...
А огласите весь список, пожалуйста.
И - да, я нисколько не сомневаюсь в твоей квалификации. Но по моим наблюдениям, некоторые из людей с очень высокой квалификацией страдают от убеждения в собственной непогрешимости. Вот так - людей. А человеку свойственно - что?
По формальным признакам, автоматы с перезапускаемым таймером не являются КА. Именно потому, что перезапускаемый таймер - это аналог памяти. Поскольку ограничения на разрешение таймера не наложены, такой автомат перестает быть конечным.
В целях настоящего исследования, мы будем игнорировать эту неопределенность. Метод игнорирования - таймер не имеет дробных значений, время у нас квантуется только интервалами таймера. Таким образом мы сохраняем конечность количества состояний.
А я было уже испугался. Ожидал примерно следующего: "Сейчас для иллюстрации решим одну задачку. Но в задачке - таймер, а таймеры выходят за пределы концепции КА, поэтому мы будем решать совершенно другую задачу..." Но, слава Богу, этого не случилось.
А по поводу "бесконечности" автомата с перезапускаемым таймером - я с ходу не могу сообразить, почему. Я немного подумаю, и если не справлюсь, спрошу позже. На первый взгляд кажется, что если у таймера есть конечный набор интервалов, то, даже если эти интервалы не квантуются, а находятся между собой в иррациональном соотношении, автомат не должен становиться бесконечным.
Евгений, пошу прощения за оффтоп (можно выпилить этот пост), но дабы пресечь возможные нападки Великого и Ужасного Чма - хочу сказать вам и Деду Семёну огромную спасибу за то, что помогли взглянуть на ситуацию со стороны, и не принимать безоткатных, скажем так, решений. Поэтому - немного остыл, и решил продолжать наслаждаться (без шуток) приятной компанией. Спасибо вам за участие ;)
Я тоже поздравляю с возвращением!
Тем более, что ... ну не надо все принимать так близко к сердцу. Не стоит оно того.
Тем более - расставаться с приятной компанией из-за одного не очень приятного человека. ;)
Мы не в школе и ты не "неудобный мальчик с вопросами". Бесконечное число состояний получается потому, что между любыми двуми числами есть бесконечно много других регулярных (которые можно решить конечным автоматом) чисел. Память бесконечна - автомат бесконечен. Поэтому вводим квантование, чтобы память сделать конечной.
Хочешь учиться - учись. Я указал базис. Если готов - я буду терпеливо читать лекции по математике, теории множеств, теории доказательтств и пр. и пр., если цель настоящего раздела - только КА в прикладном значении, то много придется принять на веру.
...Каюсь, я забыл в какой области ты специалист, поэтому "зеркальный" пример не смогу придумать. Но фраза "я немного подумаю и решу" - она несколько странная. Еще раз, рамки изложения требуют многое принимать на веру. Иначе мы застрянем в деталях и никуда не продвинемся.
--------------------
Сейчас интереснее обсудить именно "слияние" автоматов. Потому, что простейший "антидребезг" - это тоже КА, он выдает готовые события кнопки, которые мы используем в """главном" автомате. А еще, наприме, даллас: в основном автомате используем температуру, а получаем ее в служебном автомате, реализующим протокол.
Евгений, только вечером внимательно вчитался в ваше сообщение, сорри...
Тепрь записываем таблицу в виде массива списков, где каждый элемент списка - приведённая выще структура
/////////////////////////////////////////////// // // Состояния автомата // enum AUTOMATA_STATE { MODE_DAY = 0, MODE_NIGHT, MODE_NIGHT_LIGHT_ON }; // // первая строка таблицы // static const SSolution s10 = { temno, NULL, MODE_NIGHT, NULL }; // // вторая строка таблицы // static const SSolution s21 = { motionDetected, initTimerAndLightOn, MODE_NIGHT_LIGHT_ON, NULL }; static const SSolution s20 = { svetlo, NULL, MODE_DAY, & s21 }; // // третья строка таблицы // static const SSolution s31 = { motionDetected, initTimer, MODE_NIGHT_LIGHT_ON, NULL }; static const SSolution s30 = { svetlo, lightOFF, MODE_DAY, & s31 }; // // Массив строк таблицы // const SSolution * automataDefinition[] = { &s10, &s20, &s30 };Вот собственно и всё.
мне кажется, Вы в третьей строчке таблицы упустили реакцию на истечение таймера? И еще - ну это просто придирки... вы пишете, что последний элемент структуры - ссылка на следующий, а по вашей записи получается. что на предыдущий... или в этом есть какой-то тайный смысл?
Что касается получившихся структур SSolution - их число и смысл подозрительно напоминают те состояния, что я получил вчера, преобразуя автоматы. Ведь в итоге, фактически, у вас получился автомат Мура - верно? Вот боюсь, опять скажете, что я не прав....
--------------------
Сейчас интереснее обсудить именно "слияние" автоматов. Потому, что простейший "антидребезг" - это тоже КА, он выдает готовые события кнопки, которые мы используем в """главном" автомате. А еще, наприме, даллас: в основном автомате используем температуру, а получаем ее в служебном автомате, реализующим протокол.
мне так и хочется написать - "а чего тут обсуждать?" :)
Ну вот у меня в текущем проекте есть основной автомат и есть кнопки. Автомат кнопок читает состояние кнопки, отрабатывет задержку антидребезга, потом оценивает время нажатия, чтобы отличить короткое от длинного. По результатам работы он выставляет флаги Clicked() или Holded() . А в "главном автомате" те состояния, в которых учитываются сигналы кнопок - просто читают эти флаги и сбрасывают после прочтения.
И с температурой. в общем-то, так же. Понадобиоась температура - скинули запрос автомату Далласа. Когда тот готов выдать значение - он ставит флаг и копирует температуру в "регистр". Основной автомат видит флаг и забирает значение.
Чего тут обсуждать?
Ну, я же не могу ссылаться на имя, которое ещё не определено. Компилятор не поймёт. Потому здесь списки записываются "снизу вверх".
В каждлой структуре содержатся вход, выход и новое состояние - типичный автомат Мили.
Женя! Позже обсудим. Я просто дополнение кидаю, что для удобства описания нужно делать в разделе "выходного алфавита", или "действий", не одно , а список действий. Так будет реально удобнее. ССылка на то, что это вынесем в выходную функцию - "размазывает" описание по коду.
Ну и прости, но я как тот вшивый, что все о бане и о бане: супрерпозиция автоматов. Без этого очень ограниченно применение.
Чего тут обсуждать?
А не просто последовательные как простом автомате.
В каждлой структуре содержатся вход, выход и новое состояние - типичный автомат Мили.
хотя нет, вижу прореху в своих рассуждениях. Автомат Мили выдает действие только при переходе по входному сигналу, автомат Мура - независимо ни от чего. Так что да, вы правы, это таки автомат Мили... хотя и с намеренно избыточным числом состояний для упрощения кода.
PS Надеюсь, мы тут не на лекции и не обязаны только слушать, а можем задавать вопросы и рассуждать, даже если наша "квалификация не дотягивает"? :)
Все это не так просто...но интересно...сначала начинал с switch case, теперь стараюсь переходить на таблицы переходов в зависимости от состояний, по идее тот же КА. Но есть у меня проблемка, больше относящаяся к синтаксису С++ :
Для некоторых действий из таблицы состояний необходимо выполнять дополнительные функции /действия. Сейчас приходится в switch структуре при выполнять нужное.
Как в C++ выполнить процедуру по адресу? Т е я бы в таблицу состояний КА записал бы функцию /адрес и она бы выполнилась. Просьба написать пример.
Так что да, вы правы, это таки автомат Мили...
лег, понимаешь, в постель, надел кислородную трубку от нового концентратора (на 11.11 урвал), а тут такое. Но слава Б..у, всё-таки Мили! Прям от сердца отлегло!
спокночи всем.
По поводу Ваших замечаний. Вот Вы же ошибку нашли, значит поняли как списки устроены. Ну, давайте ещё раз пройдемся.
Одна структура соответсвует одной ячейке таблицы. А вот список (которые снизу вверх пишется) сооветсвует строке, т.е. состоянию.
Ну, и ведите пальцем по списку, доупстим тому же третьему (исправленному). Ведите и сравнивайте со строкй таблицы:
// // третья строка таблицы // static const SSolution s32 = { timerElapsed, lightOFF, MODE_NIGHT, NULL }; static const SSolution s31 = { motionDetected, initTimer, MODE_NIGHT_LIGHT_ON, & s32}; static const SSolution s30 = { svetlo, lightOFF, MODE_DAY, & s31 }; /Итак, снизу вверх.
s30: Если светло, то выключить свет и перейти в состояние MODE_DAY (всё!) Иначе перейти к s31
s31: Если обнаружено движение, то завести таймер и перйти в состояние MODE_NIGHT_LIGHT_ON (мы и так в нём) (всё) иначе перейти к s30
s30: Если истёк таймер, то выключить свет и перейти в состояние MODE_NIGHT (всё)
Т.е. здесь написано просто в точности то, что написано в таблице. Ничего другого. Это точная таблица. И работает именно на переходах.
Так мой пост #47. Там в структуре записаны адреса функций, а последний в том посте кусок кода как раз по адресам их и исполняет. Вот Вам пример.
По поводу Ваших замечаний. Вот Вы же ошибку нашли, значит поняли как списки устроены. Ну, давайте ещё раз пройдемся.
Да нет необходимости, мне кажется я ваш код понимаю на 100%. Мои замечания были немного о другом. Просто вчера, когда мы с Вами обсуждали типы автоматов. я потом нашел статью, как перевести Мили в Мура - и проделал эту операцию на вашем автомате. И там тоже процедура начинается с выделения пар (состояние/переход) - очень похоже на то, что вы делали в #47. Но сейчас я понял, что похожесть только внешняя, а смысл другой.
Вы наверно думаете, что я все время отвлекаюсь на ерунду... но эта ерунда помогает мне понять и то, что вы обьясняете.
Да, почему ерунду - это собственно суть дела. Понимать надо твёрдо, и тогда программироваться само будет.
Да, почему ерунду - это собственно суть дела. Понимать надо твёрдо, и тогда программироваться само будет.
у меня пока теория с программированием не очень сходятся... в том смысле, что все показанные примеры я бы и без всякой этой теории не затруднился запрограммировать на конечном автомате. Может не очень красиво, на select-case или на коллбеках - но работало бы.
Так что я пока не ощутил, что дает знание теории. Скорее гимнастика ума. Хотя очень интересно. Очень люблю учиться :) - применять знания не люблю... а учиться :)
Жаль, что моим, оставшимся от полноценного ганглия клеткам сиё, в большей степени, недоступна. :( Хоть плачь.
Ну, вот представьте себе, что я сейчас начну рассуждать о Вашей специальности. Даже если я не буду нести явного бреда...
понравилость...
Евгений, я внимательно перечитал сообщение №47, и у меня возникли вопросы.
Зачем в функцию mealyMachine передается параметр? Могу предположить, что для того, чтобы, если в программе имеется несколько разных КА, все их обрабатывать единственной универсальной функцией. Но номер состояния описан как глобальная переменная. Т.е. у всех автоматов может быть только одно состояние. Если изменяется состояние одного автомата, то синхронно с ним изменяется и состояние всех остальных. При этом, если количество состояний разных автоматов различно, то неизбежно некоторые автоматя будут попадать в недопустимые состояния.
Вот Вам пример.
спасибо.
Собрал все куски вместе в один скетч, основную процедуру обработки понять не смог...указатели на указатели...ссылки..... это выше моего понимания :(
надо учиться.....
Зачем в функцию mealyMachine передается параметр? Могу предположить, что для того, чтобы, если в программе имеется несколько разных КА, все их обрабатывать единственной универсальной функцией. Но номер состояния описан как глобальная переменная. Т.е. у всех автоматов может быть только одно состояние.
согласен c andriano. ИМХО, правильнее было бы хранить указатель на текущее состояние внутри самого автомата - например, в первом (нулевом) элементе массива
const SSolution * automataDefinition[] = {&s10, &s10, &s20, &s30 };Тогда чуть поправив функцию mealyMachine - получим возможность работать с любым количеством независмых автоматов
void mealyMachine(const SSolution ** definition) { SSolution * sol = definition[0]; while (sol) { if (sol->Signal()) { if (sol->Response) sol->Response(); definition[0] = (SSolution *) * (definition + sol->NewState +1 ); break; } sol = (SSolution *) sol->Next; } }Чтобы убрать необходимость прибавлять единицу в строке 6 - можно чуть сдвинуть состояния в наборе
// // Состояния автомата // enum AUTOMATA_STATE { CURRENT_MODE = 0, MODE_DAY , MODE_NIGHT, MODE_NIGHT_LIGHT_ON };andriano, b707,
мужики, В слишком серьёзно отнеслись к моему примеру. Это совсем не решение - пример, демонстрирующий технику работы с таблицей, заданной массивом списков. Эту функцию пример исполняет, а другого от него не требуйте. Это только мпример, а вовсе не программа для использования.
Если по уму писать, то там не только состояние, но и таблица у каждого автомата своя. И вот как раз здесь очень правильное место для применения ООП, потому что, если иерархию классов построить так. чтобы класс-потомок мог расширять таблицу (и алфавиты) класса-родителя, то, например, из автомата "блинк" легким движением руки делается автомат "мигать заданное время" или "мигать до какого-то события", причём всё это наследованием с ре-юзаньем кодов и данных родителя.
мужики, В слишком серьёзно отнеслись к моему примеру.
ну мы ж серьезные взрослые люди :) я все примеры в этой ветке воспринимаю как заготовки для будущего использования :)
Уважаемый Б707! Ты сетуешь, что можно и без знаний написать код для примеров? Ну так оно всегда так.
Но примеры дают технику, пользуясь которой легко написать любой автомат.
Автоматным подходом решается любая задача, в которой решения не зависят от дальнего контекста. И решается лучше, чем любым иным методом. Автоматы очень простая и хорошо изученная штука и их легко проверять на "правильность".
Уважаемый Б707! Ты сетуешь, что можно и без знаний написать код для примеров? Ну так оно всегда так.
да я не сетую, мне эта тема очень нравится. И, повторюсь - я уже узнал просто массу нового. И надеюсь, мы еще не закончили...