DRAKON.SU

Уважаемый Эдуард!

Вы задали вопрос про цикл в примитиве здесь.
viewtopic.php?p=70268#p70268



Мой ответ таков.

1. Язык ДРАКОН определен через графический синтаксис. Текстовый синтаксис не определен и может быть любым.

2. Как определен графический синтаксис? Он определен ДВОЯКО.
Во-первых, он определен через формальное описание (37 тезисов, изложенных в главе «Графический синтаксис языка ДРАКОН»). В последней книге это Глава 33, стр. 416—424.
Во-вторых, что очень важно, графический синтаксис определен через мое описание дракон-редактора. В последней книге это «Глава 32. Конструктор алгоритмов (помощник человека)», стр. 395—415.
http://drakon.su/_media/biblioteka/chas ... isanie.pdf

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

4. Отсюда вытекает, что правильно построенный дракон-редактор является инструментом не только для конструирования правильных дракон-схем, но и инструментом ДЛЯ ПРОВЕРКИ готовой дракон-схемы, относительно которой есть сомнения, что она правильная. Это именно Ваш случай, Эдуард.

5. Отсюда следует порядок действий. Глядя на Вашу схему, следует провести мысленный эксперимент (а лучше эксперимент с помощью карандаша и бумаги). Попробуйте преобразовать заготовку-примитив в Вашу схему, с помощью конечного числа шагов идеального дракон-редактора, соответствующего моему описанию.
Если получится, значит, Ваша схема правильная. И наоборот.

6. Описанная проверка (через действия редактора) не заменяет проверку на соответствие формальному описанию, а дополняет ее. Хотя по сути эти проверки тождественны. Преимущество проверки через действия редактора состоит в том, что она более наглядна. В том смысле, что «метод через построение» позволяет пощупать построение руками (на каждом шаге построения).

ВЫВОДЫ

В1. Графический синтаксис языка ДРАКОН определен двумя разными методами: декларативным и процедурным, каждый из которых является математически строгим.

В2. Декларативный метод представляет собой формальное описание графического синтаксиса с помощью 37 тезисов.

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

В4. Все сказанное выше про примитив относится и к силуэту.

==============================================

Повторю главную мысль. Графический синтаксис языка ДРАКОН описан не одним, а двумя разными способами. Это улучшает надежность описания и упрощает возможность его проверки.
http://drakon.su/_media/biblioteka/chas ... isanie.pdf

Точнее, в двух разных формах - т.к. глава о конструкторе есть в своей основе Гл.14 из "Как улучшить..." - и представляет описание реализации исчисления, т.е. другую форму операционного же (как ещё говорят математики) способа определения. Илья то же называл конструктивным - "КАК <правильно> построить из базиса" (в данном случае - шампур-схему): viewtopic.php?p=39784#p39784.

Декларативный же (в математике мне привычней "денотационный") способ - это указать, "ЧТО есть правильно построенное" (и д.б. справедливо на любом шаге построения по операционному определению). А у Ильи говорится там же об аксиоматическом, причём эти два понятия и отделяют друг от друга как два разных подхода - здесь математическая специфика или подходы разных школ - это надо подумать теоретикам. В таком ключе в рамках исходной ветки высказывались как Илья: viewtopic.php?p=70288#p70288, так и Алексей: viewtopic.php?p=70524#p70524 - и сам Эдуард указал на вопросы, сохраняющиеся при "процедурном" определении по тезисам к результату с "декларативных" (денотационных) позиций: viewtopic.php?p=70569#p70569.

Ключевая мысль - в многоадресном силуэте появляется подмножество адресов веток, не детерминируемое каким-то линейным порядком на схеме. Это адреса в побочных выходах (заземлённых). Эти адреса назначаются сочинителем в общем случае произвольно. Именно такой случай и задан авторским определением ШМ для силуэтов. Что при этом получается - сказал опять же Алексей: viewtopic.php?p=70384#p70384. А для отражения частных случаев, когда какие-то типы переходов с побочных выходов недопустимы, нужно различать типы структур многоадресных силуэтов и порождающие их типы побочно-силуэтных БП. И уже на этой базе формулировать ограничения, исключающие структуры, недопустимые исходя из заданных целей (напр, структурность по Бёму-Джакопини, Дейкстре или что-нибудь менее строгое).

Тут что важно? Все перечисленные участники вводили разметку графа, индивидуализирующую и ветки, и веточные макроциклы. Т.е. уходили от ограничения предмета определения только "слепышами". На самом-то деле попытки денотации просто показали, что точное определение многоадресного силуэта при любом подходе требует такой разметки. Как она используется в конструктивном определении - можно видеть, скажем, здесь: viewtopic.php?p=70770#p70770 (тот же мотив можно видеть у Алексея, когда он говорит о "допограничениях" - ибо их можно сформулировать, лишь различая ветки и ВМЦ между собой).
Но, коль скоро опять сказано, то, что в стартовом посте под 1) - ясно, что дальнейшее обсуждение наиболее вероятно по схеме "есть два мнения - моё и неправильное"... Ибо чисто теоретически, быть может, можно индивидуализировать каждую ветку и ВМЦ в схеме и графически - но реально естественной формой разметки будет текст... Если так произойдёт - полезность обсуждения станет сомнительна.

Уважаемый Владислав!

Вот пример графической разметки для случая, когда в силуэте два веточных цикла.

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

Оба цикла — благодаря белому пятну на черном фоне — зрительно хорошо отличаются друг от друга.
Сразу видно, где один цикл, а где второй.
По моему, никаких проблем нет. Как Вы считаете?



Это рис. 148 из книги "Дружелюбные алгоритмы".
Похожие алгоритмы для атомного реактора есть в книге "Учись писать. читать и понимать алгоритмы" (рис. 183 и 184).

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

Это позволяет облегчить работу читателя подобного сложного алгоритма с непоследовательной структурой.

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

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

Действительно, начало и конец каждого цикла прекрасно различимы.
Но, что делать если веточных циклов больше 2-х? В чёрные треугольники вписывать различные белые геометрические фигуры?


Уважаемый Владимир Паронджанов!

Опять у меня вопрос о дополнительных входах СПРАВА в веточных циклах.
Я смотрю на представленный Вами рисунок (см. выше) и вижу два пересекающихся веточных цикла.
Описания пересекающихся веточных циклов у Вас я не нашёл.

На мой взгляд цикл «Овладение мудростью» имеет дополнительный второй вход через икону Имя Ветки «Похищение сокровищ». Вроде бы раньше утверждалось, что ЛЮБЫЕ циклы не могут иметь дополнительных входов. Возможно я что-то пропустил или не так понял.

Для того чтобы явно увидеть пересекающиеся циклы я построил схему-примитив (см. ниже) аналогичную представленной схеме-силуэт (если нигде не ошибся).

Если число веточных циклов больше 2-х, можно, например, поступить так, как предложили Вы, то есть с помощью различных белых геометрических фигур.

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

Пример 2. Для четвертого веточного цикла черный треугольник рассечь двумя белыми горизонталями.

Если число веточных циклов больше 4-х, можно, например, поступать так, как в книге "Как улучшить работу ума" в главе 13 Стр. 206, 207 (рис. 105). То есть, нумеровать 5, 6, 7 и т. д.

На сегодня более точного ответа у меня нет.

Вы правы. Возникает вопрос: как быть?
Я склоняюсь к тому, что подобные веточные циклы следует разрешить.

Вы согласны? Или у Вас есть возражения?

Лично я согласен : )

Дык оно и не нужно. Потому и говорил: Как раз отсутствие в исходных ШМ-определениях какой-либо атрибуции для вершин, рёбер (кроме базовых типов ввода - если их понимать по Рэйлвей Кагену, то это атрибут именно ребра, а если по В.Д. - то точки ввода), а также для к.-л. подсхем (в частности, веток и ВМЦ) и соответственно - любых правил, связанных с такой атрибуцией (кроме опять же типизации ввода - по срочности), и означает, среди прочего, что допустима любая связность побочных выходов со входами веток в силуэте. И ни в каком специальном указании это не нуждается - м.б. только в пояснении, что оно именно так потому, что мы не включаем в рассмотрение свойства (естественно выражаемые через текст).
Примером "декларативного" определения схем, кстати, может служить эта графит-схема. Здесь общий случай адресации выражен графически - через БП-рёбра (выделяемые нетонким серым пунктиром - дальнейшие вариации по толщине линии/градации серого уже связаны с указанием областей действия ИЛИ-выбора).

В таком виде силуэт в импер-интерпретации как раз может описывать систему переходов для машины фон Неймана (с "джампами"). Т.е. обычный асмкод или такую его прямую абстракцию, как Фортран 66 или Си...
Впрочем, для первого надо ещё добавить такую штуку, как выраженьевость БП (т.е. адресов веток). Судя по тому, что этого в ШМ нет, Фортран СЗХ, служить средством граф-базной записи которого было одним из исходных назначений техноязыка, имел только невычисляемый goto...

Вот если мы хотим как-то ограничить (скажем, не допускать пересечений контуров) - тогда и становятся нужны специальные описания. В операционном определении - как часть тех же тезисов.

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

А что же с теми самыми выходами "справа-слева", т.е. обсуждавшимся здесь: viewtopic.php?p=70770#p70770? Как это выразить? Можно через отношение порядка, как и задано в посте. Но. Мы должны либо снова строить "объёмные связи", как говорит Дмитрий_ВБ - т.е. "снимать кросс силуэта", показывая каждый переход отдельно. При этом полученные контуры не должны пересекаться - тогда и при "примитивизации" (которую выполнил Эдуард выше) это сохранится. Либо всё-таки индексировать ветки и петли ВМЦ и сформулировать системы неравенств от этих индексов. Т.е. ввести в метод неграфовый компонент.

Замечу - обсуждавшиеся выше нецифровые обозначения (для ВМЦ) на самом деле не относятся к графам. Ибо есть по сути те же цифры, только по-иному записанные... Т.е. мы не можем говорить, что с их помощью мы ушли от текста. Вот вводя новые рёбра/вершины/подграфы для выражения - можем.

И вот вопрос по существу - а всё ли хотя бы сформулированное в указанном посте мы можем выразить через графы для общего случая? И даже если что-то можем - не слишком ли это усложнит определение? Не проще ли сочетать графовое с текстовым - для чего ввести атрибуты элементов и отдельных видов подсхем в исчисление?..

Ну, более точный ответ, очевидно, даёт математика. В данном случае дискретная. Если исходные посылки математики непрерывной можно шутливо выразить фразой одного из героев Стругацких "- Извлечём из чего-нибудь квадратный корень" (формально и общо - возьмём некие приближённые числа и вычислим/сравним их неким приближённым образом), то дискретной - "- Занумеруем что-нибудь и попробуем расположить как-нибудь". Т.е. атрибутируем наши дискреты числами (обычно - из натурального ряда) и зададим любые (или какие-то интересующие нас) их порядки. Ну а дальше - анализ и синтез...
Вот и Вы предложили нумерации ВМЦ - нечисловую (для 2..4 ВМЦ) и числовую (для 5 и более). Но в любом случае неграфовую - ибо порядок не выражен через связи элементов (в данном случае - петель ВМЦ, "вписанных" в петлю силуэта)...

Есть вопрос - а почему нужно разрешить? и что значит "подобные"?
В джамп-коде и неструктурном ВУ-представлении потока управления можно разрешать ведь вообще любые переходы...

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

По-моему, так она уже давно сомнительна, поскольку идёт не в том направлении. Поэтому возьму на себя смелость ответить на вопросы, заданные в ЛС, здесь - как повод ещё раз изложить основные тезисы, претензии и надежды на опыт Паронджанова и его дальнейшее развитие.

По-моему, ясно ответил: "На сегодня более точного ответа у меня нет", что по сути означает: не прорабатывал этот вопрос ни теоретически, ни практически (видать, писали программы так, чтобы не встречались столь "сложные" случаи).

Моё мнение - нет.
И даже думать на эту тему бессмысленно - ибо я принципиально против силуэта.
Поскольку он есть по сути фиговый листок для сокрытия беспорядочных goto вместо чёткой структуры циклов.
То, что Паронджановской команде удавалось писать качественный код на этой штуке, говорит, видимо, просто о культуре программирования, а отнюдь не о качестве языка...

Что хочу я? Я хочу видеть тело каждого цикла.
И, если уж накладывать структурные ограничения, то полностью, а не частично, с необходимостью плясок с бубнами вокруг силуэта.

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

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

Здесь я тоже категорически возражаю Владимиру Даниеловичу, приверженцу жёсткой бумажной копии. Возможно, я не оценил прелести такой работы, ну да и ладно. У меня дома вообще принтера нет, какая нафиг бумажная копия.

Я всегда говорил о том, что неободимо не зацикливаться на пропаганде Дракона, а продолжать создание действительно эргономичного инструмента.

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

Ну вот, в кои-то веки, послышался голос Разума.
Браво, Alexey_Donskoy!

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

Моя дата - 24 Апрель, 2009

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

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

А вот тут согласен - особенно в предположении, что основным методом достижения качества становится расчётно-логическое проектирование программы (и инструкции). И тут конкретный вопрос:
Точнее, нарезать тело схемы на равновысотные фрагменты, чтобы скомпоновать схему в целом под нужный формат/размер диосцены... то, что здесь я называл "эргопереходом к силуэту"...
Вопрос - а если не используем goto, как в случае ЦД - как думаете, на две и более ветви декомпозировать то или иное укрупнённое действие по такому же основанию неоправданно?..

Обратите внимание, что "рассмотрен" и "глубоко проработан" - разные вещи. Как разны и позиции автора в тех моментах, где он не может поступиться принципами и где "можно, например, поступать так"...

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

Есть инструменты адекватные и не очень. Силуэт прекрасен для автоматной логики, как уже много раз говорили.

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

Вы издеваетесь? Я специально пробовал решить таким путём элементарную задачу копирования - что-то путное из этого вышло?!

Нет, не точнее.
Имхо, компоновка по смыслу и компоновка "под формат/размер" - вещи разные.
Первое относится к когнитивной эргономике, второе - только к визуальной составляющей.

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

Наконец, возвращаясь к циклу, мы видим, что можем изобразить его двумя путями (!): как обычный цикл, с условным оператором и возвратом, и как веточный цикл, где дуга возврата разрывается, проходя через адресные конструкции силуэта. Подобная двусмысленность представляется мне как минимум эргономически неоправданной, да и вообще методически неверной.

Ну, в общем-то я ожидал примерно такого и в целом согласен... только более сдержанно... Разве что уточнить:
Возможно, в "примитиве" указание петель циклов тоже будет обосновано - и именно при представлении автоматной логики (если точно - то информатизации диаграмм переходов). Имеется в виду описанное здесь в п. 2: viewtopic.php?p=65423#p65423. Сверхциклы по цепочкам состояний (для них, кстати, приставка "макро" м.б. естественнее, чем для веточных) полезно прослеживать.

Но, вероятно, возможны и машины с реализацией цикла в СК?
Замечу, что я-то как раз ограничивался реализацией именно петли цикла - в смысле разобранного здесь. Вы смотрите шире - что правильно.

Ну я ж не зря сказал дальше "при условии..." Смотрят люди на схему - и при сложившихся навыках визуально-структурного анализа и ряд аспектов работоспособности выявляют, и оптимизировать могут... полуформально, но им достаточно...

"Точнее" относилось к предыдущему предложению... неточно процитировал...

Не говоря уж, как разрывается в цикле ДЛЯ (что идёт уже из ГОСТ/ИСО)...

Цикл можно изобразить ещё одним способом (см. ниже), не привлекая сущности за пределами описанного множества элементов языка ДРАКОН.
Правда при этом появляется некоторая избыточность.
Но эту избыточность можно попробовать попользовать с пользой.
Пока думаю как : )

Скорее, это не "ещё один способ", а попытка шага в сторону формального отображения семантики цикла. Обобщённого.
По сути с этого бы и надо было начинать

Короче, ещё один способ показать LOOP-EXIT?.. А как обобщённый цикл в Вашем понимании соотносится с "гибридным" (см. здесь)?..