DRAKON.SU

Текущее время: Воскресенье, 01 Август, 2021 03:53

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




Начать новую тему Ответить на тему  [ Сообщений: 107 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
СообщениеДобавлено: Среда, 16 Октябрь, 2019 19:12 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Кстати, в выше упомянутом Оберон-07 return в функциях возможен только как последний оператор. И такое ограничение влияет на структуру даже элементарных алгоритмов:
Вложение:
o07ret.png
o07ret.png [ 25.04 КБ | Просмотров: 2948 ]

Обратил внимание, что Степан старается выравнивать return-ы, располагая их внизу ветки, как здесь:
https://forum.drakon.su/viewtopic.php?f=228&t=6666&sid=eb3e2a0ee06f29b71c2fd3bccdf1f6fc#p103698

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Октябрь, 2019 19:18 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
А_МУР писал(а):
Alexey_Donskoy писал(а):
- по возможности не использовать т.н. "силуэт", поскольку он рвёт маршруты (по сути он ничуть не лучше классической общей шины на электрических схемах - источника труднообнаружимых ошибок);
- если таки использовать "силуэт", то т.н. "веточные циклы" должны быть строго под запретом;

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

Силуэт по сути есть "наглядный goto". Он неизбежен (даже если его "не желать", т.е. не предполагать использовать в конкретном случае), чтобы снять пересечения линий при их возникновении.

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

Хоть "ветка" заявлена как некая замкнутая логическая структурная единица, но фактически таковой не является. Может быть в контексте "автоматного моделирования", рассматриваемого здесь на форуме, "ветка" более-менее методологически обособлена.
По этому поводу можно привести примерчик автомата из методологии от Esterel/Lustre (упрощённо):
Код:
process count(x) = o where
    automaton
        | Zero -> do o = 0 until x then Plus(1)
        | Plus(v) -> do o = v then Plus(v+1)
    end

Здесь процесс-автомат "count" со входом "x" и выходом "o" прибывает в состоянии Zero (а-ля "ветка" силуэта), возвращая 0 пока на входе не появится "x" ("x" изменит значение с неопределенного на определенное), затем возникает последовательность состояний Plus(1), Plus(2), Plus(3)...

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

В ДРАКОН-е изолировать "ветки" в общем случае невозможно (возникнут ограничения алгоритмических возможностей).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Октябрь, 2019 19:25 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Тем не менее, может возникнуть потребность в явном отображении переходов даже между "изолированными ветками" (а-ля "автоматными состояниями"), в смысле непосредственного отображения отношений (не только в виде "шины-силуэта", где "адреса" и "заголовки" необходимо дополнительно "совмещать вручную").
Обычно автоматные методики слабо уделяют внимание упорядочиванию графа. В этом случае можно обратить взгляд в сторону "графиков работ". Вместо "деревьев решений" или условий, рассматриваемых в этой теме, в тех краях имеется адаптация (ну..., иногда) к выражению иного "леса" -- сети работ, где, фактически, отсутствуют логические условия исполнения, точнее, условие лишь одно -- так называемое условное "событие" -- окончание предшествующей работы или работ.

Ниже примеры из "Ваганян Г. А., Ваганян О. Г. Виртуальные технологии менеджмента (системотехника электронного управления) - Ер., Нжар, 2005, 368 стр.". Классический или обычный график:
Вложение:
g1.png
g1.png [ 42.61 КБ | Просмотров: 2947 ]

Адаптированная форма (уточнение: по содержанию это иной график по сравнению с рисунком выше):
Вложение:
g2.png
g2.png [ 26.3 КБ | Просмотров: 2947 ]

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

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

В дополнение -- прочие возможные варианты графиков работ, с предметной упорядоченностью (вдруг кому-то полезно):
Вложение:
g3.png
g3.png [ 22.08 КБ | Просмотров: 2947 ]

Вложение:
g4.png
g4.png [ 19.73 КБ | Просмотров: 2947 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Октябрь, 2019 19:28 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Насчёт исходной задачи выше -- сети работ. В ДРАКОН-е есть средства для построения сети -- кроме последовательности (между действиями) есть и "параллельные линии". Однако могут возникать пересечения при попытках их использования. Вариации распределения совместных действий по силуэту (т.е. "разрыв" параллельных блоков для применения "веток"), когда-то здесь на форуме разбираемых, не увенчались большим успехом. Скорее, "Д-планарность" в таких случаях -- слабый помощник. Иной вариант -- определить императив в виде алгоритма с использованием "пуск" параллельного процесса, "ожиданием" условных сигналов окончания процессов (если каким-то образом подобрать "икону" для выражения событий, до сих пор отсутствующую вне рамках специализированных "паузы"/"синхронизатора" в контексте временных уставок), "стоп" для процесса. Если подобный алгоритм не является реальной исполнительной инструкцией, то такая спецификация мало полезна. Для отображения сети-результата всё равно потребуются иные средства, уже за рамками Д-методологии.
Например, кроме графиков работ, циклограмм те же "ортогональные" ("неэргономичные" и "агрессивные") Р-схемы могут "переварить" и запутанные сети процессов.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Октябрь, 2019 19:37 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Ещё по поводу сети параллельных процессов. Ранее в теме была ссылка насчёт граф/штрих-схем алгоритмов. У автора в рамках вводных статей имеются простые задачки-примеры. Воспользуемся одной из них:
Житников А.П. Параллельные алгоритмы технологических мехатронных систем.
Вложение:
A1.png
A1.png [ 97.82 КБ | Просмотров: 2945 ]

В оригинале имеются варианты задачи с разной постановкой параллелизма. Интересен случай "или"-соединения процессов:
Цитата:
Параллельная дизъюнкция алгоритмов (#V)

Допустим, существует ограничение по степени параллелизма процесса (например,
ограничение мощности гидростанции привода силовых головок в системе с мощными
режимами резания): возможна работа не более двух силовых головок одновременно –
реализуется частичный параллелизм.
[...]
Выполнение команды Z3 (ДИА-2) начинается после завершения более короткой
команды Z1, но до окончания параллельной ей команды Z2
[...]
Вводится блокировка для контроля завершения отработки циклов Z1, Z2, Z3 всех
силовых головок (СФА-5, ШСА-3):
задаются дополнительные стрелочные связи блокировки – запуск команды Z4 возмо-
жен только после отработки всех трех команд Z1, Z2, Z3 управления циклами силовых
головок.

Штрих-схема алгоритма:
Вложение:
A2.png
A2.png [ 20.25 КБ | Просмотров: 2945 ]

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

Автор определил штрих-схему выше (и постановку задачи) с некоей особенностью. То, что исполнение Z3 начинается после завершения именно Z1, известно косвенно по условиям задачи. Или из циклограммы:
Вложение:
A3.png
A3.png [ 22.21 КБ | Просмотров: 2945 ]

Тем не менее, например, Р-схема в подобном случае может быть такой:
Вложение:
rs1.png
rs1.png [ 36.36 КБ | Просмотров: 2945 ]

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

Если конвергенция на схеме только как конъюкция процессов, то можно обойтись и без спецвершин (а-ля "классический график работ"):
Вложение:
rs2.png
rs2.png [ 21.78 КБ | Просмотров: 2945 ]

В императивных схемах "развилки" есть альтернативы действий, поэтому для параллельности нужны все спецвершины ("||" -- дивергенция). Например: параллельный расчёт функции "y =Sin(x1+x2)*Cos(x1+x2)" по мотивам (от того же автора):
https://forum.drakon.su/viewtopic.php?p=93258#p93258
Вложение:
rs3.png
rs3.png [ 40.45 КБ | Просмотров: 2945 ]


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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Октябрь, 2019 19:44 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Ещё одна задачка -- в данном случае с конвейерными процессами. Её уже пытались представить здесь на форуме:
Асинхронные конвейерные алгоритмы в Фабуле

Или подробнее:
Житников А.П. Синтез асинхронного конвейерного алгоритма робототехнологического модуля
Вложение:
A4.png
A4.png [ 19.07 КБ | Просмотров: 2942 ]

Вложение:
A5.png
A5.png [ 43.56 КБ | Просмотров: 2942 ]

Вложение:
A6.png
A6.png [ 242.46 КБ | Просмотров: 2942 ]

Вложение:
A7.png
A7.png [ 38.4 КБ | Просмотров: 2942 ]


Вариация в виде структурной Р-схемы:
Вложение:
rs4.png
rs4.png [ 81.13 КБ | Просмотров: 2942 ]

Границы процесса Z2 выделены -- нет слияния начальной/конечной вершины (можно вставить и небольшой промежуток между вершинами) -- локализованы части A1, A2, A3 (фактически, разделены алгоритмы с "собственными исполнителями"). Точками на дугах отмечены лишь входные/выходные сигналы для всего процесса без конкретики (в исходной задаче они также подробно не рассмотрены). "Черными" вершинами отмечены начальные позиции процессов. Т.е., например, Z13 начинает работу после завершения Z12, Z2, Z31 (после Z13 одновременно стартуют Z14 и Z2). Однако, на первой итерации Z2 и Z31 считаются "завершёнными" (на входе процесса Z13).

Вариация Д-схемы, видимо, возможна вновь лишь как императив вида "пуск"/"ожидание сигналов завершения"/"останов".


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Октябрь, 2019 19:46 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
В блок-схемах выражение отношения следования между операциями не было представлено в полной мере (в целом в задачах управления расписанием возможны и иные отношения между процессами, но блок-схемы, прежде всего, предназначены именно для разруливания последовательности). Похоже, что планарность в ДРАКОН-е улучшает проблематику, но ограниченно.
Alexey_Donskoy писал(а):
И никто (кроме, вероятно, Лаптева с семантическим редактором) вообще не занимается сколько-нибудь серьёзно научной стороной проблемы.

Кстати, анонсирован доклад -- возможно имеются какие-то подвижки по поводу:
https://forum.drakon.su/viewtopic.php?f=211&t=6656


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 16 Октябрь, 2019 20:05 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
PSV100 писал(а):
где неявное "да" всегда вниз
Считаю, что это плохо с точки зрения когнитивной эргономики (см. далее).

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

Когнитивно эргономичным считаю правило:

Основной маршрут - вниз. Нарушение хода основного маршрута происходит по проверяемому условию

То есть подчеркну: не произвольные формулировки условий, а именно "маршрутные": "надо ли переводить стрелку?".

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Октябрь, 2019 18:36 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Кстати, насчёт формулировок вида "чем правее, тем хуже...", "отклонение от нормы...". Вероятно, в "цивилизованных" странах за такую диаграмму ниже можно схлопотать по полной из-за "гендерного неравенства" (явно выделяя "главный" маршрут):
Вложение:
dr1.png
dr1.png [ 5.3 КБ | Просмотров: 2906 ]

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

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Октябрь, 2019 18:41 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Alexey_Donskoy писал(а):
Что считать нормой в каждом конкретном случае - вопрос к проектировщику. А уж как он будет задавать вопрос для проверки условия отклонения от нормы - дело десятое.

Похоже, что дело не десятое, однако. На сегодня в IT наблюдается некая методологическая трансформация даже в Си-производных языках. А именно. Частенько в API на Си результат функций есть код ошибки. Отсюда, в основном, возникают конструкции вида "если есть ошибка, то ..." (как раз, мол, уходим вправо с основного маршрута при "да"). Т.е. результат операции -- "такая-то проблема" при его валидном значении.
Сейчас же рутинное API меняется, в т.ч. и из-за новомодных языковых фишек. И, в основном, результаты операций -- "успех". Чтобы уменьшить потребность в инверсии вида "нет успеха?" в язык добавляют новые модификации оператора "if". А также и для того, чтобы не применять явных дальнейших проверок в случае определения переменных по месту непосредственно в условных выражениях.
Например, в языках а-ля Swift вводят оператор "guard":
if let , if var, guard let,guard var and defer statements in swift
Код:
func greet(person: [String: String]) {
    guard let name = person["name"] else {
        return
    }

    print("Hello \(name)!")

    guard let location = person["location"] else {
        print("I hope the weather is nice near you.")
        return
    }

    print("I hope the weather is nice in \(location).")
}

greet(person: ["name": "John"])
// Prints "Hello John!"
// Prints "I hope the weather is nice near you."
greet(person: ["name": "Jane", "location": "Cupertino"])
// Prints "Hello Jane!"
// Prints "I hope the weather is nice in Cupertino."

Оператор "guard" по сути есть специализированная форма "if". Он не имеет явной "then"-части (она как бы "выносится" далее за оператор, уменьшая вложенность блоков) и есть обязательное else-тело, где обычно реализуется досрочный особый выход. Таким образом возникает семантическое разделение -- оператор guard отвечает как раз именно за "маршрутные" условия (за продолжение "главного шампура"). В некотором смысле так реализуются "наколенные монады" (поступательный процесс с учётом результатов предшествующего этапа/этапов). Прочие обычные if/switch занимаются мол вспомогательными условиями внутри этапа "монады".

Само название "guard" подразумевает "защитное выражение". Что соответствует традиционному понятию предикатов, и такое решение близко к популярным формальным методам рассуждений об алгоритмах. И в итоге везде идентичные принципы: у оператора "if" -- предикат в качестве операнда, редко в языках имеется вспомогательный оператор вида "unless" ("если не"), в конструкциях "pattern matching"-а у оператора вида "when" также предикат, редко встречается вспомогательная инверсия "whenot", и пр. Т.е. по умолчанию везде принцип "защитного выражения" (мол продолжаем при "да").

Соответственно логические условия возникают также как "защиты":
Код:
func validatePassword(password: String) -> Bool {
    guard password.characters.count > 3 else {
        print(“Password should contain atleast 3 characters”)
        return false
    }

    guard password.characters.count > 13 else {
        print(“Password should contain more than 13 characters”)
        return false
    }

    guard checkPasswordCharacterSet(password) else {
        print(“Password should contain one capital letter , one small letter, one special character”)
        return false
    }

    return true
}

Досрочные выходы имеют и плюсы, и минусы (отдельная смежная тематика).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Октябрь, 2019 18:43 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Alexey_Donskoy писал(а):
Общество (здешнее) эту идею принимает в штыки - наверно, потому, что лень попробовать.

Кстати, как минимум в прошлом общество ведь было на Оберон-форуме, где традиционная "структурщина", и "монады" на основе предикатов (защитных выражений) в стиле:
https://forum.oberoncore.ru/viewtopic.php?f=27&t=3175&p=57993&hilit=andif#p57990
Код:
Первый этап;
ok := первый этап удался;
IF ok THEN
  Второй этап;
  ok := второй этап удался
END;
IF ok THEN
  Действия при успехе
ELSE
  Действия при неуспехе
END

Рутинное API, в основном, имеет результат как "успех". Следовательно, принуждение к условию "есть проблема?" (чтобы уйти с главного маршрута) приводит "к нагибанию" лишний раз использовать инверсию "нет успеха?".

Инверсия себя оправдывает, например, в таких случаях -- удаление вложенности:
https://forum.oberoncore.ru/viewtopic.php?f=27&t=3175&p=57993&hilit=andif#p58010
Код:
IF A THEN
   IF B THEN
      a;
   ELSE
      b;
   END;
ELSE
   c;
END;

Трансформируется в:
Код:
IF ~A THEN
   c;
ELSIF ~B THEN
   b;
ELSE
   a;
END;


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Октябрь, 2019 18:49 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
А_МУР писал(а):
Alexey_Donskoy писал(а):
- ряд элементов (особенно громоздкий "выбор" aka "case", "switch") требует абсолютно нового дизайна;

Да, более компактную макроикону Выбора очень сильно растягивается по экрану, читаем пока есть два выбора, если больше то уже не читаемо

Вероятно, альтернатива -- это ряд "вопросов":
https://forum.drakon.su/viewtopic.php?f=62&t=6443

Однако, всё же стиль ДАЛВЯЗ-а эффективнее:
https://forum.oberoncore.ru/viewtopic.php?f=121&t=5628

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

Если у "защитника" сделать двойные боковые стороны (по аналогии со "вставкой") -- будет "ожидание события". Такой ромбик можно разместить и единственным на маршруте без бокового выхода (а-ля "пауза").

Может быть, этот же "защитник" применять и для циклов вида "for". Существующие иконы для этих циклов слабо различимы от "контрольных сроков" (которые запросто могут быть использованы в рамках одной предметки):
Вложение:
dr2.png
dr2.png [ 3.96 КБ | Просмотров: 2906 ]

И для визуального выделения требуется увеличивать эти иконы по ширине для отметки блока. Пусть для "for" будет цикл со стрелкой слева, как для силуэта (в конечной иконе-защитнике можно указать традиционно "конец для..." и т.п. в качестве "защитного выражения"):
Вложение:
dr3.png
dr3.png [ 1.86 КБ | Просмотров: 2906 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Октябрь, 2019 18:52 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Тогда освободившийся "выбор" можно интерпретировать как "данные" (традиционно для блок-схем) или пусть как "операнд". Некая методика по поводу уже была указана выше в теме -- штрих/граф-схемы:
https://forum.drakon.su/viewtopic.php?p=93258#p93228
https://forum.drakon.su/viewtopic.php?p=93258#p93258
Вложение:
dr4.png
dr4.png [ 11.8 КБ | Просмотров: 2906 ]

В простейшем случае можно указывать выходные операнды в качестве результатов функции вместо "действий" с ключевым словом "return" (последние содержательные иконы на схеме).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Октябрь, 2019 18:55 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
На форуме оживилась тема про школу Шалыто. В тех краях есть такая любопытная штуковина:
Вложение:

Вложение:
lbg.png
lbg.png [ 27.6 КБ | Просмотров: 2906 ]

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

Схемы выражаются и по-драконовски. Если ввести ограниченного "защитника" вместо "вопросов", то тогда можно задействовать "операнд" (т.е. экс-"выбор"). Если из иконы-операнд исходит единственная линия -- безусловная передача операнда, если два выхода (как в "вопросах", здесь возможны только бинарные отношения) -- с сопоставлением с указанной валентностью на дугах, где будут короткие необходимые обозначения (0,1, T, F, да, нет и пр.). И возможны операнды как "произвольные вопросы".

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

Таким образом, можно сохранить исходную Д-гибкость, "разгрузив" базовые средства для рядовой рутины.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 18 Октябрь, 2019 19:18 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
PSV100 писал(а):
а-ля оператор "select"
Фишка в том, что select/switch/case могут показывать как равноправный выбор, так и приоритетный (в т.ч. лучше/хуже).
И это даже не семантика, а метасемантика.
А в синтаксисе она, ясен пень, не отображается вообще. Может, и зря. Может, стоит показать такую разницу.

Цитата:
спецификация/правила языка всё равно вынуждают выделять некоего "главного" в случае его отсутствия
Не делайте принуждения, делов-то. :)

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 19 Октябрь, 2019 15:22 

Зарегистрирован: Пятница, 08 Декабрь, 2017 18:24
Сообщения: 421
Откуда: Астрахань-Сочи
а мне концепт "защитное выражение" нравится. как мне кажется, он может быть применим в графических алгоритмах.

причем логику его работы можно описать "Паузой" с "Временной Вставкой". У меня в ней задержка алгоритма происходит при выполнении условия.

Итак, можно Защитное Выражение определить иконкой Пауза, с логическим выражением внутри. Я уже предлогал расширенную трактовку Паузы, когда используются логические выражения. У простой, традиционно известной обычной Паузы, логика работы является частным случаем от моей расширенной.
Вложение:
Пауза5_.JPG
Пауза5_.JPG [ 18.21 КБ | Просмотров: 2884 ]


Однократно сработавшая Вставка при этом подобна Защитному обработчику. А многократно сработавшая - приобретает новое качество.
Как в электронике: есть Предохранитель, и есть Предохранитель многократного действия.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Октябрь, 2019 17:48 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Alexey_Donskoy писал(а):
Опять отпотолочная данность (немотивированное соглашение), жестоко давящее мэйнстримом.
Но мы-то как раз рассматриваем (мотивированный) уход от него, не так ли?

Видимо, ключевое в конкретике мотивации и возникающих "конфликтах интересов".

Рассмотрим плюсы/минусы методики "да вниз". На форуме была схемка на ДАЛВЯЗ:
Изображение

В данном случае есть "цикл-силуэт", который по сути является циклом вида "while...". Поскольку "да вниз", то такие циклы по-другому и не реализуешь, фактически то... Для цикла имеется особенный конечный "защитник" (икона "конец цикла-силуэта"), который должен "знать" о том, что все условия цикла валидны или нет. Структура цикла представляет собой некий локализованный блок (со спецоператорами), как для циклов вида "for" (если не ошибаюсь, в ДАЛВЯЗ единая форма для всех циклов, "обобщённый цикл"). Конструкция громоздкая, но зато именно замкнутый блок (согласно канонам "структурщины" и идентично архитектуре смежного текстового языка программирования). К примеру, досрочно "выпрыгнуть" из цикла -- только через специкону (а-ля "break").

И такой цикл весь как блок "надевается на шампур" -- мол находится на пути согласно драконовской методологии "шампур-метод", явно определяя границы.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Октябрь, 2019 17:51 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
Петли "классических" драконовских циклов более гибки, включая и вида "while ...", но более размыты в границах.

https://forum.drakon.su/viewtopic.php?f=94&t=6597
Вложение:
poisk.png
poisk.png [ 32.18 КБ | Просмотров: 2867 ]


Выше отмечена ключевая Д-фишка: в отличие от текстового формализма и while-циклов в ДАЛВЯЗ (при варианте "да всегда вниз"), а также и от Р-схем (вне специальных структурных переходов), от условий цикла можем перейти сразу к действиям или иным элементам после цикла -- мол явные связи (что, однако, имеет и плюсы, и минусы).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Октябрь, 2019 17:52 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
На форуме был любопытный рисунок:
https://forum.drakon.su/viewtopic.php?f=144&t=6256#p103289

Изображение

В самом деле, второй вариант воспринимается лучше.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 21 Октябрь, 2019 17:53 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 396
В общем, если сохранить побольше визуальной Д-гибкости, то, видимо, вариант "да всегда вправо" предпочтительнее. Что позволит, как минимум, идентично выстраивать циклы и с предусловием (а-ля "while..."), и с постусловием ("do...while").

Однако, есть проблематика в "вопросах". Во всех вариациях блок-схем, как правило, в ромбиках-условиях указывается, где да/нет. В ДАЛВЯЗ-е можно обратить внимание, что в условиях всегда имеется "пустая else-часть". Т.е. условия всегда указаны в комплексе из ромбов (хотя бы два), явно расписывая все варианты, и у последнего ромба есть "пустая" нет-линия. Тем самым подчёркивается неявно, что "да" вниз.

Видимо, желателен явный или косвенный признак направления развилок.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 107 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

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


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

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


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

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