DRAKON.SU

Текущее время: Воскресенье, 06 Декабрь, 2020 00:18

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




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: Четверг, 19 Апрель, 2012 14:13 

Зарегистрирован: Вторник, 15 Декабрь, 2009 11:43
Сообщения: 83
Как с дополнительным маршрутным оператором: значок R? в блоке "действие"
(подробнее см. в теме "AB_VJAZ и DAL_VJAZ")


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Оформление возврата из функции
СообщениеДобавлено: Четверг, 19 Апрель, 2012 14:39 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Может, имелось в виду ещё кое-что? Скажем, как визуализировать. Можно делать боковиком, как виоп 20Д здесь - а можно ещё как-то?
Кстати, return иногда нестандартно употребляется...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Оформление возврата из функции
СообщениеДобавлено: Четверг, 19 Апрель, 2012 15:05 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владислав Жаринов писал(а):
Может, имелось в виду ещё кое-что? Скажем, как визуализировать. Можно делать боковиком, как виоп 20Д здесь - а можно ещё как-то?
Кстати, return иногда нестандартно употребляется...

Я так понимаю, что return, как раз, передаёт управление на икону Конец. Это нужно как-то отображать. Желательно без пересечений. Наверно, с обрывом ...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Атомарность и оператор return
СообщениеДобавлено: Четверг, 03 Май, 2012 06:47 

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

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

Так что в гибридном техноязыке трактовка будет зависеть от производящего ТАЯ/ТЯП (т.е. от префикса языка scheme kind) существенно...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: О неатомарности return
СообщениеДобавлено: Пятница, 04 Май, 2012 06:42 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Вот, оказывается, уже было: viewtopic.php?f=82&t=2349. Как "убирать ретурны" - и одновременно в топик этой ветки. Ибо была сформулирована цель:
Илья Ермаков писал(а):
...
viewtopic.php?p=42533#p42533:
Я хочу видеть причинно-следственные связи и соотношения на данных для них, а не последовательность команд. Важнейший шаг роста программиста - перестать думать о последовательности команд и перестать гонять их в уме, имитируя процессор.

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

viewtopic.php?p=42538#p42538:
...
Вот посмотрите на это. Когда я вижу if...elsif..elsif..., я знаю, что эта конструкция обспечивает выполнение только одного своего подблока, какого - определяется первой истинной охраной. И это знаю даже не я, а мои автоматические ассоциации при чтении. Если же мы даём подблокам право на нелокальные действия, то я вообще ничего не могу сказать о свойствах общего собранного блока, без влезания в подблоки. Понимаете - НИ-ЧЕ-ГО! Какая, нафиг, абстракция, какие уровни детализации тогда остаются? Остаётся одна склёпанная заплатками портянка.
И атомарные алгоструктуры - это как раз надёжные подблоки. Конечно, при соблюдении структурности и в самих атомах - уже говорил.

А также:
Илья Ермаков в viewtopic.php?p=42554#p42554 писал(а):
...
Любой блок программы должен допускать последовательную композицию с другими блоками. И не только последовательную, но и вкладывание в объемлющие конструкции. И я не обязан изучать внутреннее устройство этого блока, если нет связей по потокам данных.

Т.е. блоки, в которых использована инструкция выхода из процедуры, являются дефектными, неполноценными, потому что не поддерживают вполне законную композицию в объемлющем блоке.

Если говорить юридически, то оказывается, что требование не использовать досрочные выходы - это не "глупая буква закона", а как раз вполне в терминах "гражданских прав", так сказать. Свобода программиста ставить EXIT-ы ограничивается в силу того, что эта свобода ограничила бы свободу других (осуществлять ЗАКОННУЮ композицию этого блока).
Технически же говоря (ну да, придираясь, но тем не менее...), это ухудшает свойства объемлющей системы в плане возможностей развития.

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

Так что ретурны можно реализовать... но надо ли?.. Тем более, что это дополнительная степень сложности при прорисовке (ибо из написанного в посте выше, думаю, ясно, что это лиана, нарушающая в общем случае топозапрет исходного ШМ на пересечения). Как он реализован в тезисах, обсуждалось здесь: viewtopic.php?p=63751#p63751. Это, кстати, и к вопросу, что будет, если разрешить пересечения... другая математика "правильности шампур-схем" потребуется, чем у Владимира Даниеловича... куда сложнее (можно было понять из нашего с Вами обсуждения ДАР-формата)...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: О неатомарности return
СообщениеДобавлено: Пятница, 04 Май, 2012 22:14 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Владислав Жаринов писал(а):
Так что ретурны можно реализовать... но надо ли?..

А что делать с уже имеющимися ретурнами при преобразовании текста программ в визуальный алгоритм?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Май, 2012 09:22 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ну, у каждого на этот счёт м.б. своё мнение. :) Моё таково. Прежде всего не забудем о реальных "головах" - компонентах МФЗ - т.е. язык, технология, реализация. Которые взаимозависимы - и под реализованное определение языка нужна в чём-то своя технология - учитывающая и особенности определения, и особенности ЖЦ описания, заданные реализацией.
Ну и есть два пути. Первый - убирать ретурны ещё в тексте. Обоснованием (практическим, заметим) сему - позиция А. Ильина: viewtopic.php?p=72528#p72528. Тогда реализация (и сохранение в определении гибридного языка для редактора) не нужны. Но нужна - как часть технологии - методика "убирания". Аналогичная "убиранию LOOPов"... Возможно, тот же Александр (или любой, владеющий алгоритмизацией гарантоспособной по существу, а не только по форме), мог бы предложить. Хотя общий принцип ясен - доказательный вывод аналогично этому примеру - но конкретика преобразований не помешает...
Такой редактор уже пригоден для "кризисных" задач, ибо не поддерживает "избыточную сложность" формализации. Но ещё и сама реализация длжнаа ведь быть корректной. А отсутствие разрешённых пересечений не требует "сложной математики" представления - а значит, и упрощает реализацию. А чем проще, как известно - тем меньше потенциальных возможностей ошибиться... :)

Второй - не убирать и потому реализовать в редакторе. Тут тоже возможен вариант, несколько упрощающий дело (при определённых условиях). А именно - если разрешить не "вообще пересечения", а только в частности - скажем для ретурн-лиан - то можно и обойтись "менее сложной" математикой как основой реализации. В данном случае мы просто тянем линии без вершин от ретурн-выходов развилок. Поэтому синтаксически всё сравнительно просто - делаем разрывы, как показано на этой схеме, допустим. Ну и вводим индексацию разрываемых рёбер, чтобы адреса контактов в разрывах назначать...
    Однако при обилии ретурнов изнутри схема загромождается разрывами (как бы их не оформлять). Сами понимаете, читать её будет сложно. Так что и эргономика графовой формы записи не спасает от неэргономичности содержания (точнее, принятой "запутанной" логики его выражения)... :)
    Кроме того, приматы обычно поодиночке не ходят - всегда стаями... :wink: Так что допустив одно исключение из атомарности - будет соблазн допускать ещё и ещё (чего там в разных ТЯП не напридумано... :)). А тогда "частная сложность" математики работать уже не будет... и будет "клёпаный" редактор... :| В смысле, описанном здесь (при обсуждении первого типа мышления сочинителя).
Кстати, об исключениях. Вот это в ту же тему:
Александр Шостак в viewtopic.php?p=45023#p45023 писал(а):
Евгений Темиргалеев писал(а):
Berserker писал(а):
Лучше больше времени потратить на создание кода, чем отладку или доработку в будущем. Вполне возможно, что если взять за правило структурный стиль , то через какое-то время это войдёт в привычку.
Попробуйте. Если взять соответствующий язык, который не даст расслабляться, то 100% через некоторое время Вы обнаружите, что так и есть.

...
Также стала абсолютно дикой концепция использования исключений для обработки ошибок (в Делфи это сплошь и рядом). Подобные неявные goto рушат основу структурного стиля, заставляя шарахаться от каждого вызова метода или функции. Считаю необходимым применение исключений только там, где это действительно нужно - в математических операциях (TRY a+b EXCEPT MathError END).
Т.е. исключения нужны, хотя и в максимально ограниченном числе случаев. И это тоже механизм передачи управления неатомарный. И если к нему добавить ещё хотя бы те же ретурны - уже "избыточная сложность" получится...
Более систематически об исключениях см. Гл. 8 у Кауфмана. Вот с ними нечто надо делать (в смысле представления связей на совокупности схем)...

Впрочем, есть и третий путь. Он не про нас с Вами, конечно... :) но раз уж строим базис решений - полезно упомянуть. Но не здесь а в более подходящей ветке: viewtopic.php?p=72555#p72555.

Так что не пойдём мы этим путём, наверное... как думаете?..


Последний раз редактировалось Владислав Жаринов Суббота, 05 Май, 2012 10:41, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Май, 2012 10:06 

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 28
Откуда: Ленинград, Емельянов Алексей Николаевич
>> to Жаринов
По поводу ретонов, лупов и прочее. Здесь я согласен с Тышовым. Мне кажется товарищи вы занимаетесь имитацией деятельности. Сколько можно жевать эту жвачку. Не надо быть святее папы римского. Ну есть в Делфи goto, и чего, кажется пару раз (за все время) я даже использовал, так ради интереса.
То что Ильин убирал loop ы, так это он занимался оптимизацией, а его нелюбовь к лупам чистый субъективизм.
Я еще могу понять преподавателей, им надо прививать "классическую" технику, а тут-то чего.

По поводу Лысенко, я с Вами принципиально и категорически не согласен (т.е. все с точностью до наоборот), и считаю что Вы не должны провоцировать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 05 Май, 2012 10:53 

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

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

Другое дело - Ваше замечание насчёт помещения сюда "третьего пути". Действительно, он очень общий - поэтому вряд ли ему место в теме конкретной - соглашусь с Вами. Потому перенёс в другую ветку: viewtopic.php?p=72555#p72555. Там же некоторые соображения по другим Вашим замечаниям.

В то же время "по месту требования" одно всё-таки отмечу. Что провоцируют, думаю, как раз те, кто этому пути следуют. А не те, кто указывает на его существование... А смысл данного поста был - что БП, дающие неустранимые пересечения на схеме, вряд ли стоит сразу реализовывать в редакторе схем. И также - что не стоит затевать споры, не основанные на фактах и научном методе. Потому, что предвидел - кроме замечаний, подобных Вашим - где-то эмоциональных, но по сути верных - начнётся ведь и "пережёвывание жвачки" типа: "А правда ли, что ретурн или исключение есть БП?" или "А почему это здесь будут пересечения?"... :wink: Кстати, Вы удачно напомнили, что редактор д.б. и инструментом "постановки классической техники" в обучении - вот и ещё резон, чтобы иметь "атомарный" вариант реализации, где произвольные БП типа ретурна будут отсутствовать...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об определении лианы
СообщениеДобавлено: Вторник, 21 Август, 2012 15:42 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4966
Откуда: Москва
Владислав Жаринов писал(а):
Уважаемый Владимир Даниелович!
Всё собираюсь спросить - на практике при визуализации понятий шампур-метода я определяю лиану как цепочку от побочного выхода развилки (варианта переключателя) до первой встреченной вершины-соединителя (что можно видеть, скажем, на схемах здесь или здесь). Т.е. из понятия лианы исключается главная вертикаль примитива (ветки силуэта) - что должно соответствовать смыслу операций с лианой. Вместе с тем в Вашем текстовом определении говорится о любом выходе ветвления как о начале лианы. Тогда получается, что формально мы можем пересадить/заземлить и главную вертикаль... а куда? :)

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

Ваше сообщение содержит ошибочные утверждения.

Владислав Жаринов писал(а):
я определяю лиану как цепочку от побочного выхода развилки (варианта переключателя) до первой встреченной вершины-соединителя
Вы даете НЕУДАЧНОЕ определение лианы, которое ведет к противоречию
Почему только от побочного? Это не верно.

Владислав Жаринов писал(а):
... из понятия лианы исключается главная вертикаль примитива (ветки силуэта)
Возражаю. Из понятия лианы НЕЛЬЗЯ исключать главную вертикаль. Зачем ее исключать? Исключать лиану, находящуюся на главной вертикали, НЕ СЛЕДУЕТ. Этот путь ведет в тупик.

Владислав Жаринов писал(а):
в Вашем текстовом определении говорится о любом выходе ветвления как о начале лианы.
Да, это верно. Так и должно быть. Любой выход ветвления может быть началом лианы.

Владислав, Вы предположили, что не любой выход ветвления, а только побочный.
Это и есть ГЛАВНАЯ ОШИБКА, из которой вытекают все остальные.

Вы спрашиваете:
Цитата:
Тогда получается, что формально мы можем пересадить ... и главную вертикаль... а куда?
Ответ простой и он давно опубликован. Ответ на вопрос: куда? дан на рис. 129 книги " Как улучшить работу ума".
На рис. 180 книги "Дружелюбные алгоритмы, понятные каждому".
На рис. 249 книги " Учись писать, читать и понимать алгорритмы".
Во всех книгах изображен один и тот же рисунок.

Даю точную цитату:
Цитата:
§8. ПЕРЕСАДКА ЛИАНЫ

Тезис 28. Пересадка лианы – преобразование дракон-схемы, выполняе-
мое за четыре шага.

Шаг 1. Производится отрыв конца лианы от точки присоединения
(рис. 236, 237).

Шаг 2. Конец лианы с помощью вертикальных и горизонтальных ли-
ний присоединяется к любой валентной точке, куда лиана может
дотянуться без пересечения с другими линиями (рис. 236, 237).

При этом запрещается:

• формировать второй вход в ветку (ошибка «сиамские близне-
цы» – см. рис. 247);

• образовывать новый цикл;

• создавать второй вход в цикл.

Однако разрешается строить новый путь из середины обычного цикла
к единственному входу в этот цикл, создавая визуальный эквивалент опе-
ратора continue языка Си (см. рис. 167, пример 7, а также рис. 83).


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

ВОПРОС. КУДА МОЖНО ПЕРЕСАДИТЬ ЛИАНУ,
НАЧАЛО КОТОРОЙ ПРИСОЕДИНЕНО НЕ К ПОБОЧНОМУ ВЫХОДУ РАЗВИЛКИ,
А К ЛЕВОМУ?


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

 формировать второй вход в ветку (ошибка “сиамские близнецы” — см. рис. 127);

 образовывать новый цикл;

 создавать второй вход в цикл.

Однако разрешается строить новый путь из середины обычного цикла к единственному входу в этот цикл, создавая визуальный эквивалент оператора continue языка СИ (см. рис. 90, пример 7, а также рис. 41).
Я написал начало которой присоединено к левому выходу развилки красным цветом специально для вас, чтобы обратить ваше внимание и разъяснить вашу ошибку.

На самом деле, фраза начало которой присоединено к левому выходу развилки в определении пересадки лианы НЕ НУЖНА.

ВЫВОДЫ

1. Таким образом, в моих определениях и примерах никаких ошибок нет.

2. На заданные Вами вопросы я дал ответ, полностью согласованный с текстом моих книг.

3. Высказанные Вами сомнения являются результатом путаницы в ваших определениях и рассуждениях и не требуют пересмотра текста указанных книг.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Об определении лианы
СообщениеДобавлено: Среда, 22 Август, 2012 10:29 

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

Вы спрашиваете:
Цитата:
Тогда получается, что формально мы можем пересадить ... и главную вертикаль... а куда?
Ответ на вопрос: куда? дан на рис. 129 книги " Как улучшить работу ума".
На рис. 180 книги "Дружелюбные алгоритмы, понятные каждому".
На рис. 249 книги " Учись писать, читать и понимать алгорритмы".
Во всех книгах изображен один и тот же рисунок.
...
Да, определение нужно расширить. При этом имея в виду, что разновидность лианы от главного выхода развилки (разветвителя маршрутов) м.б. пересажена только вперёд по той же вертикали (назад нельзя - образование цикла), а на неглавной оси порядка тела - также ещё и влево (на главной слева уже ничего нет по определению порядка). Ну и (продолжу изложение, прерванное недоступностью форума :wink:) лиана-вертикаль на любой оси (где она существует - т.е. кроме самого низшего порядка, на котором м.б. уже только побочные лианы, определённые сейчас) м.б. пересажена вправо - в пределах контура, ограниченного её развилкой и её соединителем (от которого отрываем). Т.е. на побочную вертикаль от той же развилки.

Кстати, линия с ретурнами имеет практическое продолжение... которое, очевидно, имеет обоснование в теории структурного программирования. Интересно, скажет ли что-нибудь Иван по этому вопросу...

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


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

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


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

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


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

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