DRAKON.SU

1. показалось необоснованным ограничение расположения петли обычного цикла только справа от развилки.
2. когда пересаживаем правый выход развилки вверх(через правую сторону) - корректно организуется обычный цикл. Пересадка лианы для нижнего выхода развилки(налево и вверх) позволила создать неправильную конструкцию - не появилась стрелка на конце лианы:

Любопытно выслушать мнения, имеется ли необходимость создания обучающего дракон редактора под Linux?

Я думаю, что следует ставить вопрос о создании кросс-платформенного редактора ДРАКОН с поддержкой сохранения рисунков в формате SVG.

-

А где цикл? Схема нециклическая вроде?
Несколько входов в цикл быть не может.
И ещё - "конец" должен быть на той же оси, что и начало.
Получается, что схема вообще не по правилам построена...

Если не нарушать правило "петля справа" то вроде бы получается. Так?:

Только не SVG, a DXF.

Ужас какой!!

Два входа в цикл недопустимы.

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

Дракон-схемы здесь и здесь получены в результате пересадки лианы. В данных случаях действия пользователя редактором не ограничиваются, т.е. редактор не принимает решений за человека.

Здесь, в пересадках лианы, мы имеем проблему аналогичную проблеме бессистемного использования GOTO.

В справке об этом сказано:
Пересадкой лианы можно преобразовать блок “Развилка” или “Переключатель” в “Обычный цикл” или в “Переключающий цикл", а также наоборот. Можно преобразовать блок “Обычный цикл” в “Цикл ЖДАТЬ”, вставив икону "Период", а также наоборот. Применять эти преобразования не рекомендуется и выбор вида блока должен быть сделан изначально.
Контролируйте правильность дракон - схемы.

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

Насколько понимаю, это обеспечивает достаточность такой конфигурации для линейной текстовой записи с помощью набора структурных предложений. Необходимость же такого условия для плоской записи Дракон-схемы пока под сомнением. Не хотелось бы перетаскивать на Дракон-схемы все топологические ограничения, обнаруженные в результате работ по трансляции граф-схем в языки высокого уровня. Если дополнить правила графического структурирования Дракона математически обоснованными границами применимости топологий, то получится строгий вариант языка для проектирования программных систем. Рекомендательный характер только вызовет споры. А если обеспечивать трансляцию в код целевой платформы(или промежуточное бинарное представление), то не будет ни одного упрёка от GOTOфобов.

Согласен. Цель - уточнить правила двумерной структурной записи для создания программ. Если оставить всё на уровне рекомендаций по использованию редактора, то получим документ типа стандарта на язык Си.


Тоже самое можно сказать об алгоритме проезда перекрёстка. При этом, алгоритм не содержит ни повторного использования, ни запутанных маршрутов, выполнен с соблюдением правил Дракона, т.е. вроде как является структурным для плоской записи. Но не может быть преобразован в линейную текстовую запись только с помощью набора структурных предложений.

А чем такие схемы будут отличаться от обычных блоксхем? Разве по правилам Дракона движение должно быть не вниз? Движение вбок и вверх не особо эргономично.

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

и при этом результат удовлетворяет правилам графического структурирования Дракон-схем.

Насколько понимаю, это обеспечивает достаточность такой конфигурации для линейной текстовой записи с помощью набора структурных предложений. Необходимость же такого условия для плоской записи Дракон-схемы пока под сомнением. Не хотелось бы перетаскивать на Дракон-схемы все топологические ограничения, обнаруженные в результате работ по трансляции граф-схем в языки высокого уровня. Если дополнить правила графического структурирования Дракона математически обоснованными границами применимости топологий, то получится строгий вариант языка для проектирования программных систем. Рекомендательный характер только вызовет споры. А если обеспечивать трансляцию в код целевой платформы(или промежуточное бинарное представление), то не будет ни одного упрёка от GOTOфобов.[/quote]

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

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

В таких случаях (дублирование в начале цикла) это и не является, на самом деле дублированием. Это вылезает, когда есть некое добавочное к циклу действие, которое, по чистой случайности, иногда совпадает с телом. Вот тут на эту тему излагалось уже - viewtopic.php?p=28238#p28238

если это не выполняется, то

1."та точка" не является единственной точкой входа в цикл

2.не работают алгоритмы поиска циклов в графе, основанные на поиске дуг, у которых голова доминирует над хвостом

3.не работают методы оценки приводимости графа, основанные на проверке ацикличности подграфа, полученного после удаления обратных дуг в исходном графе.

4.исходный граф в общем случае неприводим, поэтому невозможно составить программу без использования GOTO.

Это всё, что удалось вспомнить/найти. Если я что-то пропустил, буду признателен за совет.

p.s.: "ужасный" алгоритм "легализовался" так:

Ага, всё так

К проверке в конце цикла добавилась ещё одна- в начале. Плюс внутри цикла каждый раз одно и то же присваивание (m:=0). Скорость упала как минимум вдвое. "Буран" будет в 2 раза медленнее реагировать на возмущающие воздействия. Реальная дееспособность как жертва идеологически выверенной структурности. Напрашиваются мрачные аналогии..

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

Но, вообще, это задача оптимизатора кода нижнего уровня. Т.е. оптимизатор самостоятельно должен разворачивать циклы в несколько проходов, если речь идёт о многопоточной/многопроцессорной программе.

Ага, сегодняшние оптимизаторы лучше разгребутся с изначально структурным кодом. Но им без разницы - "натянули" конструкцию или целиком редизайнили.