DRAKON.SU

Текущее время: Воскресенье, 15 Декабрь, 2019 15:26

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 292 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14, 15  След.
Автор Сообщение
СообщениеДобавлено: Понедельник, 25 Январь, 2010 06:11 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
...нет анализа вновь вводимых сущностей на предмет непротиворечивости с базовым Драконом на уровне языка - с иконами, маршрутами и правилами).

Я тут попробую порассуждать... Разделим предмет анализа (МШ-язык), как и ДРАКОН, на маршрутную часть и немаршрутную. Последняя "спрятана" в составе и содержании текста МШ-икон и по определению для узлов подлежит алгоритмизации; делается это по правилам ДРАКОНа на основе заданных дракон-моделей, и тут противоречия не будет - главное, чтобы суть расщепления/сбора раскрывалась дракон-моделями правильно, но это уже другой вопрос - к корректности методики алгоритмизации.

Первая же часть связана с абстрактными МШ-схемами (слепышами). Здесь отправная точка - доказанные Паронджановым теоремы 1 и 2 (нас интересует больше вторая).
Сначала рассмотрим, как сочинить некий МШ-слепыш в диоформе силуэта (или примитива), пользуясь операциями прибавления структурных элементов (и прежде всего ввода атома). Заготовки-аксиомы выбраны те же самые, правила вывода прибавлением в МШ те же, что и в ДРАКОНе; расширено лишь множество атомарных макроикон на Мультишампур. Положим, что он (без текста) топологически эквивалентен макроиконе Переключатель. Для обоснования этого утверждения нам потребуется определение древесных точек дракон-переключателя, показанное здесь при описании сложных ветвлений и операций перевода на ДРАКОН (далее независимый шампур назовём Н-шампур).
Здесь рассмотрим два случая вначале для примитива:

1) все МШ-узлы имеют тип "один из многих";
2) имеется хотя бы один МШ-узел типа "не один из многих".

В случае 1) получается схема-слепыш, эквивалентная дракон-схеме (имеется в виду именно топология). Обоснование этому следующее. По определению узла расщепления типа "один из многих", имеем право заменить его на слепыш шапки переключателя; аналогично узел сбора "один из многих" заменяется на подвал переключателя (т.е. дерево "подвального сбора", которое после эргономических упрощений изображается как "гребёнка зубцами вверх"). Полученная схема есть дракон-схема.
Теперь разберём случай 2). Перевести узлы (некоторые или все) типа "не один из многих" прямо на ДРАКОН в смысловой схеме не получится; нужно алгоритмизовать. Однако утверждаю, что абстрактную МШ-схему можно приравнять к абстрактной дракон-схеме так же, как для случая 1). Обосновываю это так: обе они есть формы произвольной схемы деятельности, т.е. графа, обладающего такими свойствами:
    а) этот граф ориентированный с циклами;
    б) среди всех вершин этого графа имеется одна или несколько начальных, из которых только и могут начинаться любые маршруты на графе;
    в) имеется также одна конечная вершина, к которой только и могут вести все маршруты на графе (включая циклические, если их развернуть, полагая число циклов конечным);
    г) интерпретацией смысла (как говорят, "надстройкой") этой структуры является некое вычисление - получение объектов-результатов из исходных объектов (те и другие указаны деклар-текстом вершин и в случае физического процесса м.б. вещественно-энергетическими, а в случае информатического - данными) посредством операций, заданных командным текстом икон.

    Замечание: качественно понятно, что число циклов (повторений некоторого подмаршрута подряд) д.б. конечным для целесообразной деятельности; даже "зацикливание" примитива/силуэта реального времени здесь не нарушает общности, т.к. ясно, что реальный исполнитель работает ограниченное время, следовательно и число циклов всё равно будет конечным; кроме того, и в этом случае можно указать конечную вершину схемы - это та икона, по которой происходит "риторический" возврат управления в точку после иконы основного/единственного входа, что показано здесь при описании "зацикливания" примитива).
    Замечание 2: силуэт можно "перевести обратно" в драконоподобный примитив с сохранением разрешённых БП, как показано здесь при описании топологического перехода. При этом сохраняются и допвходы, если они были добавлены. Это представление имеет смысл не только в символическом представлении алгоритма; подобным образом и дракон-силуэт представляется как дракон-примитив с добавлением БП (но по несколько другим правилам) для последующего машинного кодирования (имхо, это и есть модификация шампур-метода для ассемблера).

Очевидно, что слепыш МШ-примитива удовлетворяет всем этим требованиям; а узлы "не один из многих" при абстрагировании трактуются как узлы "один из многих" с одним уточнением - МШ-специфичный текст каждого поля переносится в свою метку. А слепыш МШ-силуэта есть лишь способ укладки на плоскости произвольного графа деятельности (слепыша МШ-примитива с пересечениями). Значит, мы также можем раскрыть топологию МШ-узлов с использованием двоичных деревьев "шапочного разбора" и "подвального сбора", т.е. прямо перевести на ДРАКОН структуру маршрутов (и только) любой МШ-схемы.
Итак, операции прибавления структурных элементов (атомов) МШ-метода эквивалентны операциям шампур-метода, т.к. определены для абстрактных схем деятельности, а в этой форме записи единственный новый объект МШ-метода можно приравнять к одному из существующих в шампур-методе. К нему можно применить и добавление варианта (в смысловой записи - изначально пустого Н-шампура с критической точкой ввода), и боковое присоединение (однако синхронизация, я полагаю, будет относиться к процессу общего поля; для частных предлагается ввести внутрь поля зону-трапецию, имеющую тот же смысл).
Если же мы можем приравнять абстрактный МШ-примитив к абстрактному дракон-примитиву с той же структурой маршрутов, то по Теореме 2 можем уложить его в силуэт тем же образом (с точностью до типа икон Имя ветки и Адрес; переопределение их типа не происходит, т.к. приравненный к переключателю мультишампур вначале укладывается в одну ветку целиком), получив структуру из того же многообразия вариантов укладки; единственное отличие - появление меток (которые можно рассматривать как аналоги надписей в развилке; опять-таки несущественное отличие - у МШ-узла есть надпись также и при единственном входе/выходе).

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

В случае Б) у нас получится абстрактная схема "МШ-силуэт", отличающаяся от МШ-примитива, уложенного в силуэт по шампур-методу, следующими особенностями:
    А. разрывами некоторых линий (обозначены парами МИ7+МИ8 с одинаковым текстом), не входящими в петлю силуэта - это всё те же временные пересечения.
    Б. в петле МШ-силуэта разрывы Н-шампуров (как результат их заземления также на Н-шампуры) обозначены также иконой МИ8 на конце заземлённого шампура и МИ7 с тем же текстом-индексом - в начале ветки, где этот шампур продолжается (снова уходя в подвал силуэта иконой МИ8) или заканчивается (если до следующей иконы подвала силуэта присоединён к узлу сбора; выход этого узла уже логически другой шампур, независимый только если является частью более раннего расщепления, чем рассматриваемое).
Итак, "переключатель", в который переводим абстрактный МШ-блок, м.б. разорван между ветками; каждый его "вариант" (частное поле расщепления) как бы посылает вперёд по шампуру своего "представителя" в виде иконы МИ7 (в шапке силуэта) в каждую ветку, продолжающую раскрытие этого "варианта". Это вытекает из того, что в созданной версии МШ-метода мы допустили размещение узлов-границ одного Н-шампура в разных ветках (как результат операций пересадки шампура в данном определении); это можно и запретить (это, как я понимаю, сделано Тышовым в ГОСТ-реализации), но тогда:
    - придётся умещать весь МШ-блок в одну ветку;
    - если в МШ-блоке есть пересечения - всё равно нужно их уложить в петлю силуэта.

Вопрос 1: нельзя ли без пересечений в МШ-блоке? - В общем случае нельзя, т.к. мы визуализируем "поведение" как любой мыслимый сбор ранее расщеплённых Н-шампуров. Это и есть суть расширения языка - а за ней тянется и расширение объектов для укладки в силуэт.
Т.е. разносить части МШ-блока по разным веткам можно (а если в МШ-блоке есть пересечения - то и нужно).

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

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

Вопрос 3: а дракон-переключатель всегда полностью располагается внутри одной ветки дракон-силуэта? - Нет, только если ни одна его побочная вертикаль не заземлена. В противном случае получается, что "подвал" переключателя реализуется петлёй силуэта (это нетрудно понять, имея в виду, что "гребёнки" силуэта без эргоупрощений техноязыка также есть двоичные деревья на базе соединителей/разветвителей); при этом продолжением его главной вертикали служит шампур той ветки, на которую указывают адреса заземлённых лиан (м.б. не сразу в первой же ветке после той, которая содержит "шапку" рассматриваемого переключателя; тогда имеем, как и для Н-шампура, цепочечный разрешённый БП, т.е. продолжение содержания варианта в следующих ветках с "посылкой представителей" в шапке силуэта уже в виде икон обычного БП с неспецифическим текстом).
    Для произвольного ветвления типа "матрёшка переключателей" (жарг. "кейс по кейсам") при заземлении логика несколько усложняется: сначала надо свести лианы от внутренних переключателей, потом результаты этого сведения свести между собой; однако полученную структуру можно при некоторых условиях горизонтально объединить.
Для любой структуры ветвления силуэт даёт возможность за счёт адресации веток по петле как бы "визуально сократить" дублирующиеся в примитиве конструкции "подвального сбора"; так можно поступить с "многоэтажным" подвалом "переключающей матрёшки" (по аналогии с горизонтальным объединением).

Т.о. для преобразований топологии графа деятельности тип узла роли не играет (это относится и к переопределению икон Имя ветки и Адрес). Если рассматривать только топологию, то и специфические операции МШ-языка эквивалентны операциям ДРАКОНа, т.к. тип узла есть главное их расширение, и остальные МШ-особенности, как мы показали, не влияют на эквивалентность содержащей их абстрактной МШ-схемы некоей абстрактной дракон-схеме, в которой МШ-узлы расщепления (сбора) заменены на шапки (подвалы) дракон-переключателя.
Эквивалентность топологии МШ-схемы и схемы-результата её перевода на ДРАКОН (если принятая выше трактовка расширения логически корректна) позволяет применить неспецифические правила вывода ДРАКОНа для абстрактной МШ-схемы как для обычного силуэта/примитива, что вытекает из Теорем 1 и 2. Это обосновано выше (в силуэте - как для разнесённых МШ-блоков, так и для сосредоточенных по веткам).

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

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

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

Подчеркну: всё это имеет силу именно постольку, поскольку границы независимости (узлы) в МШ-силуэте остаются в теле ветки; если пытаться "скрещивать" эти границы с силуэтом как одной из конкретных диоформ графа деятельности, то вот там начнутся математические дебри (возможно, преодолимые для опытного математика-графовика; я к таковым себя не отношу, поэтому молчу :))... впрочем, одну вещь, ясную интуитивно, скажу: мы можем получить неэквивалентность одной и той же структуры деятельности в формах примитива и силуэта...
Правильно ли я рассуждаю? Опытные математики, ау-у :)


Последний раз редактировалось Владислав Жаринов Суббота, 30 Январь, 2010 05:57, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 30 Январь, 2010 05:42 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Эдуард Ильченко писал(а):
Для развития идей мне не хватает инструмента. То бишь редактора : ))), который позволял бы быстро реализовывать придумки. Меня интересуют больше практические вопросы. И если бы существовал бы готовый редактор, закрывающий эти вопросы, то я бы им с удовольствием пользовался бы. Но... к сожалению доступен только редактор уважаемого Геннадия Тышова, в котором отсутствуют необходимые мне возможности.

Банальность скажу, но быстрее всего реализовывать придумки в работе с данными не в специализированном "говорителе" на формальном языке, даже когда в нём присутствуют все возможности. Вон взять Ты-среду - чтобы создать ГОСТ-блок независимых шампуров, нужна целая процедура (Геннадий писал об этом здесь) - и это же не потому, что "редактор плохой", а как раз потому, что он вполне точно следует ограничениям формального языка как исчисления (и ещё м.б. вводит свои как результат информатизации этого исчисления); другое дело, что неплохо иметь методики выполнения каждой практически значимой техоперации (они в этой теме фактически и нарабатываются потихоньку).
Так что проще рисовать, не связываясь ограничениями; и здесь любое средство, начиная с карандаша и бумаги, будет "альтернативным". Для эффективного создания схем таким способом, разумеется, лучше не карандаш и ластик и не их машинный аналог - перо рисующее и стирающее в пэлграф-редакторе, а редактор элементной графики с соответствующим пользовательским набором элементов: Вы, как я понимаю, сделали это для Diagram Designer'a, я пользуюсь OpenOffice (а иногда, кстати, и на бумаге рисую ;)), кто-то ещё чем-то.
Если хотите поработать с МШ-языком, то вот набор элементов для Draw (версия 2.4.0); вместе с документами ДРАКОНа с этой страницы он составит базовую инфоподдержку. Здесь, кстати, реализовал идею об указании времени старта шампуров в зонах-"ванночках" частных полей узла типа "не один из многих"; это делает ненужным указание временнОго типа узла графикой - для синхронного узла все времена равны нулю, для асинхронного нулевое значение указывается только для одного шампура - эталонного - у остальных время при расщеплении д.б. больше, а при сборе меньше (всегда со знаком минус). Как это алгоритмизовать - уже предлагал на стр. 12 Рабочего определения. Чтобы проще начинать, в другом файле МШ-схемы по мотивам Вашей задачи (тоже в Draw, но с прежней версией узлов); М.б. изобразите в числе прочего, какой д.б. асимметрия МШ-блоков :)

Эдуард Ильченко писал(а):
Я намерен посвятить свободное время проработке вопроса об альтернативном редакторе. В случае положительного результата обязательно отпишусь на форуме.

А потом можно будет вернуться к теоретическим вопросам : )

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


Вложения:
A3L МШ-схемы - алфавит (нов).odg [23.33 КБ]
Скачиваний: 325
A3L МШ-схемы - примеры (исх).odg [29.78 КБ]
Скачиваний: 282


Последний раз редактировалось Владислав Жаринов Суббота, 30 Январь, 2010 05:55, всего редактировалось 1 раз.
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 30 Январь, 2010 05:44 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
Интересны обозначенные проблемы с циклами. Мне кажется, что рассматривать их можно в классической терминологии, т.к. похожие вопросы возникают и при использовании ГОСТовской нотации.

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

Я лишь ослабил его силу: можно разрывать МШ-блок между ветками (посредством независимых БП), но только в тех местах Н-шампуров, которые не охвачены петлями циклов (обычных). Единственный смысл такого ослабления - необходимость/желательность эрговыделения веток (по "правилу Я. Романченко"); однако нарезать надо все Н-шампуры, сходящиеся далее на один узел сбора, что не всегда повысит удобство восприятия МШ-силуэта. Если цикл по всему Н-шампуру - всё равно можно вставить независимый БП в самое начало и/или в самый конец такого шампура; но тут уже и эргономическая ценность результата сомнительна... к сожалению, так всё равно придётся делать, если зацикленные Н-шампуры ещё и пересекаются (см. предыдущее сообщение; кстати, оно несколько дополнено).
Обоснование: смысл частных полей МШ-узла при алгоритмизации - частные алгоритмы, порождаемые алгоритмом общего поля узла расщепления (иконами И20-Старт). Эти алгоритмы выполняют свои функции, описанные в Разд.2 Рабочего определения, и пытаться охватить их циклом, проистекающим из логики процесса, заключённого внутри узлов, не следует.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Февраль, 2010 11:59 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4531
Откуда: Москва
Рэйлвэй Каген писал:

Цитата:
Покритикуйте пожалуйста

viewtopic.php?p=40315#p40315

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Февраль, 2010 05:52 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ещё относительно употребления циклов и других особенностей МШ-схем. Каждый МШ-блок можно рассматривать как сетевой график, где МШ-узлы являются событиями, а Н-шампуры - работами. Интерпретация узла расщепления - событие "много работ после одной", узла сбора - событие "одна работа после многих"; событие "много работ после многих" представляется как цепочка "сбор-расщепление". Индексы МШ-узлов отражают топологическую сортировку событий на графике (возможно, вводятся дополнительные событийные индексы). В этом случае справедливо следующее:

    1. Циклы внутри МШ-блока допускаются только по отдельному Н-шампуру (т.е. как содержание одной работы). Если Н-шампур в МШ-силуэте разбит на ряд веток, возможны и веточные циклы, т.е. заземлённые Н-лианы могут указывать на одну из предшествующих веток того же (и только того же) Н-шампура (напомним, что в текст икон Н-БП обязательно входит индекс Н-шампура).
      Не допускается цикл, не ограниченный одним Н-шампуром, т.к. его петля становится дугой сетевого графика и образует в нём контур, что не допускается. Причину этого легко понять, вспомнив, что направление дуг работ есть направление течения времени; при наличии контуров получится, что время может течь вспять :) Это же относится к зацикливанию одного из выходов узла расщепления; высказываясь о желательности такой возможности ранее, я имел в виду ожидание наступления условий старта по другим выходам, а это решается внутри алгоритма общего поля узла.
    2. Возможен цикл, охватывающий МШ-блок. Это понимается просто как повторный проход по той же сети работ. Если такие циклы входят в нагрузку Н-шампуров другого (охватывающего) МШ-блока, последний в этом случае также можно трактовать как сетевой график, если все циклы сначала развернуть.
    3. Каскад (дерево одновидовых узлов без нагрузки Н-шампуров между ними), вообще говоря, отражает просто детализацию условий "внешнего" из узлов (корня дерева); такой каскад следует понимать как одно событие. Возможно, корректней будет ввести каждый "внутренний" узел в состав предыдущего, добавив туда новые частные поля и расширив условия общего, и так до корневого узла.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Февраль, 2010 10:52 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Драконограф писал(а):
..получится, что время может течь вспять :)
Классная трава! Но управление после отработки тела цикла передаётся по адресу, а не в направлении течения времени. Вы, вроде бы, не циклограммы рисуете..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Февраль, 2010 13:30 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 631
Откуда: Россия, Орёл
В направлении, в направлении. Если понимать алгоритм как шаблон возможных процессов, то цикл в нём - это "свёртка" для периодического участка в процессе.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 09 Февраль, 2010 18:59 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Если эта "свёртка" на уровне ассоциаций не сложнее мотка верёвки, то согласен. Только забредёт кто-нибудь на уровне свёртки во временнОй области, и будет долго-долго думать, где же он чего не понял.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Февраль, 2010 06:00 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
Если эта "свёртка" на уровне ассоциаций не сложнее мотка верёвки, то согласен. Только забредёт кто-нибудь на уровне свёртки во временнОй области, и будет долго-долго думать, где же он чего не понял.

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

В общем, МШ-модель (или любая аналогичного назначения) представляется мне как результат информатизации (т.е. сведения математической модели к дискретной, конечной и выполнимой, т.е. детерминированной для конкретного формального исполнителя с его репертуаром, багажом и реквизитом) сетевой модели деятельности.
Рэйлвэй Каген писал(а):
Вы, вроде бы, не циклограммы рисуете..

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 10 Февраль, 2010 14:48 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Драконограф писал(а):
Вообще-то..
Высказывание относилось к Дракон-схемам, а не к результатам их преобразований.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 17 Февраль, 2010 06:16 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
В связи с вопросом Эдуарда из этого сообщения и чтобы довести до логического конца - недавно обнаружил похожую тему. Оказывается, первая из идей для совмещения в одном силуэте разных алгоритмов - образование несвязанных цепочек веток путём разадресации подвала (назовём её "кластеризация веток") - уже обсуждалась, правда, несколько в иной форме и как ошибка (действительно, если имена веток в иконах Адрес - константы, то появляются неисполнимые ветки, и только). Напомню остальные идеи, делающие это осуществимым:

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

Идея 3) не связана исключительно с механизмом кластеризации силуэта. По сути, речь идёт о введении переменной-указателя на процедуру/функцию (роль которой может играть и отдельный визуал, а если принять предложение dvuugl в этом сообщении то, по сути, и отдельный фрагмент силуэта, начинающийся с любой ветки; однако по правилам допвхода ДРАКОНа, т.е. не попадая внутрь веточного цикла - м.б. лучше передавать только на допвход).
Но главное - можно показать получение имени алгоритмически (в конечном счёте - операции над адресами дракон-программ и подпрограмм). Можно и в ходе исполнения формировать маршрут по помеченным элементам силуэта (входам) и вызывать из него другие визуалы параметрически (выбирая имя для очередной вставки).
Наверное, "эту мысль можно ещё думать" :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 19 Февраль, 2010 09:50 

Зарегистрирован: Воскресенье, 04 Ноябрь, 2007 23:01
Сообщения: 512
Тут такое дело.. Некоторая несимметрия правил "вынуждает" следовать в определённом направлении. Если параметризовать "Адрес", то пользователь неизбежно растопырится в позе буриданова осла, выбирая, где ему реализовать параметрическое ветвление - внутри ветки(по классике) или в петле силуэта. А когда наворотит и там, и там, то изучать такую дракон-схему будет сплошная морОка.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 19 Февраль, 2010 10:44 

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 140
Откуда: Троицк, Москва
Драконограф писал(а):
... Наверное, "эту мысль можно ещё думать" :)
Предпочитаю не встревать в Драконовские темы, но тут не могу не указать на несоответствие сложности обсуждаемых конструкций с заявляемой (совсем недавно ИЕЕ формулировал) целью, чтобы Дракон был инструментом для инженеров, не умеющих программировать.

От цитируемого сообщения впечатление, что научиться работать на Драконе не особо проще, чем научиться программировать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 19 Февраль, 2010 20:24 

Зарегистрирован: Воскресенье, 06 Апрель, 2008 14:43
Сообщения: 1657
Рэйлвэй Каген писал(а):
Тут такое дело.. Некоторая несимметрия правил "вынуждает" следовать в определённом направлении. Если параметризовать "Адрес", то пользователь неизбежно растопырится в позе буриданова осла, выбирая, где ему реализовать параметрическое ветвление - внутри ветки(по классике) или в петле силуэта. А когда наворотит и там, и там, то изучать такую дракон-схему будет сплошная морОка.

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

У Вас так сложно, не соответствует назначению, изложению и духу языка Дракон по В.Д. Паронджанову.

Info21, для практики, грамотному человеку, достаточно книги "Занимательная информатика" и выдержек из книги "Как улучшить работу ума".

Уважаемые Владимир Паронджанов и модераторы форума, книгу "Занимательная информатика" от 2000 года было бы хорошо выложить в WIKI для скачивания.


Последний раз редактировалось ==== Суббота, 20 Февраль, 2010 08:20, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 20 Февраль, 2010 01:40 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Рэйлвэй Каген писал(а):
Тут такое дело.. Некоторая несимметрия правил "вынуждает" следовать в определённом направлении. Если параметризовать "Адрес", то пользователь неизбежно растопырится в позе буриданова осла, выбирая, где ему реализовать параметрическое ветвление - внутри ветки(по классике) или в петле силуэта. А когда наворотит и там, и там, то изучать такую дракон-схему будет сплошная морОка.

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 02 Март, 2010 22:12 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4531
Откуда: Москва
Предлагаю Вашему вниманию схему с шестью параллельными процессами.

Используется только одна икона " параллельный процесс".

Аналогичный ( но не тождественный) пример показан в книге
"Как улучшить работу ума..." на стр. 168 (рис.84).


Вложения:
Комментарий к файлу: Шесть параллельных процессов
0Рис.123.png
0Рис.123.png [ 38.07 КБ | Просмотров: 15870 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 05 Март, 2010 05:59 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Владимир Паронджанов писал(а):
Предлагаю Вашему вниманию схему с шестью параллельными процессами.

Используется только одна икона " параллельный процесс".

Я, наверное, чего-то не понял... а сколько ещё икон (понимая как алфавитный знак) можно было использовать? :wink:

О смысле текста икон: сообщение процессу-потомку "Пуск" мне понятно, а что значит сообщение "Выдать"?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 05 Март, 2010 12:58 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4531
Откуда: Москва
Драконограф писал(а):
Я, наверное, чего-то не понял... а сколько ещё икон
(понимая как алфавитный знак) можно было использовать? :wink:

Сообщение процессу-потомку "Пуск" мне понятно,
а что значит сообщение "Выдать"?


1. Число параллельных процессов практически не ограничено.

2. Выдать -- значит Выдать команду.
Командой называется порция инфрмации, выдаваемая
из бортового компьютера "Бисер" и передаваемая по проволоке
к абоненту.

Команда, например, может взорвать пиропатрон,
что приводит к разделению ступеней ракеты.

Идентификатор команды порождает согласованную работу
центрального процессора и процессорв ввода-вывода.

Более подробно про команду можно посмиотреть здесь:
http://oberoncore.ru/wiki/drakon/start

В разделе Применение
найдите
Извлечение из документа "Язык ФЛОКС. Руководство алгоритмиста" (pdf).
См. стр. 35--40
http://store.oberoncore.ru/lib/paper/GrafitFloks.pdf

Примечание. Команду у нас (в нашем НПЦ) не принято
называть параллельным процессом


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 05 Март, 2010 14:00 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4531
Откуда: Москва
Уважаемый Драконограф!

В предыдущем рисунке я допустил ошибку.
Ошибка состоит в том, что параллельный процесс и команда
должеы иметь РАЗНЫЕ иконы.

Команда изображается как Вывод. (См. Как улучшить работу ума,
рис. 1, икона И14).

Ниже я исправил ошибку.


Вложения:
Комментарий к файлу: Показаны 6 параллельных процессов и 3 команды
ПараллельКоманда.png
ПараллельКоманда.png [ 65.75 КБ | Просмотров: 15815 ]
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 06 Март, 2010 23:08 

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 342
Уважаемый Владимир Даниелович!

Спасибо Вам большое за пример!

Владимир Паронджанов писал(а):
параллельный процесс и команда
должеы иметь РАЗНЫЕ иконы

Не только у Вас ;-) так.

Возникают еще вопросы:
1. A=182 т - это означает 182й такт по абсолютной шкале времени?
2. Там, где у Вас иконы с надписями "5т" и "2т" - это паузы (задержки) основного потока управления алгоритма?
3. Как осуществляется "Пуск с параметром A= 182т" и остальные такие же - в этом месте делается запрос БОС на запуск соотвествующей
служебной программы по истечении устанавливаемого временного интервала?
4. Между "первым участком" и "вторым участком" управление передается непосредственно или каким-то иным образом (через диспетчер?),
есть ли какая-то связь между участками и отдельными моментами времени?
5. Там, где используется икона с параллельными линиями в прямоугольнике - АП1... - там имеется в виду, что основной поток управления
должен дождаться завершения того запускаемого (причем только в момент 1432 т) процесса, и только потом продолжить свою работу?

Спасибо.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 292 ]  На страницу Пред.  1 ... 10, 11, 12, 13, 14, 15  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2008-2019, участники конференции «DRAKON.SU», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB