Как стать автором
Обновить

Комментарии 41

Stateflow - это хорошо. Но не стоит забывать Simulink в среде которого диаграммы Stateflow работают. А Simulink создан в парадигме потоковой обработки данных. Stateflow там лишь компонент.

Знакомые буковки, Simulink, и где за пределами машинного обучения в программировании такой инструмент используется?

Цифровая обработка сигналов, фильтры, оцениватели состояний, квантизаторы, статистики, спектральные трансформеры, фаззи-регуляторы, HDL-кодеры, индустриальные коммуникаторы, распознаватели , навигаторы, физические симуляторы, контроллеры моторов и мехатроники, финансовые решатели и симуляторы, фазовые решетки, контроллеры роботов, радиопротоколы и симуляторы радиосетей и т.д. и т.п

НЛО прилетело и опубликовало эту надпись здесь

Быть модным, креативным, понятным «пиплам» – это по-современному, это то, к чему надо стремиться. Кто ж с этим спорит? Собрать по максиму лайков и\или лойсов(?),так сказать, «похайпить» – ну, что еще может быть лучше?!J Правда, в процессе есть опасность, прошу прощения за выражение, «облажаться», но это так – мелочи, на которые не стоит и обращать внимание.

Язык начинается с алфавита, теория программирования – с абстрактных машин. Не зная алфавита, не зная правил, можно выглядеть очень даже креативненько (вполне себе такой Даня Милохин), но и … безграмотным.  Если плавает, как утка, крякает, как утка, то это, наверное, и есть утка или то, что станет ею. Даже если это пусть не очень красивый птенец или весьма привлекательный селезень.

За внешностью Stateflow и за «креативными» котиками «Scratch»-а скрывается нечто, что можно распознать, лишь зная алфавит или – тьфу! – абстрактные машины. Но увидеть это, порой, не очень просто! Здесь нужен или некий очевидный тест, который бы просветил или убедил в чем-то, или самому «ручечками» (что не очень креативно) очистить все от шелухи и докопаться до «алфавита».

В нашем случае алфавит – это те самые абстрактные машины. Но если до них – не царское это дело, то есть простой и, думаю, креативненький такой тест. Это RS-триггер. Он рассмотрен в статье (можно ее не читать). Но он оформлен, нарисован, как «шапка» статьи. Уж его-то можно вполне собрать из «квадратиков» и в среде Stateflow, и в среде “Scratch” да и в любой другой. И если при этом получится верный результат, то все написанное в статье - полный, можно сказать, «скратч», но если не получится, то … уж будьте добры  поставить «лайк» и, отбросив все свои «креативные амбиции», и т.п. … серьезненько так заняться основами, начиная с тех самых абстрактных машин.

Иначе… Ну, иначе прямой путь к …  лайкам (лойсам?)  Дане Милохину. Уж в лойсах, лайках и дизлайках, «котиках» и т.п. он наверняка знает толк J  

Теория формальных грамматик и автоматов конечно мощная. Хорошо описана в учебнике "Фундаментальные основы дискретной математики" В.А.Горбатов.
Но даже там сразу упоминается существование алгоритмически неразрешимых задач, обнаруженных Черчем ещё в 1936 году.
И вот программисты постоянно имеют дело с алгоритмически неразрешимыми задачами.

Т.е. Statflow - это не про автоматное программирование. А про визуальное. И это очень слабо пересекающиеся вещи.
И визуальное программирование действительно передовой метод программирования, но из статьи это понять трудно.


Статья, действительно, по большей части не про визуальное программирование. Она про формальное определение понятия автоматной программы. Просто автоматы имеют множество способов описания и графический способ хорошо ложится в понятие визуального программирования. Stateflow использует графический способ описания автоматов (точнее, диаграмм Харелла). Это чуть искаженные автоматы, но их можно также считать автоматами. Так что Stateflow все же про автоматное программирование. Пусть и в несколько модифицированной форме. А чтобы разъяснить это - в какой - в помощь и может быть моя статья.

Нет, Stateflow это исключительно визуальное программирование. "Автоматчики" узурпировать Stateflow не имеют никаких оснований. Да там можно делать и в cтиле Милли и в стиле Мура, и таблицы переходов, Ну так "автоматчики" умудряются в самом потоковом Simulink сделать автоматы накидав дискретных логических компонентов. Они даже на Бейсик-е могут сделать "автомат".
Да, в Stateflow основное элемент - это состояние, но только это и роднит его с автоматами. Поскольку переходы между состояниями могут быть по событиям, по темпоральным функциям, по сообщениям с очередями, по тригерам и по куче всего.
Я постоянно пишу программы в Stateflow и могу создавать там программы вообще без состояний.

Я тоже считаю программирование в Stateflow автоматным с большой натяжкой. С очень большой ;) Например, у автоматной программы хотя бы одно состояние быть должно. Но чтобы совсем без состояний? Для истинного автоматчика это уж слишком :)

Да, это программирование похоже на автоматное. Очень похоже ;) И модели Мили и Мура похожие. Но и только. О деталях - отдельный разговор.

Я не программирую в Stateflow, а лишь в порядке освоения его возможностей набрасывал в нем небольшие примерчики. И кое-что до конца так и не выяснил. Ну, например, есть ли доступ извне к состоянию модели? Как-то у меня не получилось. А для "автоматного программирования" это важно. Может, подскажите?

Я для вывода текущего состояния использую вот такую опцию у диаграммы:

Тогда у диаграммы появляется внешний порт со значением состояния. Оно будет в виде элемента перечисления, но в Simulink его легко конвертировать в число.

Либо иногда я явно при входе в каждое состояние в директиве en: присваиваю некой переменной определенной значение и эта переменная служит индикатором состояния.

Спасибо! Навскидку больше привлек первый вариант. Конвертация, правда, несколько смущает. Но если уж легко, то пусть хотя бы так.

НЛО прилетело и опубликовало эту надпись здесь

Все же, скорее всего, заблуждаюсь не я. Любое мало-мальски серьезное введение в программирование начинается с определения вычислительного процесса, основанного на понятии алгоритма. В основе понятие алгоритма - определение через абстрактные машины. А уж потом идут всякие операторы, структуры данных, переход к изучению разных алгоритмов, к их реализации, как правило, на некоем условном языке программирования . Как-то так - если кратко "на пальцах". Здесь любой язык программирования - лишь некая форма описания алгоритмов. Просто пока эта форма и понятней и привычней. Но она могла бы быть и другой.

Зачем собирать RS-триггер? Чтобы понять каким должно быть нормальное параллельное программирование. Он простая задача для параллельного программирования, но неподъемная для последовательного. Казалось бы простая мысль, но в силу определенных причин трудно воспринимаемая обычными программистами. Может, в силу их последовательного мышления, впитанного, так сказать, "с молоком".

НЛО прилетело и опубликовало эту надпись здесь

Визуальное программирование, действительно, распространено не так чтобы очень. Но кроме "детских проектов" есть "взрослый" МАТЛАБ, был [заброшенный нами] Дракон. Можно и еще что-то припомнить. Я уж молчу про свою ВКПа, которой я активно пользовался, но сейчас для текущй моей работы - это ПЛК ее "слишком много" и потому она несколько в стороне... Так что тренд есть и он достаточно стабилен...

Про триггер. Собрать-то его собрали, но как он работает, как это ни удивительно, толком нет описания. Его поведение описано в основном "на пальцах". И это при нынешнем-то развитии науки. Смех и только! А все потому, что фактически нет теории параллелизма. Без нее все выливается в некое подобие многопоточности, многоядерности, корутины тут всплыли (видимо, от недостатка идей?) и т.д. и т.п.

В статье, пожалуй, единственное строгое доказательство его поведения. И оно привязано к модели, а не к какому-то языку. С++ здесь фигурирует лишь как средство реализации модели и не более того. И его пример показателен в том смысле, что нужно не так уж много, чтобы из последовательного языка сделать параллельный. И тест на примере триггера ведет себя фактически как реальный триггер, что доказывает свойства параллельности языка (адекватности реальному параллелизму). Попытки реализовать его существующими средствами параллелизма этого не достигают. А ведь можно предложить тесты и посложнее.

И не так уж много надо, чтобы последовательные процессоры сделать параллельными. Об этом была моя предыдущая статья. Но, если кто-то этого не хочет, то, как говорится, и Бог с ними. Пример с виртуальной машиной на С++ убеждает, что и это не главное. Мой опыт убеждает, что в большинстве случаев ее скорости - за глаза, как говорится. Но, может, и не надо спешить с железом, а набрать опыта работы с этой моделью (кстати, других-то параллельных моделей фактически и нет).

Кстати, меня не напрягает даже отсутствие "настоящего" параллельного языка. Текущий вариант с С++ и ядром меня вполне устраивает.

НЛО прилетело и опубликовало эту надпись здесь

Я, безусловно, поклонник :) Прямой рекламой не занимаюсь (как-то это не мое), но мои статьи, надеюсь, хоть немного ею могут считаться. Ну, а то, что нет движухи? Ну, так это и есть следствие реакции большинства на рекламу, ориентации на массы и влагаемые на это деньги. Пример - корутины. Старинная идея, но во что вылилась?! По мне это бред какой-то. В С++ внедрили это безобразие! Но... работает! Может я чего-то не понимаю? Может. Изменю ли я свое мнение по поводу них? Вряд ли. "Сто лет" тому назад я их рассматривал и ... отказался. Отказался в пользу автоматов и как-то не испытываю ни малейшей тревоги или сожаления по этому поводу. Поскольку все это обосновано теми аргументами, которые я, плохо ли хорошо ли, привожу в своих статьях.

Занимаюсь ли я критикой? Занимаюсь, но тоже как могу. Может не так, может не столь сильно. Про корутины я сказал, про SWITCH-технологию высказался, многопоточность обхаял (но ей и без меня ей достается). Что-то это меняет? Да почти ничего. Добавить креативности, перейти на уровень "пиплов"? На это нужны свои способности, наклонности, которых у меня похоже нет. Но, может, это даже к лучшему :)

НЛО прилетело и опубликовало эту надпись здесь

Тема очень близка для программистов, которые в своих практиках применяют FSM (конечные автоматы) которые можно реализовать практически на всех языках.
Таким образом мы можем обращаться в потоке к их состояниям и управлять переходами.
В этой статье в который 101 раз происходит доказательная полемика, базирующаяся на принципах составления алгоритмов, но по большому счету если IDE включает в себя многообразные целевые FSM, с возможностью параметрических настроек их свойств состояний, то вся работа разработчика практически будет сведена к вводу инструкций, следуя детализированному словесному алгоритму, без его представления в виде графов.
Для публичной демонстрации такой IDE далеко не обязательна доказательная теория, это реальный кодогенератор и интуитивно понятная интерфейсная абстракция (понимаем разрабов), есть мнение что это и есть языковая модель (визуальная).

@lws0954Существуют ли поточные алгоритмы синтеза структурных автоматов с памятью?

Можно, конечно, представить и такое. Но есть ли в этом смысл? Другое дело - реализовать поточные алгоритмы, используя сетевую автоматную модель. Что-то подобное я даже было дело пробовал :)

Да-да, вот про "сетевую автоматную модель" и её поточный синтез расскажите, пожалуйста, подробнее)

Посмотрите мою статью. В ней в достаточной степени отражена асинхронность сетей. Каждый компонент подобной сети - это поток. Но, строго говоря, для потоковых вычислений нужно еще делать анализ готовности входных данных и только по их готовности запускать операцию. Но можно этого и не делать. Рано или поздно все устаканится и мы будем иметь тот конечный результат., который ожидается. Главное здесь за него не принять промежуточные значения.

Правильно понимаю, что гарантированно "устаканится" на ожидаемый результат может лишь только в том случае, если в схеме нет рекуррентных связей?

Насколько я понимаю речь об обратных связях. Здесь - это абсолютно не помеха. Но опять же все зависит от алгоритма. Смотрим на тот же триггер. Он содержит обратные связи. Причем связи перекрестные. Но в одной ситуации он "устаканивается", т.е. переходит в устойчивое состояние. В другой - входит в режим генерации. Но и то и другое - правильно. И тот и другой - ожидаемые результаты. Более того, - просчитанные (см. статью, операция умножения автоматов и построение результирующего автомата).

Да, собственно и приведенный здесь RS-триггер - это тоже пример поточных вычислений. Каждый его элемент - это тот же поток. Они работают независимо, воспринимаю входные данные и выда.т результат. В результате имеем поведение RS-триггера. Поточного ;)

Да, еще типичный пример - сети Петри. Когда-то, реализуя их, я представил каждый барьер (полочку) и место (кружочек) некоторой сети Петри отдельным автоматом. Определил их условия работы и ... все. Дальше делаем разметку и смотрим на результат. Вот, как-то так...

Вы уже, разумеется, поняли) я далёк от автоматного программирования, да и дискретную математику порядком подзабыл, поэтому просто постараюсь нарисовать:

Автомат

Как собрать такой автомат на "сетях структурных автоматов"? Входящие узлы принимают булевские значения. Автомат должен быть с памятью, т.е. не просто комбинационная схема.

Собственно это не автомат. Таблица, которую Вы нарисовали не несет информации о поведении. Опишите функции переходов и выходов. Переходов - это когда есть текущее состояние и входной сигнал и нужно указать следующее состояние. Функция выходов - это когда есть это же состояние, этот же вход и нужно выдать сигнал. Если это будет несколько автоматов, например автоматы А и В, то нужно определить, если оно есть, взаимодействие между ними.

В таблице, как мне представляется, описано поведение некоего "черного ящика" в серии из 4 наблюдений за ним. И нам надо собрать устройство, реализующее идентичную логику. Что-то мне подсказывает) но эта задача очень распространённая. Скорее, даже типовая, не ошибиться бы.. в ТАУ?

Как на "сетях структурных автоматов" построить модель черного ящика по серии наблюдений за ним?

Это отдельная тема. Подобным построением автоматов я не увлекаюсь. Это уже что-то ближе к нейронным сетям. Но припомнил только одну книжку, которая, может, и сможет помочь разобраться в этом. Это Богомолов А.М., Твердохлебов В.А. Диагностика сложных систем.

Хорошо, спасибо за книжку.

А ведь статья вовсе не о программировании, тут о цифровых системах управления идёт речь, а это две больших разницы, я такую фигню изучал.

И то и другое - одна хрень. Ей название - алгоритмы. Программирование - про алгоритмы. Может, Вас не тому и не так учили? ;)

Может учили, а может и не учили, но вот троллить меня по этой теме не нужно, хотя бы поверхностно ТАУ и ЦСУ я знаю: нет там никаких алгоритмов, чистое моделирование.

П.С. запись программы из z-уравнений не в счёт, ибо если ты уж получил z-форму, написать для неё реализацию - попса.

А моделирование - это не про алгоритмы? До текущего момента я все же представлял, что поведение любой модели определяется простым ли, сложным ли, но все же алгоритмом. Вы переворачиваете мои представления о моделировании...

У меня - во всех.

Понятно. Если применяется только в ваших игрушках, то к чему этот высокий штиль и академический формализм?! Ощущение от вашей статьи такое, как будто читаешь нормативно-правовой акт: хочется по-быстрее закрыть, чтобы не сойти с ума. Если хотите разжечь интерес к теории автоматов и практике, нужно проще излагать для широкой публики.

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории