В схеме на Рис.1 могут исполниться все ветви (жёлтая, синия, оранжевая), а может не исполниться ни одна.
В переключателе же исполнится одна, без дополнительных построений, а это уже совсем другой алгоритм.
Да, но я-то говорю всё время о вариантах 2 и 3 (после пересадок лиан, которые отличаются только компоновкой), а Вы сейчас о варианте 1 (до пересадок). Для него Вы правы, и это будет другой переключатель, чем я описывал (если его возможно получить - см. постскриптум).
Что-то тяжело даются мне рокировки : )
Не могли бы Вы графически изобразить переключатель эквивалентный схеме на Рис. 1?
А Вам и не нужны рокировки, если Вы хотите в схеме с инверсной записью сохранить порядок маршрутов - только вывод новых условий и разъединение.
Когда нужны будут - пробуйте вводить БП, как показано
в определениях ветвлений в этом подпункте - тогда можно мысленно (а если редактор подходящий, то и в нём) убрать нагрузку вертикалей и переставлять развилки отдельно, а потом подставлять ветви по адресам БП.
В общем виде сказанное, наверное, опишу в Драконографике (ранее вообще-то полагал эти вещи тривиальными). Нарисовать быстро не получится наверное.
P.S. А если совсем точно, то чисто графическими соображениями при таких преобразованиях не обойтись. В самом деле, общая процедура преобразования имеет вид:
* если структура конструкции лианная и нужно обратить "шапочный разбор" из развилок - провести разъединения для составления из точек слияния дерева "подвального сбора";
* обратить конструкцию согласно замыслу сочинителя (из инверсной формы в прямую или наоборот);
* выписать формулу каждого маршрута преобразуемой конструкции, как показано у Паронджанова для нелинейных структур (включая и ответы на вопросы, и сами вопросы; можно так, как предложил он же в своём стандарте дракон-псевдокода, пример можно найти, скажем, в тексте, вложенном в это сообщение).
Для каждого маршрута результирующей схемы выполнить следующее:
* если на маршруте есть развилки, лежащие между линейными участками - переместить их сразу после начальной развилки маршрута в порядке следования по шампуру;
* составить по развилкам новое условие выбора маршрута как конъюнкцию вопросов (причём, если на вопрос даётся ответ "нет" - он должен входить в конъюнкцию с отрицанием);
* подставить полученное условие в развилку (вариант) новой схемы, а остальное содержание маршрута - как содержимое (нагрузку вертикали) этого варианта.
Изначально выполнимость преобразования, как уже говорил, ограничена тем, что развилки должны составлять дерево "шапочного разбора" (в виде "лесенки" в прямой записи или "ханойской башни" в инверсной - неважно). Но. Ограничение накладывается также на перемещения развилок: они возможны, если на участке маршрута между местом, где была развилка, и местом, куда она перемещена, не использовалась как результатная (в правой части к.-л. присваивания на этом участке) ни одна из переменных, входящих в условие развилки. Это не выводимо из одной топологии схемы, а только из логики, учитывающей текст икон: ведь по результатам присваиваний меняется текущее состояние визуализированного процесса, и проверка условия ПОСЛЕ возможного изменения значения его аргументов-переменных не эквивалентна проверке ДО изменения - выбор м.б. другим.
Понятно, что проверить это ограничение невозможно ни по литеральной схеме (Ваша является её разновидностью), ни по абстрактной ("слепышу") - только по смысловой и притом со структурированным текстом икон, где выделены имена величин (в соответствии с
указаниями в конце этого подпункта), а из командного текста ("имени действия") ясно, где операнды, а где результат.
NB. Разумеется, я имею в виду состояние в обычном за пределами ИТ смысле (для целевого назначения), в которое входят только величины алгоритма. Более широкое состояние, включающее поддержку функционального назначения, т.е. служебные величины исполнителя (сигналы состояния узлов и выполнения шагов алгопроцесса, в т.ч. ошибочного), здесь не требуется - это для обработки исключений.Ваша схема после пересадок "подгадалась" так, что ни один маршрут после первого ветвления не проходит больше через развилки; в этом случае не надо перемещать развилки, и ограничение неактуально (потому я его не обсуждал до этого). Однако на схему до пересадок (Ваш Рис.1) это ограничение распространяется; поэтому без конкретного текста икон невозможно определить допустимость её преобразования в переключатель (не говоря уже о том, чтобы изобразить результат такого преобразования).
По сути это то же, о чём говорил неоднократно, напр., Илья Ермаков - нельзя сочинять алгоритм/программу, не опираясь на математическую логику, не анализируя цепочки состояний, сменяющихся в процессе исполнения. Потому и я говорю о логическом проектировании.
P.P.S. И ещё одна вещь, которую не упомянул (как-то полагая молчаливо, что она выполняется, а если нет - то логически вполне очевидна
). Собирать в начало маршрута развилки, не находящиеся там изначально, можно только при ещё одном ограничении - их условия при любых сочетаниях входящих величин должны либо все вместе выполняться, либо все вместе не выполняться - только тогда они будут отвечать смыслу конъюнктов нового объединённого условия.
В самом деле, представим, что условие развилки, начинающей маршрут, при конкретном сочетании данных (сформированном при исполнении предыдущего маршрута) вывело нас на него, а условие какой-то из развилок, отделённых от начальной по крайней мере одним оператором, уводит нас с этого маршрута (при этом совершенно необязательно, что этот оператор изменяет какие-то переменные, проверяемые после него) - и тогда если мы переместим эту развилку прямо под начальную развилку (для последующего составления объединённого условия), то "потеряем" случай выполнения только этого оператора.
Это ограничение не м.б. проверено даже по тексту визуала - нужно привлекать области определения величин, употребляемых на маршруте. Т.о. в слоистой модели информатического решения мы поднимаемся на верхний уровень иерархии - данных. Если множества значений величин, получаемые при переработке данных, таковы, что при любом сочетании конкретных значений в условиях данного маршрута обеспечивают выполнение ограничения - тогда можно преобразовывать, как описано выше.
Сочинитель, исходя из смысла задачи, может и сам ограничивать области определения некоторых переменных - напр., заданием нужных параметров верификации при контролируемом ручном вводе, предобработкой (нормализацией, масштабированием, отсечением диапазонов и пр.) данных, поступающих по техническим каналам - но делать это исключительно для того, чтобы получить удобную схему, конечно, далеко не всегда оправданно.
Вход
FAQ
Поиск
