В том-то и дело, что применить этот закон к чему-то просто невозможно. Потому как он не отвечает на вопрос, как посчитать проценты. А с остальным согласен на все "сто".
Все может быть. Может быть любой цвет. Например, переход из состояния 1 в 2 (см. рис.2) может происходить через промежуточное состояние, в котором можно будет включить на какое-то время желтый.
Но это будет уже другой светофор. У рассматриваемого светофора даже не предусмотрен желтый.
А по поводу модели Харелла. Конечно, нет.
Но главная цель статьи в другом. В демонстрации теоретических возможностей автоматов. Есть даже результат, на который следовало бы обратить внимание. Возможностей, которых фактически нет у других моделей. У модели блок-схем (типичной модели для любого языка программирования) так точно. Правда, любую блок-схему можно обратить в автомат и далее продолжить... И, может, если постараться, получить такой же результат. Но можно доказать и обратное. Т.е. у автоматов есть теория, которой можно пользоваться и на формальном уровне делать формальный анализ созданной модели.А это намного эффективнее, чем обычное тестирование.
Ну, вот и всё. До свидания, мой читатель! Спасибо за то, что прочитал эту статью!
Как говорится, - не за что!
Тем не менее, что можно сказать после прочтения столь замечательной статьи? И как можно выразить ту степень благодарности, которую испытываешь после ее прочтения?
Весьма поразила описанная мощь теории многопоточного программирования. Хорошо, что автор напомнил, из чего состоят программы. Теперь хотя бы понятно почему «немного» времени процессор уделяет коду программы. Остальное время – что-то типа «черной материи»?
«Теоретическим открытием» для многих будет и то, что команды в программе выполняются друг за другом. Не совсем, правда, ясно как потоки «могут повысить быстродействие и производительность программы»? Но это, может, из-за непонимания различия между «быстродействием» и «производительностью» программ?
О реализации многопоточности. Даже не к чему придраться. А потому-то, ой, как «здорово получилось»?! Но если рассуждать здраво, то потоки работают одновременно и одновременно «бьются» в консоль. И почему тогда не «каша» из символов/слов, а - просто «здорово»? Почему, как сказано далее, в этом случае «проблем нет», а другие случаи требуют синхронизации?
Если так - другое дело. Как-то не врубился сразу. Так что беру свои слова (про один цвет) обратно.
По поводу таймера. Совсем нет проблем. Здесь используется вложенный автомат. Можно и параллельный. Все эти задержки используются в моих примерах на Git. В базовом автоматном классе (LFsaAppl) это методы FCreateDelay и FCreateParDelay.
У Вас специализированное решение, у меня - универсальное, где цвета могут гореть одновременно, есть действия по установке и сбросу действия. У Вас может гореть только один цвет. Это существенное ограничение.
По поводу корректности. Я даже ждал этот вопрос. У меня таймер - вложенный автомат, а потому не нужно контролировать его завершение.
О процедуре. Она приведена в книге С.Баранова "Синтез микропрограммных автоматов". Знать ее очень полезно. Процедура эта не "помогает" писать, а помогать приводить одну модель к другой. Я беру Вашу - блок-схему и получаю свою - автомат. Она объясняет/доказывает, что Ваша программа это по сути тот же автомат и наоборот.
Так что все нормально. Имя свою модель я очень просто создаю управление светофором. В этом случае я не изобретаю таблицу, не создаю программу перебора ее строк. Т.е. ситуация только проще, а не сложнее. Более того автомат имеет плюшки, которых нет у таблицы и программе к ней.
Автомат ни чего не проверяет :) Есть некое представление таблицы переходов автомата и есть интерпретатор этой таблицы. Вот последний берет эту ТП и в соответствии с ней организует работу остальных компонент автоматной программы (АП). Он имеет информацию о текущем состоянии и понимает какие функции (предикаты и действия) относятся к нему, запускает сначала предикаты для определения наличия условия перехода и если оно есть, то запускаются действия этого сработавшего перехода. Да, при этом, если есть переход, устанавливается новое текущее состояние. Это немного отлично от того, что Вы, прошу прощения, нафантазировали.
Компиляция здесь только навредит делу, т.к. автомат не один, а есть на самом деле множество автоматов, называемое сетью. Вы об этом помните?
Было бы неплохо иметь не программный, а аппаратный интерпретатор. Это бы на порядок, а, может, и несколько увеличило бы скорость. Но и сейчас они очень даже неплохая, если сравнивать параллелизм автоматов и потоков. При необходимости синхронизации процессов, автоматы, думаю, потоки сделают ;)
Создавая свое решение следите, чтобы не создать другую модель. Не плодите ошибок подобных МАТЛAБ, Engee и SimInTech. Они пошли по стопам автоматов Харела. Но это уже другая модель, которую по несчастью тоже назвали конечным автоматом.
Сравните мое решение и Ваше. Я Ваши же запросы к таблице оборачиваю в действия и предикаты автомата. Неужели не понятно? Для кого я это делал, елки-моталки? ;)
это всех нервирует.
Можно не обращать внимания... Но людей "нервирует" в двух случаях. По своей глупости или по глупости автора. Всем не угодишь, но понять почему их "нервирует" важно. Вы явно зря наехали на автоматы. Люди занервничали. Еще не поняли почему?
Ваша "машина" (АМС) проще. Ее "табличный язык": множество строк, где каждая строка - цвет, время. Автомат, безусловно, сложнее, но для знающего КА все просто и здесь. Но дело в другом - возможности "машин" несравненно разные. Автомат - управление универсальное. У Вас - ограниченное. Ну, очень ограниченное. Для простого светофора - сойдет, но даже для другого скорее всего нет. Автомату по силам любой светофор. Любой, какой позволяет Ваша фантазия. Все потому, что - автомат! Классический автомат. Это важно. Кто хоть немного знает ТКА разберется в 5 сек. Вам для другого светофора придется переписывать программу. Автомат не придется переписывать. Но переписывается его таблица переходов. Просто потому, что алгоритм будет другой. Но от этого ни куда не деться. Так что, может, чуть-чуть сложнее, но много-много-много универсальнее. Как-то так.
почему вам своей таблицы не хватает с Иксами и Игреками? Зачем вы мою таблицу еще скоммуниздили?
Прошу прощения. Есть еще другой более современный термин - "цап-царап" :)
В оправдание скажу, что я лишь хотел реализовать Вашу "абстрактную машину" программирования светофора. Назовем ее условно АМС (абстрактная машина светофора). У нее есть и язык - программа светофора (ПС). Это множество строк формата - "свет, время". Есть у этой АМС и блок управления (БУ), который интерпретирует эту программу (ПС).
Я прошу прощения, даже каюсь, что цап-царапнул у Вас ПС. Это получилось без Вашего разрешения, но мною - неосознанно. Я не осознавал, что делал в этот момент. Но мне очень хотелось реализовать Вашу АМС на основе реализации собственного БУ в форме автомата. Здесь я тоже поступил нечестно - конвертировал Вашу реализацию БУ в свою - на базе КА. И горжусь тем, что это получилось. .
Не догадались также в виде объектов переписать как здесь у вас
Вы, может, удивитесь, но, как ни странно, догадался! ;) В моей предыдущей статье в Листинге 1 такая реализация приведена.. Я ее здесь даже повторю:
nextRect(Table) в данном случае совсем не автомат. Это - действие "взять следующую строку таблицы". Так что тут не "дело вкуса", а нужно отделять котлеты от мух.
А вот программа - это уже вычислительная модель. Не в форме, конечно, автомата, а в форме блок-схемной модели. Но именно по этой модели я и построил автоматную модель.
Все тяжело и заумно, когда не знаешь. Например, для меня очень тяжелы и заумны новые языки программирования. Просто потому, что я их не знаю, а не знаю просто потому, что они мне не нужны, т.к. есть великолепный С++. Тут я думаю все понятно.
Теперь о решении. Автомат - это управление программы. Оно может быть сколь угодно, сложны, большим. Это такая универсальная модель, которая оперирует запуском определенных функций - предикатов и действий.
Чтобы сделать поставленную задачу (любую!) я создаю предикаты - x-сы, которые анализируют внешнюю информацию. Ну, например, что нужно перескочить через строку. А это делает уже соответствующее действие - y-ки. Если не хватает тех, что есть, я создаю такие, которые прыгают по таблице. Имея все это, я могу уже создать модель управления для алгоритма, который "прыгает" по строкам.
Кстати, если заметили, то выделенное управление позволяет изменять алгоритм, не трогая остального кода. Кстати, Ваше решение близко к этому - можно менять программу управления (Ваш цикл), не трогая код таблицы.
И, вообще, используемая Вами вычислительная модель - устаревшая. Это признано уже давно. Автоматная алгоритмическая модель - это более мощная модель. Из этого и надо исходить.
Не очень ясно про "камушек". Автомат работает ровно так, как его создали. Но он при этом позволяет процесс своего исполнения контролировать лучше, точнее, нагляднее, чем при обычном программном подходе. Хотя бы контроль его текущего состояния. Но, ведь, есть еще и другие "автоматные фишки".
Тут хотелось бы услышать мнение Рабиновича. А, может, он "напел" не хуже Карузо и при этом высказал свое мнение по его поводу? Стоит ли комментировать его мнение? В том-то и дело, что"Рабинович" не только напел, но еще и что-то сказал. Вот такая примерно ситуация ;)
Кстати, вчера была оценка статьи +4, а сегодня уже +3. Кто-то, может, учел мнение "Рабиновича"?
для некоторых задач есть более эффективная техника программирования
Т.е. "некоторые задачи" подразумевают некий класс и/или хотя бы перечень задач. А "более эффективная техника" - тоже хотя бы название этой техники. Вот это хотелось уточнить. Потому что в приведенном примере все просто и обыденно и чего-то такого оригинального нет. Ни в самой задаче, ни в технике ее программирования. Обычная "процедурная техника", если ее можно так назвать.
Переход к автомату (КА) делается по щелчку. !00 лет формальной процедуре перехода от любой мудреной программы к КА. Так что для знающего КА не ловушка, а идеальная игрушка! Просто нужно хорошо знать матчасть. :)
В том-то и дело, что применить этот закон к чему-то просто невозможно. Потому как он не отвечает на вопрос, как посчитать проценты. А с остальным согласен на все "сто".
Все может быть. Может быть любой цвет. Например, переход из состояния 1 в 2 (см. рис.2) может происходить через промежуточное состояние, в котором можно будет включить на какое-то время желтый.
Но это будет уже другой светофор. У рассматриваемого светофора даже не предусмотрен желтый.
А по поводу модели Харелла. Конечно, нет.
Но главная цель статьи в другом. В демонстрации теоретических возможностей автоматов. Есть даже результат, на который следовало бы обратить внимание. Возможностей, которых фактически нет у других моделей. У модели блок-схем (типичной модели для любого языка программирования) так точно. Правда, любую блок-схему можно обратить в автомат и далее продолжить... И, может, если постараться, получить такой же результат. Но можно доказать и обратное. Т.е. у автоматов есть теория, которой можно пользоваться и на формальном уровне делать формальный анализ созданной модели.А это намного эффективнее, чем обычное тестирование.
Как говорится, - не за что!
Тем не менее, что можно сказать после прочтения столь замечательной статьи? И как можно выразить ту степень благодарности, которую испытываешь после ее прочтения?
Весьма поразила описанная мощь теории многопоточного программирования. Хорошо, что автор напомнил, из чего состоят программы. Теперь хотя бы понятно почему «немного» времени процессор уделяет коду программы. Остальное время – что-то типа «черной материи»?
«Теоретическим открытием» для многих будет и то, что команды в программе выполняются друг за другом. Не совсем, правда, ясно как потоки «могут повысить быстродействие и производительность программы»? Но это, может, из-за непонимания различия между «быстродействием» и «производительностью» программ?
О реализации многопоточности. Даже не к чему придраться. А потому-то, ой, как «здорово получилось»?! Но если рассуждать здраво, то потоки работают одновременно и одновременно «бьются» в консоль. И почему тогда не «каша» из символов/слов, а - просто «здорово»? Почему, как сказано далее, в этом случае «проблем нет», а другие случаи требуют синхронизации?
С нетерпением ждем разъяснений…
Если так - другое дело. Как-то не врубился сразу. Так что беру свои слова (про один цвет) обратно.
По поводу таймера. Совсем нет проблем. Здесь используется вложенный автомат. Можно и параллельный. Все эти задержки используются в моих примерах на Git. В базовом автоматном классе (LFsaAppl) это методы FCreateDelay и FCreateParDelay.
У Вас специализированное решение, у меня - универсальное, где цвета могут гореть одновременно, есть действия по установке и сбросу действия. У Вас может гореть только один цвет. Это существенное ограничение.
По поводу корректности. Я даже ждал этот вопрос. У меня таймер - вложенный автомат, а потому не нужно контролировать его завершение.
О процедуре. Она приведена в книге С.Баранова "Синтез микропрограммных автоматов". Знать ее очень полезно. Процедура эта не "помогает" писать, а помогать приводить одну модель к другой. Я беру Вашу - блок-схему и получаю свою - автомат. Она объясняет/доказывает, что Ваша программа это по сути тот же автомат и наоборот.
Так что все нормально. Имя свою модель я очень просто создаю управление светофором. В этом случае я не изобретаю таблицу, не создаю программу перебора ее строк. Т.е. ситуация только проще, а не сложнее. Более того автомат имеет плюшки, которых нет у таблицы и программе к ней.
Автомат ни чего не проверяет :) Есть некое представление таблицы переходов автомата и есть интерпретатор этой таблицы. Вот последний берет эту ТП и в соответствии с ней организует работу остальных компонент автоматной программы (АП). Он имеет информацию о текущем состоянии и понимает какие функции (предикаты и действия) относятся к нему, запускает сначала предикаты для определения наличия условия перехода и если оно есть, то запускаются действия этого сработавшего перехода. Да, при этом, если есть переход, устанавливается новое текущее состояние. Это немного отлично от того, что Вы, прошу прощения, нафантазировали.
Компиляция здесь только навредит делу, т.к. автомат не один, а есть на самом деле множество автоматов, называемое сетью. Вы об этом помните?
Было бы неплохо иметь не программный, а аппаратный интерпретатор. Это бы на порядок, а, может, и несколько увеличило бы скорость. Но и сейчас они очень даже неплохая, если сравнивать параллелизм автоматов и потоков. При необходимости синхронизации процессов, автоматы, думаю, потоки сделают ;)
Создавая свое решение следите, чтобы не создать другую модель. Не плодите ошибок подобных МАТЛAБ, Engee и SimInTech. Они пошли по стопам автоматов Харела. Но это уже другая модель, которую по несчастью тоже назвали конечным автоматом.
Сравните мое решение и Ваше. Я Ваши же запросы к таблице оборачиваю в действия и предикаты автомата. Неужели не понятно? Для кого я это делал, елки-моталки? ;)
Можно не обращать внимания... Но людей "нервирует" в двух случаях. По своей глупости или по глупости автора. Всем не угодишь, но понять почему их "нервирует" важно. Вы явно зря наехали на автоматы. Люди занервничали. Еще не поняли почему?
Ваша "машина" (АМС) проще. Ее "табличный язык": множество строк, где каждая строка - цвет, время. Автомат, безусловно, сложнее, но для знающего КА все просто и здесь. Но дело в другом - возможности "машин" несравненно разные. Автомат - управление универсальное. У Вас - ограниченное. Ну, очень ограниченное. Для простого светофора - сойдет, но даже для другого скорее всего нет. Автомату по силам любой светофор. Любой, какой позволяет Ваша фантазия. Все потому, что - автомат! Классический автомат. Это важно. Кто хоть немного знает ТКА разберется в 5 сек. Вам для другого светофора придется переписывать программу. Автомат не придется переписывать. Но переписывается его таблица переходов. Просто потому, что алгоритм будет другой. Но от этого ни куда не деться. Так что, может, чуть-чуть сложнее, но много-много-много универсальнее. Как-то так.
Прошу прощения. Есть еще другой более современный термин - "цап-царап" :)
В оправдание скажу, что я лишь хотел реализовать Вашу "абстрактную машину" программирования светофора. Назовем ее условно АМС (абстрактная машина светофора). У нее есть и язык - программа светофора (ПС). Это множество строк формата - "свет, время". Есть у этой АМС и блок управления (БУ), который интерпретирует эту программу (ПС).
Я прошу прощения, даже каюсь, что цап-царапнул у Вас ПС. Это получилось без Вашего разрешения, но мною - неосознанно. Я не осознавал, что делал в этот момент. Но мне очень хотелось реализовать Вашу АМС на основе реализации собственного БУ в форме автомата. Здесь я тоже поступил нечестно - конвертировал Вашу реализацию БУ в свою - на базе КА. И горжусь тем, что это получилось. .
Вы, может, удивитесь, но, как ни странно, догадался! ;) В моей предыдущей статье в Листинге 1 такая реализация приведена.. Я ее здесь даже повторю:
И, кстати, именно автомат реализует непроцедурную (декларативную) технику проектирования. Ваша же таблица - нет.
А где тут декларативность? Все (именно все) очень даже процедурно. Ни какого смешения техник. Или как?
А какие здесь могут быть вопросы. Это известная табличная форма описания автомата. Что не ясно-то?
nextRect(Table) в данном случае совсем не автомат. Это - действие "взять следующую строку таблицы". Так что тут не "дело вкуса", а нужно отделять котлеты от мух.
А вот программа - это уже вычислительная модель. Не в форме, конечно, автомата, а в форме блок-схемной модели. Но именно по этой модели я и построил автоматную модель.
Все тяжело и заумно, когда не знаешь. Например, для меня очень тяжелы и заумны новые языки программирования. Просто потому, что я их не знаю, а не знаю просто потому, что они мне не нужны, т.к. есть великолепный С++. Тут я думаю все понятно.
Теперь о решении. Автомат - это управление программы. Оно может быть сколь угодно, сложны, большим. Это такая универсальная модель, которая оперирует запуском определенных функций - предикатов и действий.
Чтобы сделать поставленную задачу (любую!) я создаю предикаты - x-сы, которые анализируют внешнюю информацию. Ну, например, что нужно перескочить через строку. А это делает уже соответствующее действие - y-ки. Если не хватает тех, что есть, я создаю такие, которые прыгают по таблице. Имея все это, я могу уже создать модель управления для алгоритма, который "прыгает" по строкам.
Кстати, если заметили, то выделенное управление позволяет изменять алгоритм, не трогая остального кода. Кстати, Ваше решение близко к этому - можно менять программу управления (Ваш цикл), не трогая код таблицы.
И, вообще, используемая Вами вычислительная модель - устаревшая. Это признано уже давно. Автоматная алгоритмическая модель - это более мощная модель. Из этого и надо исходить.
.
Вы еще не понимаете своего счастья: Вам есть куда развиваться! :)
Не очень ясно про "камушек". Автомат работает ровно так, как его создали. Но он при этом позволяет процесс своего исполнения контролировать лучше, точнее, нагляднее, чем при обычном программном подходе. Хотя бы контроль его текущего состояния. Но, ведь, есть еще и другие "автоматные фишки".
Тут хотелось бы услышать мнение Рабиновича. А, может, он "напел" не хуже Карузо и при этом высказал свое мнение по его поводу? Стоит ли комментировать его мнение? В том-то и дело, что"Рабинович" не только напел, но еще и что-то сказал. Вот такая примерно ситуация ;)
Кстати, вчера была оценка статьи +4, а сегодня уже +3. Кто-то, может, учел мнение "Рабиновича"?
Да это-то понятно. Не понятна фраза:
Т.е. "некоторые задачи" подразумевают некий класс и/или хотя бы перечень задач. А "более эффективная техника" - тоже хотя бы название этой техники. Вот это хотелось уточнить. Потому что в приведенном примере все просто и обыденно и чего-то такого оригинального нет. Ни в самой задаче, ни в технике ее программирования. Обычная "процедурная техника", если ее можно так назвать.
Проштудировал, можно сказать. Даже статью, признаюсь, накрапал на эту тему - тему "ловушки" :)
Только не понял "простым циклическим переходом" это другая задача и другая техника?
Можно уточнить. Что за задачи и что за техника программирования?
по мотивам статьи Конечный автомат - ловушка для программиста
Это исходная программа:
tablRec = Table.firstRec();
while(true)
{
setLampsState(tablRec.colors);
timer = setTimer(tablRec.period);
waitFor(timer);
tablRec = nextRec(Table);
if(tablRec == 0)
tablRec = Table.firstRec();
}
А это эквивалентный ей автомат:
bool x1() { return timer; }
bool x2(){ return tablRec == 0 }
y1() { tablRec = Table.firstRec();}
y2(){ setLampsState(tablRec.colors); }
y3(){ timer = setTimer(tablRec.period); }
y4(){ tablRec = nextRec(Table); }
“s1”, “s2”, “-”, y1,
“s2”, “s3”, “-”, y2y3,
“s3”, “s3”, “x1”, -,
“s3”, “s4”, “^x1”, y4,
“s4”, “s2”, “x2”, y1,
“s4”, “s2”, “^x2”, -.
Переход к автомату (КА) делается по щелчку. !00 лет формальной процедуре перехода от любой мудреной программы к КА. Так что для знающего КА не ловушка, а идеальная игрушка! Просто нужно хорошо знать матчасть. :)