Comments 82
Я, признаться, совершенно не понял сути вашей проблемы из набора приведённых графиков.
Совершенно очевидно, что если вносить задержки, то мы будем получать различные эффекты. Скажем, алкоголь, неумеренно принятый накануне в тяпницу вносит определённую задержку в контур управления, так что наливая наутро стакан воды для компенсации обезвоживания организма, я обычно переливаю выше краёв.
Ну а если серьёзно, то нечёткая логика тут особо ни при чём, там довольно примитивный контроллер на два входа и один выход, и это первое же, что я проконтролировал, перекладывая код SimInTech на LabVIEW, так как там фактически библиотечные функции вне моего контроля (меня немного смутила "асимметрия" в параметрах контроллера, так что я довольно дотошно проверил, подавая на входы сгенерированные рампы и визуально контролируя форму сигнала на выходе, и там всё в общем честно, хотя расхождения и есть, но они незначительны). Если вам нужна реализация на плюсплюсах, то её вероятно можно найти готовую (на Питоне уж точно).
А вот дальше там два интегратора и обратная связь (кстати, интегратор в клапане мне кажется избыточным, можно обойтись и одним в баке, ну да ладно), и меняя шаг дискретизации мы также можем получить всё что душе угодно. Кстати, насколького я вижу, SimInTech автоматом подгоняет шаг интегрирования к шагу дискретизации, а вот в LabVIEW параметр dt интегратора настраиваемый:

так что я не только временнýю задержку могу получить, но и изменение амплитуды на выходе интегратора, если шаг интегрирования и шаг симуляции будут отличаться.
Вообще если вы по-какой-то причине не доверяете SimInTech, так возьмите Simulink, ведь пример SimInTech почти один в один взят вот отсюда:
Там вот так всё устроено:

И да, выходы контроллерва нечёткой логики тоже настроены слегка несимметрично (я имею ввиду close_slow/open_slow):

Ну и результат:

Если же начать накручивать параметры в симулинке, то, разумеется, тоже появятся всякие весёлые эффекты.
Либо вас смущает лёгкая специфика реализации на автоматах, но это вроде вот тут уже обсуждалось: Нечеткая логика и конечные автоматы против ПИД-регулятора. https://habr.com/ru/articles/500268/.
Как говорят, - хороший вопрос Вы задали ;) А, действительно, зачем это - колготня с задержками. В заключении статьи я сказал, что "мы показали влияние задержек на результат". Ну, и что? Для специалиста это как-бы очевидно. Тоже мне, мол, открыл Америку? ;)
И тут я сам себе задумался... Действительно, а что я показал и что сказал нового в этом смысле? В смысле задержек, конечно.. Ну, меняется результат... И что?
А то... что задержки в параллельных средах и последовательных распространяются по-разному. Скажу гениальную вещь! :) В параллельных - параллельно, в последовательных - последовательно. Ит тут уж совсем - нестандартная мысль (заметили, как я себя любимого оцениваю - гениальный, нестандартный и т.д.!)! Можно ли, меняя только задержки/задержку, понять - параллельная система или последовательная? Конечно, по конечному результату... А?
Это уже вопрос к Вам. Платформы SimInTech, LabView, Matlab последовательные или параллельные? Можно ли, глядя на результаты, выдаваемые здесь решениями, сказать что-то об их параллелизме?
Вот я, как "колокольчик", занудно везде "звоню", что ВКПа - параллельная платформа. И, действительно, результаты в ней достаточно заметно отличаютс от других платформ. Которые, не скрывая гордости, говорят, что мы, мол последовательные. И что с того? Нафига нам параллелизм ВКПа, если есть удовлетворяющие нас последовательные, SimInTech, LabView и далее по списку.
Действительно, - нафига? Я "звоню"- потому, мол, что последовательные выдают правильный результат, а последовательные его искажают. И что? А какой он должен быть - правильный? И далее повторяется все по кругу...
Однако, есть задачи, которые без параллелизма просто не работают. От слова совсем. Это, например, моделирование RS-триггера.Существующее программирование в лице любых платформ с нею не справляется. И чо? Ведь все остальное работает. И даже где-то параллельно. Неверно? А докажи!
Ну, с триггером все понятно. А с остальным? Итак, повторю вопрос.
Можно ли по результатам работы обсуждаемой здесь системы управления баком определить как она (модель, конечно) реализована - параллельно или последовательно? Причем, в реальном исполнении ее компоненты параллельны по определению. А тогда как быть с результатами? Результаты реальной параллельной системы и ее модели будут совпадать? Должны совпадать? Если будут отличаться, то насколько допустимо это отличие?....
Теперь понятно, почему я тормознул с ответом? Вы своим вопросом заставили (в хорошем смысле, конечно) меня задуматься. И, кажется, даже я что-то придумал. Но это надо еще проверить И, может быть, даже будет основой для еще одной статьи ;)...
Но вопрос к Вам остается. Можно ли и как по результатам работы рассматриваемой нами системы управления баком оценить степень параллелизма SimInTech? Степень адекватности моделирования? Все это относится и к, безуcловно, более близкой и известной Вам LabView.? Может это тоже заставит Вас задуматься? :)
И тем не менее я всё-же не до конца понимаю словосочетание "степень параллелизма" в вашей интерпретации. Для меня параллелизм — это когда что-то с чем-то выполняется параллельно. Два потока в компьютере, к примеру. Да, там есть тонкости типа псевдопараллельности в зависимости от модели многозададачности, но LabVIEW параллельна сама по себе априори и из коробки, вплоть до того, что отдельные циклы (автоматы, если хотите) там вообще на разные ядра процессора раскидать можно и они будут выполняться параллельно (можно с синхронизацией, можно и без). Что значит "степень параллелизма?"
Но в контексте конкретно данного обсуждения я, кажется, начинаю вас понимать, и вот мне кажется, что вы в какой-то мере подменяете понятия "непрерывности/дискретности" понятиями "параллельно/последовательно". Вероятно вы считаете автоматы клапана и бака некими "параллельными" системами с "мгновенной" реакцией.
Давайте в качестве примера упростим всё до предела, рассмотрим сливной бачок унитаза. Там есть кнопка слива, поплавок и клапан, соединённый с поплавком. Чем ниже уровень воды, тем сильнее открывается клапан. Нас интересует уровень воды как функция времени после нажатия кнопки, определённая на временнóм участке до следующего наполнения. Это типичная непрерывная (аналоговая, если будет угодно) система. Чтобы хоть как-то проконтролировать нашу модель, мы вкорячим туда ардуинку, замеряющую уровень в определённые моменты времени. Понятно, что если мы будем менять частоту опроса ардуинки, то на систему это никак не повлияет, разве что график станет грубее. Также и в симуляции, если мы меняем частоту дискретизации, но модель возвращает одни и те же значения в одни и те же моменты времени, то это непрерывная модель. Я могу хоть через пять секунд попросить время и моделб мне скажет количество воды в этот момент.Всё просто.
Теперь мы слегка изменим наш бачок — добавим сервомотор, и ардуинка теперь будет не просто опрашивать уровень поплавка, но будет управлять мотором, подключённому к клапану. В этом месте мы внесли дискретность в наше устройство, причём не только временнýю, но и по значениям (что поплавок, что серва имеют ограниченный набор допустимых значений). Вот теперь время цикла ардуинки будет очень даже влиять на результат — если я поставлю пять секунд, то мало того, что бачок начнёт наполняться с задержкой, он ещё и запросто может переполниться. Очевидным образом при уменьшении времени дискретизации (увеличении частоты) наша система будет ближе и лучше приближаться к непрерывной (догонит ли Ахиллес черепаху?). Я так понял из вашего отчёта выше, что при 0,01 сек это примерно и произошло и "диаграммы совпали идеально".
Пока что всё просто, это просто азы САУ. Современные средства симуляции позволяют моделировать оба типа систем, равно как и смешанные, гибридные. Тот скриншот, что я показал в комменте к предыдущему посту — это классический пример симуляции дискретной, или последовательной, если будет угодно. Я подогнал результат под SimInTech, но меняя время дискретизации, я безусловно буду влиять на результат. Там всё исполнение в цикле идёт последовательно — вычисление управляющего воздействия контроллером нечёткой логики -> вычисление значений уровня воды и потока, и на следующей итерации (такте) передача их в контроллер (там сдвиговый регистр), и так далее по кругу, никакой "параллельности" там нет и в помине.
Однако LabVIEW Control Design and Simulation Module умеет и в непрерывную систему. Я не стал усложнять там коммент, но установка этого модуля добавляет специальный цикл для симуляции, и вот в нём возможно соединить выход напрямую с входом вот таким образом (что в общем противоречит парадигме потоков данных):

Но это даёт нам ту самую "параллельность" (хотя бы визуальную), когда выход мгновенно распространяется на вход, как если бы наш поплавок был жёстко соединён с клапаном. На самом деле авторы тулкита просто вдохновились Симулинком.
Для симуляции дискретной системы там свои отдкльные инструменты (поэтому и примеры отдельно для разных типов и инструменты для непрерывных и дискретных систем разные).
Цикл симуляции, кстати, универсален, вот посмотрите на его свойства, непрерывное и дискретное время раздельно:

Как я уже отметил выше, при уменьшении времени дискретизации наша дискретная система начинает приближаться к непрерывной, но расчёт с использованием очень большого количества шагов непродуктивен с точки зрения разбазаривания вычислительных ресурсов, поэтому тут всё хитрее — используется Рунге-Кутта с переменным шагом, и шаг уменьшается лишь на сильных изменениях. Так что симуляция в общем всегда дискретна, просто шаг очень маленький. При этом я могу задать требуемую точность симуляции, как относительную, так и абсолютную, а LabVIEW сама подгонит необходимый шаг. Документация: https://www.ni.com/docs/en-US/bundle/labview-control-design-and-simulation-module/page/lvsim/sim_configparams.html?srsltid=AfmBOopYUDq60ORMmPloKvwHHDw7du6r_GpWTyGoCd1bOwyr6plxTNRH Дискретный шаг на симуляцию непрерывной системы не влияет, а лишь на количество данных (но в точках отсчёта данные должны быть валидны).
Если же я выполняю симуляцию чисто дискретной системы, то переключусь вот так:

А так, кстати, там вот что доступно:

(надо будет на досуге разобраться с остальными, а то кроме Рунге-Кутта да Эйлера ничё не знаю). Вот это всё или почти всё есть и в Simulink в той или иной форме. Там, к примеру, также как и в LabVIEW есть как дискретный, так и непрерывный интегратор (https://de.mathworks.com/help/sps/ref/integratordiscreteorcontinuous.html).
SimInTech если верить документации также умеет симулировать как дискретные так и непрерывные системы, причём их можно комбинировать.
Технически мне совершенно понятно, что симуляция непрерывной ("параллельной") системы суть приближение, а уж насколько оно "адекватно"... Самолёты на автопилоте как-то летают, автомобиле на круиз контроле худо-бедно ездят, всё это достаточно адекватно симулируется с достаточной степенью точности. Степень "адекватности" модели для меня — это степень расхождения (отклонения) симуляции и реальной системы, которое может быть измерено. Степень же параллелизма — какое-то размытое эфемерное понятие. Параллелизм — он либо есть либо нет, либо просто выглядит так, как будто он есть, хотя его нет. В остальном вроде всё достаточно понятно, ну мне во всяком случае.
Просто уважемый @lws0954вообще не вкуривает, что он делает. Он сейчас изобретает метод эйлера для численного решения обыкновенных дифференциальных уравнений. Он придумал, что если в автоматах состояния задавать задержку на такт, то получится нивипенно крутое решение, которое по волшебству будет отображать свойства реального мира, поскольку "вычисления не происходя мгновенно" и только его гений сообразил эту задержку вставить в каждый автомат и теперье его система лучшая в мире. И на это единственную задержку на такт он накручивает, инерционности, простраство скоростей и еще единственную истинную и непогрешимую степень параллельность, которой нет ни у кого в мире. Поскольку никто задержку на такт в автомате не учитвает Алилуя.
Ответ же у вас лежит на поверхности:
Степень "адекватности" модели для меня — это степень расхождения (отклонения) симуляции и реальной системы, которое может быть измерено.
Золотые слова! Все что мы делаем в SimInTech Simulink LabView это просто решение обыкновенных диференциальных уравнений численными методами. Заменяем непрерывный процесс, вычислениями сотояния системы в дикретные моменты времени. При этом в решение использутся шаги по времени, чем меньше шаг тем ближе мы к реальной системе (больше точность), но тем больше нужно вычислений. Осюда и балансировка - поиск оптимального шага расчета разными хитрыми методами.
Если нужно учесть дискретность реальной системы, это делается легко и непринужденной в любой среде SimInTech Simulink LabView. Без всяких воистину паральеных автоматов с задержкой по умолчанию.
Для симуляции дискретной системы там свои отдкльные инструменты (поэтому и примеры отдельно для разных типов и инструменты для непрерывных и дискретных систем разные).
Мне кажестя что уважемый @lws0954пытается применить дискретную математику, не совсем понимая диференциальные исчисление отсюда у него куча новых бессмысленных терминов и определений.
Писал, писал и все пропало... :( Попробую повторить ;)
Вы правы. "Степень параллелизма" это несколько не то ;) Нужно смотреть в корень. Он (параллелизм) либо есть, либо нет. Но вот что такое параллелзм? Давайте - в корень. Для этого нужно ответить на вопросы.
Вопрос первый. Что такое програмирование? Попробую ответить (не согласны - подправляйте). Программирование - это процесс кодирования на некотором языке програмирования алгоритмов. Алгоритм - явно главное в этом процессе.
Вопрос второй. Что такой алгоритм? Алгоритм - это описание последовательности каких-либо действий в рамках некой формальной системы. Под этим обычно понимают абстрактную алгоритмическую машину. Модель блок-схем известна всем. Это может быть Машина Тьюринга или что-то иное аналогичное. Та же машина Поста и т.д. Главное здесь - машина. Алгоритмическая модель по-другому.
Вопрос третий. Что такой последовательное программирование? Програмирование в рамках последовательной машины (той же последовательной алгоритмической модели). Здесь главное уточнее - последовательной.
Вот когда согласуем ответы на эти вопросы можно переходить и к четвертому. Вопрос четвертый. Что такое параллельное программирование? .
А если мы ответим на него, то и будет понятно параллельна ли "коробка" LabView? Что осталось или имеется от параллелизма в SimInTech? И параллельна ли ВКПа?
Вот, как-то так, если уточнять понятие "степень параллелизма SimInTech"? Кстати, что на это скажет нам сам товарищь Петухов? После перекура конечно. На свежую, не затуманенную ни чем, так сказать голову... ;)
параллельна ли "коробка" LabView?
Я вроде уже много раз писал, что LabVIEW — суть компилируемый язык программирования. Самый обычный язык, просто представление кода там графическое, а не текстовое, только и всего. Алгоритм — это действительно главное. И вот я беру на себя смелость утверждать, что любой алгоритм (абсолютно любой, без исключений), который можно реализовать, скажем на С++, я могу переписать один-в-один на LabVIEW. Справедливо и обратное утверждение — любой алгоритм, написанный на LabVIEW, можно переписать на С++. Где-то надо будет больше кода, где-то меньше, но в этом алгоритмическом смысле эти языки полностью эквивалентны и С++ вы вроде знаете. Я, кажется, это даже практически показывал, когда мы RS триггер обсуждали. Ну а теперь вопрос к вам — удовлетворяет ли с вашей персональной точки зрения язык программирования С++ вашим личным критериям "параллельного программирования" и какова его "степень параллелизма"?
Ну а теперь вопрос к вам — удовлетворяет ли с вашей персональной точки зрения язык программирования С++ вашим личным критериям "параллельного программирования" и какова его "степень параллелизма"?
Сначала я все-таки ожидал получить ответы на первые три вопроса. Хотя бы. Типа: 1-й - да, 2-й - нет потому-то и потому-то. 3-й ... и т.д. Без ответа на них параллелизм обсуждать бессмысленно, т.к. нет базовых понятий. Они не согласованы. Сначала надо отыскать общие точки, а потом уж обсуждать, строить на них дальнейшие определения...
Про С++. С++ не параллельный язык. "Степень его параллелизма" ;) - обсолютный ноль. Он обычный последовательный язык (см. три вопроса)
Чтобы он стал параллельным я его расширил понятиями активных объектов, имеющих автоматное управление (в моих примерах на С++ это базовый класс LFsaAppl). И затем создал ядро и среду ВКПа, которое эти объекты уже реально делают их активными...
Все. Буквально два щелчка и реальный параллелизм вот он! ;)
Заметим. Без всяких там понятий ядер, потоков, нитей и прочей лабуды. Но, чтобы это понять нужно четкое и однозначное понимание первых трех заданных вопросов. Ну, и затем, конечно, нужен ответ на четвертый! На первые три я дал ответы выше (осталось их согласовать) На четвертый есть ответ в статье на Хабре. Но я егго буду теперь, наверное, обсуждать, зная ,что у нас одинаковые взгляды на первые три вопроса.
...
Про С++. С++ не параллельный язык. "Степень его параллелизма" ;) - обсолютный ноль. Он обычный последовательный язык (см. три вопроса)
Чтобы он стал параллельным я его расширил понятиями активных объектов, имеющих автоматное управление (в моих примерах на С++ это базовый класс LFsaAppl). И затем создал ядро и среду ВКПа, которое эти объекты уже реально делают их активными...
Все. Буквально два щелчка и реальный параллелизм вот он! ;)
На самом деле я с вами согласен. С++ не параллельный язык. Но у меня другой критерий параллельности. Смотрите, еслия я возьму два абсолютно независимых цикла
for (int i = 0; i < N; i++){
x = x + i;
}
for (int j = 0; j < M; j++){
y = y * j;
}
То по умолчанию компилятор выдаст код, выполняющий их последовательно, хотя им абсолютно ничто не мешает выполняться параллельно. А в LabVIEW они автоматом будут исполняться параллельно (до 24 штук, кстати). Чтобы добиться параллельности в С++ мне придётся выполнить пару телодвижений, несложных, но всё же.
Тоже самое и здесь:
for (int i = 0; i < N; i++){
x = x + i;
y = y * i;
}
Этим двум операторам ничто не мешает распараллелиться, но нет.
Однако если идёт зависимость по данным (выключим на время оптимизатор), скажем
for (int i = 0; i < N; i++){
x = x + i;
y = x * 2;
}
То о параллельности мы не говорим.
Комментом ниже вы показали какой результат ВКПа вы считаете правильным с точки зрения параллельного программирования на примере вычисления тривиального выражения "в два щелчка"
a[i + 1] = (a[i] + i) * 2;
И мне в общем всё стало ясно. Также мне стало понятно почему вы считаете "правильную" реализацию триггера мерой степени "параллельности".
И это хорошо. Осталось только убрать кавычки со слов "правильная" и "параллельности". Поскольку речь идет о модели параллельных вычисления, которая не просто "правильная", а именно правильная. И не просто "параллельная", а именно параллельная. Поскольку, во-первых, не доказано обратное, а во-вторых, я не знаю другой универсальной модели параллельных вычислений, аналогичной ей по свойствам. Если, вдруг, знаете было бы интересно о ней узнать и, возможно, даже обсудить ее качества..
Ну не знаю, в примере простейшего алгоритма, который должен был вернуть значения 0, 2, 8, 22, 52 и 114 вы получаете значения 0, 0, 2 ,4, 10, 16 и утверждаете что это правильно и только так и нужно. В прошлом обсуждении триггера мне пришлось также поставить пару сдвиговых регистров крест накрест, чтобы достичь параллельности, о которой вы просили, но тактовый сдвиг, дающий это, там оставался. Я понял, как вы этого достигаете в ВКПа, язык программирования тут вообще не при чём, и ровно того же результата можно добиться дополнительной кодовой обвязкой и в С++ и в LabVIEW, но об эту самую параллельность можно в какой-то момент очень даже нехило обжечься. А так если данные независимы и могут обрабатываться параллельно, то оно вполне себе работает.
Все 4 вопроса - забредушки. Они не стоят времени на их прочтение, не то что обсуждения. С таким же успехом можно обсуждать квантово волновой дуализьм света, как причину истинной паралеьности ВКПа.
Реально в ВКПа в каждый автомат встроена задержка на такт. Все больше там ничего нет от слова совсем. Наличие или отсутсвие этой задрежки никакой паралельности или перпендикулярности в совйства пакета не приносит. Ваша "стпень параллельности", "инерционность автоматов", "пространство скоростей" это фикции головной субстанции которые порождены мозгом не знакомым с основами диференциального исчисления и численных методов решения диференциальных уравнений.
Дайте определение паралельных вычислений, без обращения к вопросам о смысле бытия. Если смотреть в корень, то во все мире используется селедующее определение параллельности:
Исходя из этого определения паралельность возникает, только когда у вас есть многоядерность. Если вы разбили алгоритм на паралельные и независимые вычисления и использует treads или потоки, но у вас один процессор, то никакой паралельности не возникает по определению. Просто ее нет физически. Поэтому ваш термин "степень пралельности" к программноу обеспечению это бессмысленная забредушка, непонятная никому, кто знает про treads или потоки.
Вспомним что схема SimInTech Simulink LabView это не электрическая схема, а просто запись диференциальных уравнений, которые являются моделями каких либо физических процессов. это описание непрерываного процесса. Для решения этих уравнений используется численныме метды разделения непрерывного времени на шаги интегрирования.
При создании моделей в SimInTech Simulink LabView используется набор блоков, которые представляют собой математические выражения, превращающие вход в выход, за один такт расчета. В завимости от используемого математического выражения внутри блока, и схемы их соединения, часть блоков может расчитыватся конкурентно, когда выход блока не зависит от выхода дргого блока и мы можем построить конкурентный механизьм вычисления, который на многоядержном процессоре станет паралельным.
Часть блоков в завимости от математического выражения в них и схемы соединения, требует наличе на входе результата расчета других блоков (возникает алгебраическая петля). Вспонми что мы рассматриваем дискретное приближение непрерываного процесса, у нас есть набор точек по времени. Если нам необходимо значение которые мы еще не рассчитали (из за математического выражения и схемы соединения), мы берем это значение с предыдущего шага расчета тут то и возникакет (задержка на шаг и развязка алгебраических петель). Здесь у нас возникает численная погрешность расчета, которую нужно контролировать, чем меньше шаг тем меньшь погрешность, адаптивные методы еще и меняют шаг на лету, если погрешность выходит за заданные пределы. Либо пишет сообщение, что заданная точность не достигается, когда шаг упал до минимального.
Вот и весь хер да копейки, и никаой параллельности перпендикулярности инерцеонности тут нет.
Часть блоков в завимости от математического выражения в них и схемы соединения, требует наличе на входе результата расчета других блоков (возникает алгебраическая петля).
Йоу, да это одно из лучших описаний парадигмы потоков данных LabVIEW.
Вот, смотрите, у меня есть цикл for на четыре итерации, я беру счётчик итераций (он с нуля начинается, да домножаю его на два, получаю на выходе 0, 2, 4, 6:

Теперь перед умножителем я вкорячу сумматор и заведу выход умножителя на вход сумматора, LabVIEW мне скажет, мол так нельзя:

Это алгебраическая петля. Чтобы разрешить противоречие, мне нужно добавить сдвиговый регистр и перебрасывать данные через него, соответственно сумматор будет получать результат предыдущего умножения, на первой итерации ноль, и на второй ноль, и лишь на третьей прилетит двойка, которая сложится с двойкой и на неё же умножится, что даст 8, и так далее, поэтому будет 0, 2 ,8, 22:

Чтобы не выносить мозг программисту есть и другая запись того что выше, называется Feedback Node, но это просто "синтаксический сахар", просто чтобы было нагляднее, от того, что выше ничем не отличается:

Ну а всё, что не связано потоками данных, будет выполняться параллельно, в примере ниже оба сумматора будут ждать прихода значения индекса, а вот умножители отработают параллельно, и я не могу наверняка утверждать, в каком порядке они будут выполнены - умножение на двойку вперёд умножения на три или наоборот:

и кстати, в Си мне таки придётся повозиться, если я захочу выполнить асинхронно и параллельно что.то типа a *= 2; b *= 3, (оптимизатор может переставить инструкции, если они не влияют на результат, но создавать потоки он точно не будет). На самом деле и LabVIEW не всегда будет ибо накладные расходы на создание потоков тоже ненулевые, но стоит мне взять пару увесистых циклов и они мгновенно сядут на два ядра процессора. Факт в том, что
часть блоков может расчитыватся конкурентно, когда выход блока не зависит от выхода дргого блока и мы можем построить конкурентный механизьм вычисления, который на многоядержном процессоре станет паралельным
лучше и не скажешь.
Красивая анимация. Когда по линии связи как вода ползет утощение. Это в рамках одного шага можно отразить последовательность вычислений? И судя по кнопкам можно последовательно двигатся по сложной схеме в рамках одного такта? Правильно я понимают?
Да, но только анимацией как правило не пользуются, так как глаза полопаются (это больше маркетинговый "вау эффект"). Обычно ставят бряк (точку останова) и пробники на проводочки. Ну вот к примеру, пример с коммента ниже - тут фаззи-контроллер, у него два входа (точнее массив из двух значений) и выход. Соответственно я ставлю пробники и бряк на него и дальше вижу, что ему прилетает на вход и пишется на выход (и я могу и внутрь него зайти если надо, и увидеть почему значения именно такие). Всё как у людей, там Step Into, Step Over и т.д.:

Ну и дальше можно отлаживаться пошагово. Точки останова могут иметь условия (если больше или меньше порога, то вставай, а иначе беги дальше)
Останов по условию и окна у нас тоже есть.
А вот анимация по линиям очень прикольная, толко вот у нас обычно происходит сортировка схема, где мы перед началом расчета производим анализ и определеяем что считается первым и чисто теоретически может получится так что порядок расчета не совпадает с порядком отображения например если блок интегратор то мы из него берем текущее заначение сразу, несмотря на то что по схеме в него входит какой либо источник.
А можно посмотреть такю анимацию когда синус подается на интегратор а потом усилитель. Интересно как текущая вода по линиям связи это отразит.
Да в общем ничего особенного, там четыре скорости есть (я иконки блоков у вас утащил чтоб аутентичненько было):

Я обычно подсветкой выполнения пользуюсь тогда, когда влетев в какой-нибудь блок всё встаёт колом, и тогда подсветка может мне показать, где я вообще в коде нахожусь. Ну или что-то совсем несложное отладить или просто выполнение замедлить.
А, да, и результаты:
Вот LabVIEW:

А вот Simulation In Technic:

Ну в общем было бы странно, если бы они принципиально отличались.
Стрелочек на проводникак в LabVIEW нет, они появляются лишь тогда, когда поток данных разбит и вызывает ошибку (в случае петли или просто выход не подключен), тогда вот так:

Такая логика в общем не мешает, как-то у LabVIEW программистов негласно принято, что поток данных распространяется слева направо и любая диаграмма по правилам хорошего стиля должна укладываться в один экран (поэтому на работе у меня моник в тридцать дюймов).
Попробовал освоить отладку в SimInTech.Похоже, я до ее уровня еще не дорос. Не осилил. В С++ сильно проще и, главное, все понятно ;)
Йо-хо-хо, и бутылка рома! Это уже разговор веселый пошел!. Попробую и я соорудить что-то подобное. Одна проблема - надо как-то массивы отобразить...
Ща, попробуем...:)
Докладаю...
Вот это я собрал в ВКПа и получил следующее:

Здесь изображен эквивалент схемы в ВКПа, созданный в SimInTech.
Последний такое не разрешает - они в 18-м веке, а потому вот что получилось здесь.

Верхняя схема - это удовлетворил просьбу на удаление петли.
Ниже - схема, эквивалентная ВКПа. И - о, чудо! - график точь в точь такой, как и в ВКПа. Так что, Вячеслав, еще не все потеряно - 21 век еще может вас принять в свои объятия! Пока не поздно - решайтесь! Но теорию подтянуть надо. ;)
И что же у нас получается в 18-веке Эйлер предложил способ замены непрерывных процессов дикретных вычислениям. И мы все ими пользуемся. А в 21 уважемый @lws0954предложил изменть операцию суммирования. По его мнению любое сложение, любое умножение и деление должно сдивгать вермя на один шаг интегрирования для получени исконнно посконной высшей степени параллельности! Добрпожаловать в 21 век!
И теперь все наши расчеты идут по звезде. Это новое слово в математике операция сложения перстала быть переместительной. Всю жизнь с времен тысячи лет со времен Пифагора а+b+c = (a+b)+c теперь благодорая гениальности ВКПа высшей степени паралельность это нихуа не разу не так. Теперь меняя последовательность сложения можно получит разницу в 25 000 тысяч за 10 секунд. И меняя шаг интегирования можно получит и больше разницу.
Алилуя!

А если используя блоки ВКПа записать вот такое выражение:

Насколько шагов интегрирования сдвинитеся вычисление импульса в ячейке турбопровода сможете посчитать?
Насамом деле пох, главное мы получим истинную степень паралелизьма ВКПа, а это главное добро пожаловать в 21-век и в истиную теорию праралелизьма.
Короче выкидывайте нахрен ваши бесмысленные забредушки почитайте что нибудь про решение дифференциалных уравнений методом Эйлера. Все уже давно придумано и отлично работает. Как 2+2 = 4.
Вы отказались давать ответы на три заданных ранее вопроса, послав их в 18-й век. Ваше право, но Вы не правы. Причем серьезно. Вы не понимаете разницу между сложением, как операцией и сложением, как процессом. Это принципиально разные вещи. Эту разницу надо понимать, ощущать и правильно применять. А у Вас в голове каша.. Над этим надо работать, но Вы, похоже, принципиально уперлись в 18-й век, когда про алгоритмы (в нынешнем понимании) понятия не имели. Все это достаточно плачевно. Даже не для Вас, а для ... SimInTech.Вы и его запрете в 18-м веке. Хочется, чтобы до этого дело не дошло. Надеюсь, что конкуренты Вас наставят на путь истиный ;)
А зечем мне понимать эту разницу? Если я использую математические операци для расчета физических процессов, меня интересует именно операция сложения и умножения, поскольку с помоощю этих операций я записываю выражения законов физики. Мне нужна величина рассчитанная по физической формуле, а как она получена на пальцах, полачках, счетах или CPU вообще не ипет. Мне нужно получит результат причем как можно скорее, для этого и придумали паралельные вычисления и многоядерные системы. А до этого придумали математику и ее правила вычисления операций. А уже с помщю математике записываются физические законы.
А вы выдумали неведомую никому истинную степень паралеллизьма, которя не в звезду не в красную армию, зачем?
Докладаю...
Вот это я собрал в ВКПа и получил следующее:

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

Верхняя схема - это удовлетворил просьбу на удаление петли.
Ниже - схема, эквивалентная ВКПа. И - о, чудо! - график точь в точь такой, как и в ВКПа. Так что, Вячеслав, еще не все потеряно - 21 век еще может вас принять в свои объятия! Пока не поздно - решайтесь! Но теорию подтянуть надо. ;)
PS
Да, результат из LabView (см. выше) 0, 2 ,8, 22: что-то, похоже, не вкорячивается... :( Как это?
Да, результат из LabView (см. выше) 0, 2 ,8, 22: что-то, похоже, не вкорячивается... :( Как это?
Вот так:
int main (int argc, char *argv[])
{
int shift_reg = 0;
for (int i = 0; i < 4; i++){
int out = (shift_reg + i) * 2;
printf ("Result is %d at cycle %d\n", out, i);
shift_reg = out;
}
return 0;
}
И вот:
Result is 0 at cycle 0
Result is 2 at cycle 1
Result is 8 at cycle 2
Result is 22 at cycle 3
Я не знаю, как ещё проще эту конструкцию объяснить

Да и тут тоже 0 2 8 22, что характерно:

Так ведь получается полная и окончательная уета! Используюя задержку на шаг в математических вычислениях, где никакой задержки отродясь не было, мы получаем "всевысшую степень пралельности", но уже не можем ничего посчитать по математическим формулам поскольку задержка вычислений теперь у нас зависит от последовательности вычислений. И теперь все что придумал старина Эйлер в численных методах решения непрерывынх дифференциальных уравнений, где использутся вычисления на декретных шагах интегрирования, идет по зведе! Алилуя зато мы достигли "всевышенй степени пралелизьма".
Но самое смешное во всей это истинной параллельности, в том, что она нах никому не нужна. В самом деле зачем во всем мире используется паралельные вычисления? Что бы ускорить расчет, за счет возможностей запуска конкурентных вычислений на разных ядрах процессора. Что предлагает уважаемый @lws0954добавить задержку на шаг в каждую математитическую операцию! Ошуенное решение что бы ускорить расчет давайте заипенем задережк. Будет медленнее зато "степень паралелизьма будет всевышашая" ибо все языки последовательные а добавив задержек мы достигним абсолютной паралельности и нирваны.
На самом деле есть целы книги посвященные паралельному программированию, даются готовый и проверенные методики изменения кода, для реализации конкурентных вычислений, которые становятся параллельными на многоядерных системах, без всяких никому не нужных задержках.
В самом деле зачем во всем мире используется паралельные вычисления? Что бы ускорить расчет, за счет возможностей запуска конкурентных вычислений на разных ядрах процессора.
Это самая большая глупость, оправдыающая необходимость использования параллельных вычислений. Главное в них не скорость, а их возможность строить намного более сложные и эффективные решения - параллельные. Скорость - дело десятое, если не больше. Главное, создавать новые решения, складывая их из готовых кубиков, работающих параллельно.
Параллельные решения порождают новые алгоритмы сами по себе. Триггер - простейший пример. Нейронные сети - другой. Но принцип и там и там один - параллелизм. Об этом не знали в 18-м веке, не все, но догадваются в 21-м. И где-то неосознанно, но по полной их используют. Тот же прорыв в ИИ.
А Вы... 18-й век ,18-й век, Эйлер, Эйлер.... Эйлер - гений и был бы жив, думаю разобрался бы и с алгоритмами. С параллельными, конечно ;).
Ниже - схема, эквивалентная ВКПа. И - о, чудо! - график точь в точь такой, как и в ВКПа.
УРА! Глядя на ваш результат 0, 0, 2, 4, 10, 16 я, кажется понял глубоко сакральный смысл ПАРАЛЛЕЛьНОСТИ ВКПа!
Судя по всему, в вашем параллельном мире вы пытаетесь выполнить сложение и умножение параллельно. Но поскольку они зависимы по данным, вам приходится вкорячивать вторую задержку, чтобы иметь возможность начать умножение не дожидаясь результата сложения.
Я тоже так могу, это две диаграммы одинаковы, просто чтоб понятнее было, и вот откуда берутся ваши 0, 0, 2, 4, 10, 16:

И да, тут код выполняется параллельно, только результат не очень.
Если всё ещё не понятно, то вот эквивалент на Си, в предположении что наш Си умеет исполнять параллельно операторы, расположенные на одной строчке:
#include <ansi_c.h>
int main (int argc, char *argv[])
{
int mul = 0;
int add = 0;
for (int i = 0; i < 6; i++){
#pragma parallel
int add_out = (mul + i); int mul_out = (add * 2);
printf ("Result is %d at cycle %d\n", mul_out, i);
mul = mul_out; add = add_out;
}
return 0;
}
И результат тот же:
Result is 0 at cycle 0
Result is 0 at cycle 1
Result is 2 at cycle 2
Result is 4 at cycle 3
Result is 10 at cycle 4
Result is 16 at cycle 5
Более того, я могу разнести умножение и сложение в два отдельных цикла и они будучи независимымы, вполне себе буду бежать параллельно с тем же результатом:

Вот только в реальном мире мы зависимы по данным. Умножению нужен результат сложения, а сложению - результат умножения, поэтому я не имею права вставлять в очередь элемент для умножения, мне нельзя начинать его, не дождавшись результат сложения! Так что вот вам "правильная" параллельность:

Да только нет её тут, потому что автомат выполняющий умножение ждёт результата автомата, выполняющего сложение.
Офигенно увлекательная дискуссия.
Да именно эти задержки уважаемый @lws0954придумал втыкать в каждый автомат и объявил это высшей степенью паралелизьма. А все суматоры умножители и делители без задержка объявил некошерными, а триггер с запретом состояний у него вобще порождения сатаны, захватившего души непосвященные в истинный свет единственно верного и паралельного ученья ВКПа.
А, кстати, я начинаю понимать уважаемого @lws0954 , вот смотрите. допустим есть вот такая диаграмма, здесь симуляция идёт с шагом 1, рампа входная тоже с шагом 1, результат на выходе - шесть значений 0, 2, 8, 22, 52 и 114. На каждом шаге считается a[i+1] = (a[i] + i) * 2; Начальное а[0] = 0 разумеется:

Но беда в том, что сначала выполняется сложение, а потом умножение и никак иначе. И вот теперь я отчаянно возжелал выполнять умножение и сложение параллельно. Чтобы развязать эти операции я вкорячу вторую задержку (как выше было показано это таки даст возможность распараллелить эти операции). Но при единичном шаге результат сильно неверный. Но теперь я буду сильно уменьшать шаг симуляции, который в пределе стремится к нулю, я поставил 1E-5 и соответственно я буду уменьшать степень усиления, ну и шаг рампы тоже ну очень маленький, я эмпирически подогнал 5.5E-5 и вот смотрите, вуаля, я практически вписался в референсные точки:

То есть мы приходим к тому, что при бесконечно малом шаге симуляции все математические операции таки можно выполнять параллельно. Пора открывать новую страницу в математике.Хотя в данном конкретном случае простая полиномиальная интерполяция вероятно сразу даст ответ в любой точке, ну да ладно.
Согласен. При бесконечно малом шаге, конечно это верно. Только у нас вся математика со времен Эйлера бьется над проблемой увеличение шага интегрирования дифференциальных уравнений, с сохранением заданной точности. Потому что нужно сократить количество вычислений, что бы получить результат быстрее. И некошерные паралельные вычислений, тоже для сокращения времени вычислений вообще то используются.
А зедсь наоборот делам 10 000 вычислений на секунду модельного времени, за то у нас воистину паралельная программа. Да мы считаем в 5 000 медленнее но на двух процессорах или в 2 500 разм меделенне но на 4 процессорах, если у нас будет 10 000 процессоров мы вообще посчитает так же как без истинного паралелизьма.
Ну да, тут работает простая арифметика, основанная на том факте, что при малом приращении шага изменения настолько малы, что пофиг на то, что мы берём часть результатов из соседнего шага, ошибка не успевает набегать. Вероятно под это дело можно подвести и строгое математическое обоснование, но практическая применимость этой фишки сильно ограничена необходимостью дикого количества итераций плюс надо автоматом корёжить вычисления, чтоб результат сошёлся.
"Корежить" ни что не надо. Вычисления идут своим чередом, что до использования автоматов, что после их применения. И задержка нужна для моделирования инерционности процессов. Процессов, но не обычных расчетов. Еще раз - процессов. Еще раз - процессов!!! Их иненрционность - святое. Боженьку (или того, кто их придумал) не обйдешь!
Действия (расчеты), как часть этих процессов могут реализоваться обычным образом. Действия - это обычные функции, реализованные средствами обычных языков програмирования. Их сложнность ни чем не ограничивается. Нужен миллион сложений - используйте миллион. Но учитывайте, что этот миллион требует тоже времени. И это время не должно превышать время дискретного такта. А если время такта маленькое в силу необходимости, то этот миллион разделяется на части которые укладываются в дискретный такт. Все просто до безобразия. Но вот только, похоже, эта простота почеиу-то сложно доходит. Меня это жутко удивляет. Но это факт, который сложно не замечать :).
Ни кто ни кого не заставляет применять автоматы. Речь идет о применении автоматной модели вычисления, которая лучше и удобнее той, что используется. Например, я могу представит во что бы мне вылилось вычисление интеграла (в реальном времени) при обычном (многопоточном) подходе. Автоматное его решение - просто до безобразия. Да, точность повышается за счет уменьшения дискретного шага. Ну и что? Чем кому-то мешает, ну, очень маленький шаг дискретизации точного интеграла? Мне нет. Это не проблема. От слова совсем. Да такт этот не обязательно маленький, если точность не требуется, и делается это так ,что не влияет на время работы других процессов, которым по фиг проблема точности интеграла. Да применяй, если так уж нужно, любые приемы повышения точности интегрирования. В чем проблема? В автоматах? Да нет - в головах :(.
И вообще для параллельных вычислений автоматы - не самое главное. Не проблема использовать другую модель. Здесь главное, основное, что 1) процессы живут в дискретном времени 2) процессы, составляющие единую модель работают в едином дискретном времени и 3) должна быть правильная работа с памятью.. Все. Точка. Своеобразная комбинация "из трех пальцев" :)
Автоматы нужны, чтобы иметь алгебру процессов. Чтобы не путаться в "трех пальцах". Если вам эта математика по барабану, то вам не нужны и автоматы. Если вам по барабану корректная работа процессов, то вам не нужно и дискретное время. И тогда у вас то, о чем вы мечтаете - потоки, ядра и т.п. А то, какая будет при этом последовательность данных (см. наш пример) - это уже дело случая, искусство разработчика и его понимания создаваемой модели.
Что бы понять насколько перпендикулярна ваша "истинная исконно посконная степень параралелизьма", к традиционным неизвращеннны и общепринятым понятиям о паралельных вычисления приведу цитату из классика в паралельных вычислениях:
Algorithms with State
The first example of code that cannot be executed concurrently is algorithms, functions, or procedures that contain a state. That is, something kept around from one execution to the next. For example, the seed to a random number generator or the file pointer for I/O would be considered state. Algorithms with state cannot be made directly concurrent, and whenever you encounter such code, a red flag should go up when you are considering concurrency. However, you may be able to take steps to render the code thread-safe, which may be sufficient.
You can make state-filled code thread-safe by adding some form of synchronization or writing the code to be reentrant (i.e., it can be reentered without detrimental side effects while it is already running). The former option will serialize all concurrent executions of the synchronized code (and add unnecessary overhead when not called concurrently), while the latter option may not be possible if the update of global variables is part of the code.
If the variable(s) holding the state does not have to be shared between threads, you can use TLS to overcome this dependence. Using TLS, each thread would have a separate copy of the state variable(s) (accessed in exactly the same way across all threads) to ensure there are no data races on the variable(s). Thus, each thread can have a different random number seed and use the same code to generate a separate stream of numbers that will not interfere with any other thread’s seed.
Алогритм с состоянием, не может быть напрямую сделан конкурентным (а значит и параллельным на многоядерной системе) и если у вас есть подобный код красный флаг должен подниматся когда вы рассматривает конкретность.
Просто во всем мире принятое так. Если после распаралеливания результат вычислений отличается значит получилась huiня. А у вам на это пох. Если перестал совпадать результат - сделайте меньше шаг и ошибка будет меньше, ибо истинная степень паралельности не требует точного совпадения результата. До слез!
И задержка нужна для моделирования процессов. Процессов, но не обычных расчетов. Еще раз - процессов. Действия (расчеты), как часть этих процессов могут реализоваться обычным образом. Действия - это обычные функции, реализованные средствами обычных языков програмирования. Их сложнность ни чем не ограничивается. Нужен миллион сложений - используйте миллион.
Ну спасибо хоть, не нужно ставить задержку на шаг в каждую математическую операцию это на самом деле реальный прогрес.
Но про моделирование процессов вы продолжает нести дичайшую дичь. Все придумали до вас Эйлер и Лагранж. То, что вы пытаетесь изобрести для моделирования непрерывных процессов, давно исследовано и решено математиками в 18 веке. В общеприятой математике это называется система диференциальных уравнений в общих производных. (производных по времени). И ваша безумная выдуманная ибессмысленная задержка, в этой теории тоже описана и используется. В математике и в системах моделирования, это просто шаг интегрирования, базовое понятие при численном решении диференциальных уравнений в общих производных. А поскольку это базовое понятие, то оно широко используется во всех формулах. Вот классика метод Рунге_Кута
Я старательно пытаюсь разобраться в этом потоке сознания, но не могу.
задержка нужна для моделирования инерционности процессов. Процессов, но не обычных расчетов. Еще раз - процессов. Еще раз - процессов!!! Их иненрционность - святое.
Инерционность инерционности рознь. Я примерно в курсе как бороться с инерционностью процесса, скажем используя предиктор Смита (пятьдесят седьмой год, кстати), но слабо вкуриваю, как можно делать это тривиальными тактовыми задержками. Где-то это и будет работать, но далеко не везде.
сложнность ни чем не ограничивается. Нужен миллион сложений - используйте миллион. Но учитывайте, что этот миллион требует тоже времени. И это время не должно превышать время дискретного такта. А если время такта маленькое в силу необходимости, то этот миллион разделяется на части
Вообще всё в кучу. Если я моделирую процес срабатывания воздушной подушки, что составляет миллисекунды, то мне нафиг не упало укладываться в те же миллисекунды процессорного времени. Если мне нужны сутки для обсчёта, пусть будут сутки, главное - реалистичный и адекватный результат. Реалтайм-то хоть не трогайте.
должна быть правильная работа с памятью.
Правильная работа с памятью - это понимание атомарности, спинлоков, состояния гонок, и т.д. и т.п., это-то всё тут при чём? Я в общем хорошо понимаю как устроена и работает та железка, на которой я пишу этот коммент. У вас там в ВКПа я слышал есть теневые переменные или теневая память, или как-то так, я сильно подозреваю для хранения всяких данных во время задержек, используемых для борьбы со святой инерционностью процессов, но к "правильной работе с памятью" это слабо относится. Давайте ешё кеш сюда до кучи добавим, что ли.
На мой взгляд, вы всё, вообще всё смешали в одной большой кастрюле и теперь вывариваете это дело на медленном огне.
Только у нас вся математика со времен Эйлера бьется над проблемой увеличение шага интегрирования дифференциальных уравнений, с сохранением заданной точности.
В 21-м веке таких проблем в большинстве случаев нет. "Калькуляторы" другие ;)
То есть мы приходим к тому, что при бесконечно малом шаге симуляции все математические операции таки можно выполнять параллельно.
Так, так.... еще чуть-чуть и все будет Вам понятно. Вы только что переоткрыли принцип дискретной Киберненики. :)
В 21-м веке таких проблем в большинстве случаев нет. "Калькуляторы" другие ;)
В каком большинстве случаев? У меня сейчас в офисе крутятся модели всех существующих в мире техники устройств, спутник, самолеты, ракет, атомные подводные лодки, реакторы, системы поводной добычи газа, и даже автомобили электрические, и у всех одна проблема - скорость вычислений и одна задача балансировка скорости и заданной точности. Калькулятор конечно стал другим, но физику и математику не обманешь. Теорию пределов изминить не получится. И даже "воистину истенное учение про степени параллелизма" не поможет ни разу.
Вот например класика жанра уравнение Ван Дерполя из двух строк, вешает любую ситему при коэффицеиентах больше
У вас как со школьной арифметикой? Степени помните?
У меня калькулятор 3.8 GHz и десять ядер. Это Гц
Представим что ваша воситину пралалельная ВКПа, делает вычисления за один такт. Открываем SimInTech и смотрим какой шаг нужно для получения точного ответа для уравнеия Вандерполя при этих условия это . Сколько будет считать 1 секунду модельного времния волшенбаня единственно востину паралельная система ВКПа? Даже если предположить что она будет в один такт укладываться со всеми своим скаральным пралелизьмом вычислениями делим одно на другое получаем
сек или 73 099 часов или 3 045 суток или 8 лет.
8 лет будет воистину паралельная ВКПа считать 1 секунду процесса (с малым, но не бесконечно малым шагом), потому что калькуляторы другие, конечно если использовать счеты как во времена Эйлера то это расчет занял бы примерно 8 млиионов лет, прогресс не остановить. Только вот с правктической точки зрения и 8 лет и 8 миллионв лет на расчет одной секунды процесса, это величины бесконечные и бесконечно бесполезные. Нах никому такие вычисления не нужны.

Так, так.... еще чуть-чуть и все будет Вам понятно. Вы только что переоткрыли принцип дискретной Киберненики. :)
Он уже лет 80 давно всем известнее, только вам он пока недоступен, поскольку диференциальное исчисление еще не изучили :) А ведь в книжке которую вы цитирования прямо написано, что она предназначена для тех кто диференциальное исчисление уже освоил, не говоря уже о теории пределов.
Не зря предупреждали на неокрепшие умы дискретная Кибернетика производит разрушеюшие воздействие!!!!
На все это могу сказать лишь одно - все, что считается/моделируется в SimInTech будет считаться/моделироваться и в ВКПа. Я уже это Вам показал не раз. Вас это не убедило? Какие Вам доказательства еще нужны?
Конечно будет, если вы выкините забредушки с "инерционостюю", "всевысшей степению паралельности", "простраства скоростей" и прочий бред, а просто запишите прямые математические выражения, без всяких автоматов с задержками. Все не только будет считать но даже и совпадать с расчетами методом Эйлера, поскольку ровоно это вы и пытаетсь упорно переизобрести. И все тоже можно реализовать и на Си и на Фортране, весь вопрос сколько времени это займет и насколько готовые библиотеки SimInTech ускорят процесс создания и отладки модели.
Но вот вам прекрасный пример задача Ван Дер Поля.
init y1=2, y2=0;
mu=1e14;
y1'= y2;
y2'= mu*((1-y1^2)*y2-y1);
output y1,y2;
посчитайте 2 секунды процесса вы очень удивитесь
А у нас в реальных процесса такой вандерполь в каждой второй модели, а в каждой первой их два.
все, что считается/моделируется в SimInTech будет считаться/моделироваться и в ВКПа.
Кстати, справедливо и обратное утверждение — все, что считается/моделируется в ВКПа будет считаться/моделироваться и в SimInTech. И даже если относительная высокоуровневость SimInTech не позволит что-либо реализовать (я не профи в этом), то можно перефразировать как "все, что считается/моделируется в ВКПа будет считаться/моделироваться и в LabVIEW". Есть пакет Control Design and Simulation Module. Если мне по какой-то причине не хватит его возможностей, я спущусь на уровень ниже и допишу недостающее прямо в LabVIEW, со всеми необходимыми параллельностями, задержками, активными объектами и автоматами. Если же мне не хватит возможностей (или производительности) LabVIEW, я спущусь ещё ниже ниже и напишу недостающее на Си, сделаю библиотеки и подключу их. На чём сама по себе ВКПа написана-то? На некошерных плюсплюсах вроде, насколько я знаю? "Надстроить" ВКПа можно и в LabVIEW, но зачем?. И я помню триггер, и по-моему всё, что вы попросили меня продемонстрировать, я вам тогда показал и объяснил.
Кстати, справедливо и обратное утверждение
Формально - да. Реально - могут быть проблемы. Дьявол в деталях. В сложности достичь желаемое. Я заценил Ваши последние посты. Сложно. Хотя до этого на простом примере все уже было ясно. Кстати, я решил повторить результат в LabView, т.е. получить - 0, 2, 8, 22... У меня получилось 0, 0, 2, 8, 22, 52, ... Куда делся первый 0. Хотя, рассуждая, Вы о нем и говорили. Но при демонстрации его что-то не видно.
ВКПа - да на С++. Для меня это самый-самый кошерный язык :). Си - отстой. Потому что без объектов. По-другому - совсем не то. Для меня любой язык без объектов - отстой.
"Надстроить" ВКПа можно и в LabVIEW, но зачем?.
Насчет "надстроить" к LabView - сомневаюсь. Скорее наоборот - к ВКПа LabView. Но это мое мнение. Поскольку сомнительно, что в LabView процессы будут такие же, как в ВКПа. Но это длинный разговор...
К триггеру можно было бы вернуться, т.к. были и остались, как мне представляется, там проблемы. Опять же - навскидку. Надо восстанавливать и, может, что-то сделать по новой.
Здесь Вы тоже чего-то добиваетесь. Но делается это достаточно сложно после определенных уточнений, а не автоматом (автоматически в смысле), как в ВКПа. И не надо здесь залезать в "ватерполя", чтобы выяснить что-то наглядно. Нужно упрощать. Клапан и бак - хорошо, но арифметический пример - много лучше и нагляднее. Нужно немного фантазии. Типа - Клапан - сумматор, Бак - умножение. И все ясно и понятно. И "полет мысли" тогда почти очевиден. Как в случае с триггером ;) И не нужно забывать про неотвеченные три "простых" вопроса. Мы с ними так и не разобрались... А, ведь, есть еще и четвертый... ;)
Насчет "надстроить" к LabView - сомневаюсь.
Вы совершенно напрасно сомневаетесь, поскольку я взял на себя смелость утвержать, что всё, что вы сделали на С++ я могу реализовать и на LabVIEW, соответственно если вы смогли это дело надстроить над С++, то я смогу это повторить. У меня тоже есть ООП и классы, кроме того есть акторы в придачу, и три разных тулкита для конечных автоматов и один для симуляции. Более того я это ещё и визуально решу, так что вам в Visio не придётся рисовать автоматы, они будут прямо в среде. У меня был проект, в котором вся логика конечного автомата подгружалась извне, то есть один "генерализованный" автомат выполнял другой (там всё довольно просто, поскольку у нас всего две сущности — состояние и переход между ними).
Пробежав по простыне комментов выше, я вдруг задумался, откуда вы по большому счёту вообще всё это взяли? Ну не могли вы сами придумать вот это вот всё то, что ваш тёзка вежливо называет "бесмысленными забредушками". Сегодня утром за чашкой кофе я решил таки освежить свои знания теории автоматов да полистал учебники, и кажется понял.
Да, верно, есть такая штука, как последовательная и параллельная декомпозиции конечных автоматов. И говоря о том, "последовательна" или "параллельна" система вы судя по всему имеете ввиду именно эти декомпозиции, утверждая при этом ВКПа истинно параллельна. И про вопрос о задержках я теперь понял, вы имеете ввиду их распространение в таких средах, перефразируя, можно ли меняя задержки выяснить, выполена ли последовательная или параллельная декомпозиции? Действительно, вы имеете полное право проводить параллельную декомпозицию конечных автоматов, но с одной малюсенькой оговоркой. Полученные параллельные автоматы должны быть ортогонально конгруэнтны. Формально выражаясь языком учебника "если на множестве состояний автомата А существует две ортогональные конгруэнции а1 и а2, то пара независимо работающих фактор-автоматов А/а1 и А/а2 реализуют исходный автомат А", и это можно доказать. Таким образом для выполнения параллельной декомпозиции конечного автомата необходимо произвести поиск конгруэнций, построить диаграммы Хассе решёток конгруэнции и лишь после этого параллелить.
С какого-то перепугу вы решили что можете произвести параллельную декомпозицию вообще любого конечного автомата. Но поскольку далеко не в каждом автомате можно изыскать ортогональные конгруэнции, и вы привносите их искусственно, добавляя "задержки", попутно аргументируя их мистической "инерционностью процессов". Внесённые задержки судя по всему двигают состояния по графу, делая возможной параллельную декомпозицию, вот только результат иногда не очень, и вы начинаете постить графики "в вашей последовательной среде вот так, а в моём параллельном мире вот этак" и давайте объясните мне, почему бы это. Вот как буквально только что — вы спрашиваете куда делся дополнительный ноль в последовательности 0, 2, 8, 22. Я же привёл вам Си код выше, там ровно десять строчек, посмотрите. А у вас 0, 0, 2, 8 и вы не можете понять откуда он берётся в вашей же среде? Сильно подозреваю, что вы снова сместились на такт и он выплюнул вам дополнительный нуль. Вообще для этого обычно существует режим пошаговой отладки.
Вопросы декомпозиции автоматов рассматриваются в куче учебников (в том числе вопросы генеральной параллелизации автоматов). В реальной же жизни мы прагматически смотрим на систему и просто и смело параллелим то, что параллелится и не трогаем то, что трогать не надо, вот и всё. При этом мы не анализируем дотошно, но в теории да, можно проанализировать и найти все суб-автоматы, которые могут быть выполнены параллельно. На самом деле LabVIEW частично делает это за меня, анализируя граф выполнения блок-диаграммы, разбивая его на "чанки", которые и выполняются параллельно (при этом она достаточно умна, чтобы не параллелить всё и вся, а лишь то, где я получу выигрыш) и само собой разумеется на конечный результат это влиять не будет. Кстати, хорошая мысль, в том проекте, где автомат конфигурируется "налету" я действительно могу провести такой анализ.
Если всему, что вы пишете про "абсолютный параллелизм" есть формальное теоретическое обоснование, ткните меня носом в учебник и параграф, в котором эта теория изложена и строго доказана, я с удовольствием почитаю на досуге.
Я всегда готов и мне приятно общаться с человеком, который хочет вникнуть. Причем на серьезном, как можно понять, уровне. А не сразу - а "нахуа" (привет Вячеславу;)?
Давайте начнем, может быть, сначала. С моей статьи. Автоматное програмирование: определение, модель, реализация. Ее читали?
Только не по диагонали, а задавая конкретные вопросы, если что-то не ясно. И не пропуская ответы на мои, если я ихзадам. Чтобы не так, как с предыдущей моей "тройкой".
Её я читал, и вы там лихо проводите декомпозицию триггера (кстати, вы это сами придумали или где-нибудь вычитали?), но при этом у вас там появляются синхронизирующие связи (кажется в алгебраической теории это называется стягивающие компоненты для получения стягивающего действия и в некоторых случаях стягивающий автомат представляет собой именно задерживающий элемент) и наличие таких связей (а они появляются как раз из-за наличия обратной связи) мгновенно переводит параллельно декомпозированный автомат просто в форму групповых компонентов, как это и происходит в простейшем примере, что выдаёт нам 0, 2, 8, 22. Я там безусловно могу выполнить декомпозицию на два автомата, но у меня будет синхронизирующая связь, причём так устроенная, что прибьёт параллелизм на корню, я такие автоматы истинно параллельными не считаю. Где-то у меня дома валялась книжка, годов шестидесятых, Хартманис, кажется, надо будет почитать, равно как на досуге смастрячить пример конечного автомата, демонстрирующий истинную параллельность, это несложно должно быть.
Я всё равно считаю, что далеко не каждый автомат можно вот так вот запросто перевести в параллельную форму. Более того, не каждый алгоритм вообще можно переложить на автоматную модель. Ну вот попробуйте два двоичных числа перемножить конечным автоматом, что ли.
Ну вот попробуйте два двоичных числа перемножить конечным автоматом, что ли.
Без проблем. Легко. Как бы Вы сказали, - лихо :) Одно состояние, при нем "безусловная петля" (петля, на которой условие перехода - прочерк), на ней действие - y = a*b. Здесь a, b - входы автомата, y - выход.Да, действие в этом случае - это любая функция не возвращающая значения.
По поводу операций с автоматами. Да - сам. Ну, конечно, опираясь на что-то, точнее, кого-то. Это С.Баранов и А.Мелихов. Могу даже выслать электронные варианты этих книг. Но, опять же, это только база. Дальше - мое. Собственно, об этом и статья.
А теперь у меня к Вам вопрос. Мой. Стандартный :). Начнем самого простого. Даже проще, чем умножение чисел. Создайте автоматную модель логического элемента И-НЕ (она может быть вполне будет другая, а не как у меня в статье)..
Заметьте, это очень серьезно (хотелось бы далее не уточнять, что все мои вопросы - серьезные ;).
Ну вот попробуйте два двоичных числа перемножить конечным автоматом, что ли. Без проблем. Легко. Как бы Вы сказали, - лихо
Это сильное заявление, весьма сильное. Смотрите, предположим то, что такой конечный автомат реально существует. Пусть он имеет n состояний. Подадим на вход этого автомата два одинаковых двоичных числа 2^(n+1). Каждое из этих чисел записывается n+2 двоичными разрядами. Наш автомат, выполняющий умножение, получает на вход n+1 пар нулей, за которыми следует пара единиц — последовательное представление пары входных аргументов. Автомат (если он существует) должен выдать в качестве результата число 2^(2n+2), то есть он должен выдать 2n+2 нуля, за которыми следует единица. Иными словами, после того как автомат получит n+2 входных сигналов, он, перейдя в автономный режим, должен выдать ещё n нулей, за которыми он должен выдать единицу. Однако очевидно (уж вам должно быть точно), что никакой конечный автомат с n состояниями, работая в автономном режиме (под действием только входных сигналов синхронизации), не может выдать на выход n нулей, за которыми следует единица по той простой причине, что максимальный цикл в автомате с n состояниями ну никак не может превышать n. Вот и всё, приехали. Вообще невозможность построения такого автомата для решения этой проблемки является отражением того, что объём информации которую должен был бы "помнить" такой автомат, неограниченно растёт с ростом значений исходных чисел.
Другое дело — сложение, тут да, достаточно иметь только два состояния, одно из которых помнит наличие, а другое — отсутствие переноса в следующий разряд. Но я задал вопрос именно про умножение.
У Вас "классическое" представление об автомате. Заставить машину летать - можно, но "нахуа", как сказал бы уважаемый Вячеслав. Наша цель, ведь, Ван Дер Поль. Правильно? У его Вашим автоматом не взять. А потому каждый должен заниматься своим делом.
Автомат выполняет хорошо функции управления. Вспомним машину Тьюринга. В ней есть управления, т.е любимый нами автомат (см. мою статью на эту тему), н есть и операции. Конечно, у нас они мощнее, чем у МТ. Это будет любая арифметическая операция. Вот автомат запуском этих операций и управляет. Кто в это не верит, пусть запустит ВКПа ;)
Но, серьезно. Автомату автоматово. Смотрите на мое определение модели автоматного програмирования. Возможно это "мощно" - не знаю. Но именно так надо смотреть на роль автоматов, а не то, как Вы описали.
Конечно, напрямую автомат не выполнит умножение. Ну и что. Миру на это наплевать. Мир делает миккропрограммные автоматы. Где БУ - блок управления на автомате а ОП - операционный блок, который реализует любые операции. БУ - управляет, ОП - исполняет.
Ну, как - лихо? :)
Лихо, безусловно. У меня вообще классические представления о программировании (коим я занимаюсь четверть века). Теория автоматов изучена вдоль и поперёк уж лет восемьдесят как, а про старину Эйлера, как заметил Вячеслав, я так вообще молчу, и после моего простого (но хитрого и подлого) вопроса-теоремы про умножение и вашего более чем уверенного ответа на него я таки позволю себе несколько усомниться в вашем новом определении модели автоматного программирования, равно как и знании и понимании, численных методов в том числе. Это не значит, что надо сидеть на багаже старых знаний и прогресс, безусловно надо двигать, но слегка в другом направлении.
Ваш хитрый вопрос я раскусил сразу а потому сразу и "врезал". Все это давно известно. Мне то уж точно. Когда-то с этого начинал... ;)
Ваше право сомневаться. Но, блин, в чем? Сформулировать можете? Или просто - сомневаюсь и "усе"? Если кто-то "по-дебильному" не может автоматом перемножить два числа, то это причина для сомнения? Почему так резко? А потому, что умножать чистыми автоматами это все равно, что микроскопом забивать гвозди. Не больше и не меньше.
Вы меня не то, чтобы поразили - просто сразили :( Я рассказал Вам по шагам как это сделать, как это делали и делают... А Вы сомневаетесь? Вы еще сомневаетесь? Вы продолжаете сомневаться?
Автоматы перемножают в SimInTech, автоматы перемножают в Матлаб, да в Вашем LabView без проблем это сделать, как я описал.
Я как-то не предполагал, не думал даже, что Вы настолько зашоренны прочитанным...
Итак. Конкретно - в чем сомнение? Я Вашу "арифметическую задачку" решил на автоматах. Вы сомневаетесь? Вас вводят в сомнение два первых ноля? Так я Вам скажу - они должны быть. А то, что у Вас только, один 0 - так, не сомневайтесь, это не правильно. У меня здесь сомнений нет. Я ВКПа доверяю. Уже больше 25-ти лет ;)
Просто я в автоматах не сомневался, когда все вопили, что автоматам - каюк и надо заниматься сетями Петри. И где эти сети Петри? Может, в Бауманке еще и изучают...
Нет, единственный и верный ответ, который я ожидал услышать — "Умножение двоичных чисел не может быть выполнено с помощью конечного автомата". Точка. А вот дальше уже можно было пускаться в пространные размышления, что де есть "классические" или "дебильные" конечные автоматы, а есть и другие в ВКПа, и на них оно будет вот так-то и так-то. Я, в общем, в курсе, как числа умножаются.
Ладно, оставим это. Что касается двух нулей, то у меня к ним претензий особых не было вроде бы. Я смею напомнить, что при первом подходе к снаряду вы считали правильным результат [0, 0, 2, 4, 10, 16, ...], но потом таки смогли смогли получить [0, 0, 2, 8, 22, 52, ...]. Получите же вы лидирующий ноль или нет - это зависит от того, в каком месте вы присасываетесь к данным, это легко достигается вот так:

(Я надеюсь, мне не нужно объяснять, что и в LabVIEW я получу ровно тот же результат перекладыванием одного-единственного проводочка).
Давайте не будем отвлекаться. Я так понимаю меня проверяли на знание теории автоматов? :) У меня есть, что сказать, но нусть это пока останется за скобками... :)
Итак. Я задал вопрос. А фактически дал задание - создать модель логического элемнта И-НЕ. Давайте сосредоточимся на этом. Без ухода в сторону. Помните - я жду модель. В форме конечного автомата. Не LabView, не SimInTech, не ВКПа даже. В форме обычного конечного автомата. Такого, какого Вы знаете... Обсудим и потом уже реализуем.
Если есть какие-то провлемы с ним - не стесняйтесь, не сомневайтесь задавать вопросы. Попробую ответиь. Отвечу на своем уровне понимания конечных автоматов...
Поехали?
PS
Да, по поводу...
Нет, единственный и верный ответ, который я ожидал услышать — "Умножение двоичных чисел не может быть выполнено с помощью конечного автомата". Точка.
Вынужден цитировать себя любимого
Конечно, напрямую автомат не выполнит умножение...
Здесь какой-то иной смысл?Мне кажется, что Вы придираетесь :)
PPS
Что-то не могу остановиться... ;)
Получите же вы лидирующий ноль или нет - это зависит от того, в каком месте вы присасываетесь к данным, это легко достигается вот так:
Самое интересное и любопытное, что и этого в ВКПа не надо. Но... Сначала модель И-НЕ!!!
Я ни в коей мере не проверял вас на знание теории автоматов, вы вполне в теме, я читаю ваши публикации и вы их иногда снабжаете списком литературы, я кое-что оттуда почерпнул, спасибо, кстати.
Да мы тут и не на экзамене, просто у вас весьма любопытный стиль мышления, я тут один из немногих, кто пытается понять. Если бы вы мыслили системно, то ответили бы иначе. Я вовсе не придираюсь, просто фразу о том, что автомат не выполнит умножение вы привели лишь после моего доказательства (спорить с ним, понятное дело бессмыссленно, ибо оно железобетонное). Ваш пассаж про y = a*b на петле я честно говоря тоже понять не в силах, ведь я говорил о двоичных числах, они прилетают вам порязрядно, и поразрядно же вы должны вернуть результат. Ну какое тут a*b, помилосердствуйте.
Про то, что заморочек с нулём в ВКПа не надо, я уже понял, хотя в любой нормальной системе я могу и имею полное право получать значения как до задержки, так и после, в том же LabVIEW я использую и так и сяк по ситуации (я бы мог тут спросить, не беспокоят ли вас в Си постфиксные и префиксные операции, но не буду). Ну получим чуть другой результат, там амплитудка повыше, тут чутка пониже да и "пох", как пару раз заметил тут коллега Вячеслав.
Ну а что касается И-НЕ элемента, то очевидным образом у него два состояния - 0 и 1, и для упрощения я положу ему четыре входа со всеми комбинациями значений х1х2 - 00 01 10 и 11, подключу их соответственно таблице истинности - 11 будет загонять его в состояние 0, остальные три - в 1, между ними он и будет прыгать. Рисовать лень, я с планшета отвечаю — два кружка да пара стрелочек, вот и весь разговор. Не вижу смысла что тут обсуждать. Вот нарисовать автомат, на примере которого показать правильную параллелизацию - значительно более интересно и полезно. Но тут мне надо подумать.
Вы осознанно или не очень искажает смысл автоматных вычислений. Но начинать надо с ответов на заданные вопросы. Ваше "все", Вячеслав, совершенно не соотвествует истине. Еще раз - операция и процесс - это совершенно разные вещи.
Судя по всему, в вашем параллельном мире вы пытаетесь выполнить сложение и умножение параллельно. Но поскольку они зависимы по данным, вам приходится вкорячивать вторую задержку, чтобы иметь возможность начать умножение не дожидаясь результата сложения.
Это не мой, это наш параллельный мир. В нем все параллельно. Сейчас забыли про аналоговые машины и как там набирали решения математических уравнений. На них блоки суммирования, умножения соединяли проводочками и получали результат. И все эти блоки работали параллельно. И все эти блоки, между прочим, не ожидали на своих входах готовности входных данных. В таком ключе работает и ВКПа. Ее блоки работают параллельно, они не ждут готовности входных данных, а просто реализуют заложенные в них функции, выдавая результат подобно аналоговым блокам аналоговых ЭВМ. Их устройство может быть различным и содержать в том числе тысячи и миллионы операций (привет, Вячеславу), но это могут быть и множество процессов. Электронщики, дкмаю, об этом имеют более точное понимание, представляя плату и множество ее элементов. А современный процессор - это ж прекрасный пример, миллионов (миллионов!, Вячеслав) простейших процессов (логичских элементов, сумматоров, регистров и т.д. и т.п), реализующих поставленную задачу.
Сейчас забыли про аналоговые машины и как там набирали решения математических уравнений.
Поэтому их и забыли, что это было очень кривое приближение приближение к чистой абстрактной математике. Были еще и струйные компьютеры, а еще в поездах в тормозах есть до сих пор пневматические вычислители, которые используют перпад давления в трассах для вычисления результата и срабатывания торомзов. И их начинают заменять на нормальные цифровые вычисления на контроллерах, они тоже не идеальны, но значительно лучше любой аналоговой машины. И для цифровых вычислени используюся специальные методы для создания конкурентных алгоритмов, которые при наличие нескольких вычислительных ядер могут вычислятся параллельно.
Как например можно распралелить вычисления любого интеграла.
Например возьмем расчет приближенного числа
static long num_rects=100000;
void main()
{
int i;
double mid, height, width, sum = 0.0;
double area;
width = 1.0/(double) num_rects;
for (i = 0; i < num_rects; i++){
mid = (i + 0.5) * width;
height = 4.0/(1.0 + mid*mid);
sum += height;
}
area = width * sum;
printf("Computed pi = %f\n",area);
}
если у нас два процессора, мы можем разбить итеграл на две части и запустить паралельно два цикла расчет от 0 до num_rects/2 и от mun_rect/2 до num_rects. Расчитав две площади а потом их сложить. Таким образом мы получим паралельное вычисления числа .
И пожалуйста паралельные вычисления на простом Си без всяких автоматов с задержками, причем в отличие от ваших бредовых идей здесь после распаралеливания вычисления результат не меняется. Погрешности нет от слова совсем.
И дробить шаг до нет никакой необходимости.
Это называется паралельные вычисления, так как это понимают все в этом мире.
Ее блоки работают параллельно, они не ждут готовности входных данных, а просто реализуют заложенные в них функции, выдавая результат подобно аналоговым блокам аналоговых ЭВМ. Их устройство может быть различным и содержать в том числе тысячи и миллионы операций (привет, Вячеславу),
Как?!!! Блоки не ждут готовности данных, это вообще новое словао в кибернетике. Как можно вообще проводит вычисления когда на входе нет готовых данных? Это же основы, если данные не готовы то черт возьми что вы вообще считаете? Дерьмо на входе - дерьмо на выходе, а между ними тысячи и миллионы операций с дерьмом. Нахуа?
Как?!!!... если данные не готовы то черт возьми что вы вообще считаете?
Как вы готовите данные для сумматора на АВМ? Клапаны на проводочки врезаете? Тумблеры ставите? Сумматор берет значения со входов (какие есть) и выдает результат (с задержкой, блин!) на выход. Просто - как Ван Дер Поль! ;)
Как вы готовите данные для сумматора на АВМ? Клапаны на проводочки врезаете? Тумблеры ставите? Сумматор берет значения со входов (какие есть) и выдает результат (с задержкой, блин!) на выход.
Тут, по-моему, только статьёй из Википедии ответить можно — Программирование потоков данных.
Кстати, АВМ — это Артерио Венозные Мальформации головного мозга, от которых я уже недалёк, читая это обсуждение.
АВМ на выходе выдавала большую часть времени сполошной бред, и для получения результата нужно было шаманить и настраивать вход, и натужно долго и упорно фильтровать выход. Имеенно поэтому эти вчислители АВМ ушли на помойку, как только появился превый процессор с фиксированным числовым воводм и выводом. А вы предлагаете на современных процессарах повторять помоечное решение. С воистинную правоврено параллельностью и задержками. Зачем что бы получать такое же дермовое решение, на цифровых системах какое мы имели на АВМ?
Что до вандерполя дос соберите сам. Там всего два интегратора и попробуйте посчитать при я думаю сильно удивитесь.
АВМ на выходе выдавала большую часть времени сполошной бред
На АВМ я работал в живую в институте на лабах. Все было прекрасно. Зная их принцип, я как-то уверен, что сказанное Вами, мягко говоря, искажает, скажем так, ситуацию. У АВМ были проблемы только с точностью. Компоненты были слишком не точны. А высокоточные - очень дорогие. Все остальное - норм. Параллелизм - так сплошной. Скорость - так практически мгновенная ;).
По поводу вандерполя. Делаем, как обычно. Сбросьте проект - я повторю в ВКПа. Потом, может, и удивлюсь. Если будет чему. А Вам могу предложить попробовать функцию Аккермана. Чтобы тоже удивиться.:)
На АВМ я работал в живую в институте на лабах. Все было прекрасно.
Конечно прекрасно, поэтому их на помойки все и выкинули. Что бы посчитать что-на АВМ нужно подгтовить исходные данные, а это отдельная песня. Мгновенно и полная параллельность, но полная хренотеть на выходе. Пока вход не будет подготовлен, выход просто бессмыслица.
Поэтому АВМ и зменили сразу как только цифровой процессор появился, и можно было уравнения физики процессов записывать прямо и считать нормальными методами.
Так что АВМ это как дворник вместо кухарки, только когда нет другого выхода. Зачем вы пытаетесь притащить за уши окаменелое дерьмо динозавров?
https://disk.yandex.ru/d/pQm1E35rZak2yg - проект осцилятора вандер поля
Какой пародокс я должен тут убрать? У вас модель непрерываного процесса. Набор диференциалных уравнений. Мы его в SimInTech решаем используя разностью схему с дикретизацие по времени. Чем меньше шаг тем ближе дикретный процесс к непрерывному, меньше погрешность. Чем больше шаг по времени тем больше погрешность. В чем здесь парадокс? У вас регулятор темературы в комнате вы меряеет ее 1 раз в секунду и включает кондиционер. Потом вы начинает меретя ее раз в день, и жалуетесь что регулирует плохо, а потом вы начинает мерять ее 1 раз в год. И предьявляет претензию что регулятор не работает. А с чего бы ему работать?
Какой пародокс я должен тут убрать?
Его Вы убрали, когда наконец-то выполнили мою просьбу. Если бы это было сделано изначально, то и "парадокса" не было бы. Надо просто быть внимательнее к тому, о чем Вас просят... Причем неоднократно. Делов-то.
Меня тут "вштsрило"... и я решил попытать еще эталонный Ваш проект и получил такой, как считаю, просто уникальный результат (см. ниже а):

Что скажете? При этом я менял только параметры в проекте.
Ах, да ... для чистоты эксперимента. Шаг 0.485 в нормальном проекте,

Я вот не вижу тут ничего уникального, налицо неверно настроенный контроллер нечёткой логики. На верхних графиках там фактически два состояния открыто/закрыто, соотвтетственно, клапан при низком уровне открывается на всю катушку и уровень воды проскакивает установленный уровень и клапан резко закрывется. При большом шаге дискретизации при закрытом клапане мы проваливаемся по уровню до 1,4, что вызывает резкое открытие клапана и начинаются осцилляции. Начинаются они на втором периоде потому что значально уровень был нулевой, а на втором периоде мы стартуем с 0,5. При малом шаге мы не даём системе провалиться до такого низкого уровня, поскольку ловим уровень мéньшим шагом и осцилляций нет. При правильно настроенном контроллере открытие и закрытие происходят плавно, и система не так чувствительна к шагу. Никакой мистики тут нет на мой взгляд, я вам ровно такие же осцилляции в LabVIEW могу устроить, если шаг в десять раз увеличу:

Я сейчас наверное удивлю, но я поступил еще проще. Никаких фазификаторов блоков управления обратной связи тольк бак и клапан расхода в него

Взял только клапан и бак. Добавил меандр который меняет скорость открытия и закрытия клапана с частостой 10 секунд. При шаге интегрирования 0.01 секунд получил такой результат:

Расход входа в бак после интегратора красиво линейной пилой (нижний график) то растет то уменьшается. А вот все остальные параметры в баке уже не линены. Скорости изменения уровня уже не линейная, (второй график снизу) поскольку учитывается уровень в баке и гидрастатическое давление. Больше уровень больше давления и расход выхода (третий снизу) тоже больше - меняется по кривой траектории. И верхний график это сам уровень, плавное изменение согласно баланса общего расхода линейного выхода и нелинейного выхода.
Теперь возмем и зададим шаг интгерирования 5 секунда:

ДажПонятно что нижний график не поменялся у нас линейное изменение было 1000 точект стало всего две, но линия не поменялась не на грамм ровно та же пила.
Вопрос на засыпку: Точки расчета с шагом 5 секунд на всех остальных графиках совадают с точками расчета с шагом 0.01 секунда? Что вам подсказывает едиственно верное учение ВКПа? Если взять время t=5 секунд совпадет расход выхода, скорость изменеия уровня и сам уровень в этот момент времени у одной и той же модели, но расчитанной с разным шагом интегрирования?
Конечно сломал итрику видно что при 10 секундах графики уровня и скорости изменения на совпадают. Что бы оценить на сколько вывожу все на один график

Так что без всякого регулятора можно получить херню в модели если не включать голову и никаой ВКПа и ВКПб тут ничем не помогут, несмотря на исконно посконно воистину наивысшую степень паралельности
Что вам подсказывает едиственно верное учение ВКПа?
Оно подсказывает что-то другое... Я собрал схему в SimInTech

Явно что-то иное. Кстати в ВКПа тот же эффект:

Колитесь, что не так. Наверное, меандр треугольный ;)
просто у вас подключение к меандру, а у меня к клапану. Тогда меандр это скорость открытие = угол наклона зубьев пилы положения клапана.
Приведите полную схему эксперимента, чтобы было разночтений, что Вы делаете, и что Вы отображаете на графиках. .
Модель здесь: https://disk.yandex.ru/d/1JEhIUcYQda36g
У вас меандр от -0.1 до 0.1, а у коллеги lws0954 от 0,5 до 1,5, вот и весь ответ.
Ещё вопросик, чтоб два раза не вставать — а можно разделить десятичный где-то подкрутить или брать его из системных настроек винды? Он в Германии не точка, а запятая и я всё время ошибаюсь:

В Винде в Панели управления есть Язык и региональные стандарты. Там Форматы в них Дополнительные параметры, а там уже закладка Числа, а в ней уже поле Разделитель целой и дробной части. У меня, например, как в Германии установлена "запятая". Но поможет ли? ;)
Конечно, я могу поставить там точку, но тогда мне станет неудобно решительно везде. LabVIEW вот понимает запятую, а в SimInTech запятая разделяет элементы массивов и мне потом каждый раз надо это дело править или не пользоваться цифровой клавой сбоку.
Вот что получилось на проекте, созданным мною:

А вот проект Ваш:

Но это не все. Совместим верхние графики:

Все графики, кроме красных совпадают. Чем можно объяснить сей факт?
Вы уж меня простите, но вы совершенно не умеете изложить суть даже в таком простейшем случае. Да мы тут телепаты все и прекрасно понимаем что вы там понакрутили.
Давайте строго подойдём к вопросу. Итак у вас в руках система, результаты которой вас удивляют, которые вы считаете неправильными. Поскольку единственный код, который есть у нас в руках - это тот, что был предоставлен выше, вот на его примере и покажу как производится поверка.
Прежде всего вместо мутных графиков я сброшу все значения в лог файл, вот так, включая меандр, потому что я вообще никому не доверяю в этом мире:

А теперь открываю его в любой удобной программе и начинаю разбираться:

В лог файле шесть колонок - время с начала эксперимента и те пять входов, что я добавил. В точке "ноль" я вижу 0.1 - это мой меандр, всё остальное стоит в нуле. ОК.
Едем дальше, следующая секунда, мы находимся здесь:

Меандр так и стоит в 0,1, а вот следующее значение стало 0,05. Почему так? А потому что это выход интегратора, который набрал за эту секунду 0,1, помноженный на 0,5, вот откуда 0,05. Интегрировать, кстати, тоже можно по-разному, но это так, вскользь. Как бы то ни было, это же значение пролетело насквозь нашего бака из rate в dh, а остальные два параметра в нуле, потому что там второй интегратор, а он выдаст нам значение лишь на следующем шаге.

С этим разобрались, едем дальше. Мы здесь:

О, тут уже интереснее. Значение первого интегратора увеличилось с 0,05 до 0,1 (мы не забываем, что там деление на два, поэтому приращение 0,05). Второй интегратор наконец отработал, так что теперь там 0,05. А число дальше это outrate = sqrt(2gh) outarea; где outarea это константа, то есть sqrt(2 x 9,8 x 0,05) x (1/20). Берём калькулятор, считаем, совпадает аж до последнего знака:

А откуда берётся последнее число? А это 0,1 минус то что выше, и оно записано в лог в этом же такте, это важно!

Едем дальше, мы здесь и первый интегратор клапана наинтегрировал ещё, увеличившись до 0,15, а второй в баке теперь учёл дельту, которая сложилась с входным значением и стало 0,100502525316942 (насколько я понимаю это именно ваше "проблемное" число, которое там где-то дальше не сходится):

И так далее:

Листинг:
Скрытый текст
0 0.1 0 0 0 0
1 0.1 0.05 0 0 0.05
2 0.1 0.1 0.05 0.0494974746830583 0.0505025253169417
3 0.1 0.15 0.100502525316942 0.0701756634491626 0.0798243365508374
4 0.1 0.2 0.180326861867779 0.094000086337839 0.105999913662161
5 0.1 0.25 0.28632677552994 0.118448351617771 0.131551648382229
6 0.1 0.3 0.417878423912169 0.143094523905341 0.156905476094659
7 0.1 0.35 0.574783900006828 0.167822558377396 0.182177441622604
8 0.1 0.4 0.756961341629432 0.19259051310966 0.20740948689034
9 0.1 0.45 0.964370828519772 0.217380244266743 0.232619755733257
10 -0.1 0.5 1.19699058425303 0.242182861962605 0.257817138037394
11 -0.1 0.45 1.45480772229042 0.266993592417928 0.183006407582072
12 -0.1 0.4 1.6378141298725 0.283289414492939 0.116710585507061
13 -0.1 0.35 1.75452471537956 0.293209329751968 0.056790670248032
14 -0.1 0.3 1.81131538562759 0.297916857354115 0.00208314264588544
15 -0.1 0.25 1.81339852827347 0.29808812100686 -0.0480881210068597
16 -0.1 0.2 1.76531040726661 0.294109180332855 -0.0941091803328554
17 -0.1 0.15 1.67120122693376 0.286162296817303 -0.136162296817303
18 -0.1 0.1 1.53503893011646 0.27425701007578 -0.17425701007578
19 -0.1 0.05 1.36078192004068 0.258221443884882 -0.208221443884882
20 0.1 1.38777878078145E-17 1.15256047615579 0.237645667605437 -0.237645667605437
21 0.1 0.05 0.914914808550357 0.21173291104353 -0.16173291104353
22 0.1 0.1 0.753181897506827 0.192109117373004 -0.0921091173730037
23 0.1 0.15 0.661072780133823 0.179979349444755 -0.0299793494447553
24 0.1 0.2 0.631093430689068 0.175851011096793 0.0241489889032072
25 0.1 0.25 0.655242419592275 0.179183923832529 0.0708160761674712
26 0.1 0.3 0.726058495759746 0.188618308475682 0.111381691524318
27 0.1 0.35 0.837440187284064 0.202569911825323 0.147430088174677
28 0.1 0.4 0.984870275458741 0.219678500307787 0.180321499692213
29 0.1 0.45 1.16519177515095 0.238944338669902 0.211055661330098
30 -0.1 0.5 1.37624743648105 0.259684663366113 0.240315336633887
31 -0.1 0.45 1.61656277311494 0.281445511391871 0.168554488608129
32 -0.1 0.4 1.78511726172307 0.295754536439309 0.104245463560691
33 -0.1 0.35 1.88936272528376 0.304267601855512 0.0457323981444883
34 -0.1 0.3 1.93509512342825 0.307928012769193 -0.00792801276919275
35 -0.1 0.25 1.92716711065905 0.307296580557437 -0.0572965805574375
36 -0.1 0.2 1.86987053010162 0.302693997256271 -0.102693997256271
37 -0.1 0.15 1.76717653284535 0.294264592007638 -0.144264592007638
38 -0.1 0.1 1.62291194083771 0.281997668609242 -0.181997668609242
39 -0.1 0.05 1.44091427222847 0.265715636233916 -0.215715636233916
40 0.1 1.38777878078145E-17 1.22519863599455 0.245019862794291 -0.24501986279429
41 0.1 0.05 0.980178773200259 0.219154648334943 -0.169154648334943
42 0.1 0.1 0.811024124865316 0.199349397085621 -0.0993493970856207
43 0.1 0.15 0.711674727779695 0.1867406267024 -0.0367406267023999
44 0.1 0.2 0.674934101077295 0.181856457000535 0.0181435429994649
45 0.1 0.25 0.69307764407676 0.184284574937137 0.065715425062863
46 0.1 0.3 0.758793069139623 0.192823391702982 0.107176608297018
47 0.1 0.35 0.865969677436641 0.205991539133032 0.144008460866968
48 0.1 0.4 1.00997813830361 0.222461072497812 0.177538927502188
49 0.1 0.45 1.1875170658058 0.241222586472503 0.208777413527497
50 -0.1 0.5 1.39629447933329 0.26156916769247 0.23843083230753
51 -0.1 0.45 1.63472531164082 0.283022155087549 0.166977844912451
52 -0.1 0.4 1.80170315655328 0.297125318125384 0.102874681874616
53 -0.1 0.35 1.90457783842789 0.305490284760361 0.0445097152396385
54 -0.1 0.3 1.94908755366753 0.309039301917586 -0.00903930191758623
55 -0.1 0.25 1.94004825174994 0.308321851862218 -0.0583218518622176
56 -0.1 0.2 1.88172639988773 0.303652093018472 -0.103652093018472
57 -0.1 0.15 1.77807430686925 0.295170528739902 -0.145170528739902
58 -0.1 0.1 1.63290377812935 0.282864428884825 -0.182864428884825
59 -0.1 0.05 1.45003934924453 0.266555675446954 -0.216555675446954
60 0.1 1.38777878078145E-17 1.23348367379757 0.245846903612962 -0.245846903612962
61 0.1 0.05 0.987636770184611 0.219986821739499 -0.169986821739499
62 0.1 0.1 0.817649948445113 0.200162053031564 -0.100162053031564
63 0.1 0.15 0.717487895413549 0.187501751659188 -0.0375017516591882
64 0.1 0.2 0.679986143754361 0.182535807566526 0.0174641924334744
65 0.1 0.25 0.697450336187835 0.184864995261958 0.0651350047380415
66 0.1 0.3 0.762585340925877 0.193304634464278 0.106695365535722
67 0.1 0.35 0.869280706461599 0.206384967031561 0.143615032968439
68 0.1 0.4 1.01289573943004 0.222782160937701 0.177217839062299
69 0.1 0.45 1.19011357849234 0.241486159740314 0.208513840259686
70 -0.1 0.5 1.39862741875202 0.261787592369939 0.238212407630061
71 -0.1 0.45 1.63683982638208 0.28320514030067 0.16679485969933
72 -0.1 0.4 1.80363468608141 0.297284543187145 0.102715456812855
73 -0.1 0.35 1.90635014289427 0.30563238866622 0.0443676113337802
74 -0.1 0.3 1.95071775422805 0.309168513851547 -0.00916851385154738
75 -0.1 0.25 1.9415492403765 0.308441100987609 -0.0584411009876094
76 -0.1 0.2 1.88310813938889 0.303763557442389 -0.103763557442389
77 -0.1 0.15 1.7793445819465 0.295275946388084 -0.145275946388084
78 -0.1 0.1 1.63406863555842 0.28296530377833 -0.18296530377833
79 -0.1 0.05 1.45110333178009 0.266653451613183 -0.216653451613183
80 0.1 1.38777878078145E-17 1.23444988016691 0.245943172558578 -0.245943172558578
81 0.1 0.05 0.988506707608328 0.22008368561256 -0.17008368561256
82 0.1 0.1 0.818423021995768 0.200256655514349 -0.100256655514349
83 0.1 0.15 0.718166366481419 0.187590383435798 -0.0375903834357976
84 0.1 0.2 0.680575983045622 0.182614958777301 0.0173850412226986
85 0.1 0.25 0.697961024268321 0.184932663932437 0.0650673360675629
86 0.1 0.3 0.763028360335883 0.193360775899504 0.106639224100496
87 0.1 0.35 0.869667584436379 0.20643088828318 0.14356911171682
88 0.1 0.4 1.0132366961532 0.222819653781947 0.177180346218053
89 0.1 0.45 1.19041704237125 0.241516945732989 0.208483054267011
90 -0.1 0.5 1.39890009663826 0.261813110319699 0.238186889680301
91 -0.1 0.45 1.63708698631856 0.283226521232758 0.166773478767242
92 -0.1 0.4 1.80386046508581 0.297303149645618 0.102696850354382
93 -0.1 0.35 1.90655731544019 0.305648995510486 0.0443510044895137
94 -0.1 0.3 1.9509083199297 0.309183614825488 -0.00918361482548757
95 -0.1 0.25 1.94172470510422 0.308455038133772 -0.0584550381337717
96 -0.1 0.2 1.88326966697044 0.303776585143674 -0.103776585143674
97 -0.1 0.15 1.77949308182677 0.29528826764623 -0.14528826764623
98 -0.1 0.1 1.63420481418054 0.282977094293595 -0.182977094293595
99 -0.1 0.05 1.45122771988694 0.266664880091962 -0.21666488009196
Вот ровно тоже самое вы должны проделать до момента расхождения и в вашей программе в том числе (хотя я думаю у вас там уже вначале будет разбегаться). Никакое число тут не берётся из воздуха, это результат расчёта согласно алгоритму. И если я повторю эти вычисления в LabVIEW, то получу строго такой же результат, вплоть до последнего знака после запятой, (если точность будет та же). И если вы утверждаете, что результат расчёта по вашей параллельной методике заметно отличается, то должны внятно изложить где и почему. Просто скриншоты графиков тут не катят. Берёте два листинга, прикладываете сторона к стороне и дотошно проверяете. У вас лабораторных по физике или электронике в институте не было что ли, где мы проверяли законы физики экспериментально, списывая в тетрадку показания приборов, строя графики и убеждаясь, что законы всё еще в силе? Ну вот тут тоже самое. Сдёрните логи с обеих систем, покажите их, ткните пальцем в расхождение, и объясните почему так а не иначе, почему именно ваши значения именно такие, как вы к ним пришли и что там с чем у вас складывается параллельно или попендикулярно или как ещё, ибо только вы в курсе того, как производятся вычисления в вашей параллельной среде. Любому наблюдаемому и значимому расхождению всегда есть рациональное объяснение, чудес на этом свете не бывает. Я всё ещё думаю, что вы снова съехали на один такт с этим вашим параллелизмом, берёте предыдущее значение, оно ниже, оттого размах амплитуды вашего графика несколько меньше, чем должен быть. Ошибки в SimInTech тоже исключать нельзя, но тут настолько базово всё, что тестировалось сто раз и достаточно вычищено. Впрочем - доверяй, но проверяй.
Все графики, кроме красных совпадают. Чем можно объяснить сей факт?
Я сегодня отчаянно не ленив, так что пожертвую обеденным перерывом ради высокого искусства. Выше я писал, что все значения, полученные в ходе симуляции имеют строгое мат обоснование, это можно даже в Экселе проверить. Я переброшу этот код на LabVIEW, вот так это выглядит:

Для непосвящённого может чуть непривычно, но два интегратора тут видны хорошо, формулу я оставил как есть, тут примитивная арифметика, а как работают сдвиговые регистры, я уже выше писал.
Результат:

И заметьте, полученные данные такие же как в SimInTech, при этом они не "примерно" такие же, они точно такие же (я пару колонок местами переставил, но переделывать не буду, всему есть предел).
А вот теперь следите за руками, я внесу задержку в первое попавшееся место, это легко сделать, просто растянув сдвиговый регистр вниз, второй его терминал будет выдавать данные на цикл позже. Я скопирую оригинал и сделаю вот так, оставив только то, что меня (точнее вас) интересует:

Ну и вот, получите и распишитесь:

При этом я могу строго обосновать, как и почему значение, скажем 0,180327 магическим образом превратилось в 0,250503 и так далее. Ну какие могут быть ещё вопросы? Всё что выше, я могу и на Си переписать, там двадцать строчек кода, но уж увольте. У вас амлитуда вроде в другую строну уваливается, но тут зависит что относительно чего задерживать.Вот если я в другом месте задержку вдую:

То зацените какая неописуемая красота получится:

И даже тут нет магии, просто арифметика.
Закоулками мечты. Часть 2