DRAKON.SU https://forum.drakon.su/ |
|
Нужны ли неатомарные алгоструктуры? https://forum.drakon.su/viewtopic.php?f=78&t=2919 |
Страница 2 из 2 |
Автор: | Дмитрий_ВБ [ Четверг, 19 Апрель, 2012 14:13 ] |
Заголовок сообщения: | Re: Нужны ли неатомарные алгоструктуры? |
Как с дополнительным маршрутным оператором: значок R? в блоке "действие" (подробнее см. в теме "AB_VJAZ и DAL_VJAZ") |
Автор: | Владислав Жаринов [ Четверг, 19 Апрель, 2012 14:39 ] |
Заголовок сообщения: | Оформление возврата из функции |
Может, имелось в виду ещё кое-что? Скажем, как визуализировать. Можно делать боковиком, как виоп 20Д здесь - а можно ещё как-то? Кстати, return иногда нестандартно употребляется... |
Автор: | Ильченко Эдуард [ Четверг, 19 Апрель, 2012 15:05 ] |
Заголовок сообщения: | Re: Оформление возврата из функции |
Владислав Жаринов писал(а): Может, имелось в виду ещё кое-что? Скажем, как визуализировать. Можно делать боковиком, как виоп 20Д здесь - а можно ещё как-то? Кстати, return иногда нестандартно употребляется... Я так понимаю, что return, как раз, передаёт управление на икону Конец. Это нужно как-то отображать. Желательно без пересечений. Наверно, с обрывом ... |
Автор: | Владислав Жаринов [ Четверг, 03 Май, 2012 06:47 ] |
Заголовок сообщения: | Атомарность и оператор return |
Да, в Фортране так... Т.е. ретурн там - это БП-брейк из функции... Можно считать, что задаёт лиану, "сразу пересаженную" на её конец. Точнее - участок лианы от вершины, представляющей предшественника ретурна, до соединителя (перед вершиной Конец). Если встречается в некрайнем правом маршруте ветвления - то шампур-визуализация ведёт к пересечению (с более правыми маршрутами/"подвалом" ветвления - смотря как ретурн-участок тянуть). Если в цикле поставить - то вообще круто - как бы досрочный выход (брейк), но не на КЦ, а на КФ - т.е. дальше по шампуру. В частном случае, когда между КЦ и КФ нет ничего исполняемого, эквивалентен по эффекту передачи управления брейку. Ну, всё равно лиана пересаженная (и дающая пересечения при тех же условиях). Однако в ряде других алго/прогязыков ретурна или нет, или он имеет смысл директивы объявления конкретной переменной из употребляемых в функции как её результата. А в других языках вместо ретурна используется либо другое директивное слово (так, в Eiffel - Result), либо оператор присваивания результата переменной с именем, совпадающим с именем самой функции (так в ТП). Под это как раз запись боковиком сделана... Так что в гибридном техноязыке трактовка будет зависеть от производящего ТАЯ/ТЯП (т.е. от префикса языка scheme kind) существенно... |
Автор: | Владислав Жаринов [ Пятница, 04 Май, 2012 06:42 ] |
Заголовок сообщения: | О неатомарности return |
Вот, оказывается, уже было: 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. Это, кстати, и к вопросу, что будет, если разрешить пересечения... другая математика "правильности шампур-схем" потребуется, чем у Владимира Даниеловича... куда сложнее (можно было понять из нашего с Вами обсуждения ДАР-формата)... |
Автор: | Ильченко Эдуард [ Пятница, 04 Май, 2012 22:14 ] |
Заголовок сообщения: | Re: О неатомарности return |
Владислав Жаринов писал(а): Так что ретурны можно реализовать... но надо ли?.. А что делать с уже имеющимися ретурнами при преобразовании текста программ в визуальный алгоритм? |
Автор: | Владислав Жаринов [ Суббота, 05 Май, 2012 09:22 ] |
Заголовок сообщения: | Re: Нужны ли неатомарные алгоструктуры? |
Ну, у каждого на этот счёт м.б. своё мнение. Моё таково. Прежде всего не забудем о реальных "головах" - компонентах МФЗ - т.е. язык, технология, реализация. Которые взаимозависимы - и под реализованное определение языка нужна в чём-то своя технология - учитывающая и особенности определения, и особенности ЖЦ описания, заданные реализацией. Ну и есть два пути. Первый - убирать ретурны ещё в тексте. Обоснованием (практическим, заметим) сему - позиция А. Ильина: viewtopic.php?p=72528#p72528. Тогда реализация (и сохранение в определении гибридного языка для редактора) не нужны. Но нужна - как часть технологии - методика "убирания". Аналогичная "убиранию LOOPов"... Возможно, тот же Александр (или любой, владеющий алгоритмизацией гарантоспособной по существу, а не только по форме), мог бы предложить. Хотя общий принцип ясен - доказательный вывод аналогично этому примеру - но конкретика преобразований не помешает... Такой редактор уже пригоден для "кризисных" задач, ибо не поддерживает "избыточную сложность" формализации. Но ещё и сама реализация длжнаа ведь быть корректной. А отсутствие разрешённых пересечений не требует "сложной математики" представления - а значит, и упрощает реализацию. А чем проще, как известно - тем меньше потенциальных возможностей ошибиться... Второй - не убирать и потому реализовать в редакторе. Тут тоже возможен вариант, несколько упрощающий дело (при определённых условиях). А именно - если разрешить не "вообще пересечения", а только в частности - скажем для ретурн-лиан - то можно и обойтись "менее сложной" математикой как основой реализации. В данном случае мы просто тянем линии без вершин от ретурн-выходов развилок. Поэтому синтаксически всё сравнительно просто - делаем разрывы, как показано на этой схеме, допустим. Ну и вводим индексацию разрываемых рёбер, чтобы адреса контактов в разрывах назначать...
Кроме того, приматы обычно поодиночке не ходят - всегда стаями... Так что допустив одно исключение из атомарности - будет соблазн допускать ещё и ещё (чего там в разных ТЯП не напридумано... ). А тогда "частная сложность" математики работать уже не будет... и будет "клёпаный" редактор... В смысле, описанном здесь (при обсуждении первого типа мышления сочинителя). Александр Шостак в viewtopic.php?p=45023#p45023 писал(а): Евгений Темиргалеев писал(а): Berserker писал(а): Лучше больше времени потратить на создание кода, чем отладку или доработку в будущем. Вполне возможно, что если взять за правило структурный стиль , то через какое-то время это войдёт в привычку. Попробуйте. Если взять соответствующий язык, который не даст расслабляться, то 100% через некоторое время Вы обнаружите, что так и есть.... Также стала абсолютно дикой концепция использования исключений для обработки ошибок (в Делфи это сплошь и рядом). Подобные неявные goto рушат основу структурного стиля, заставляя шарахаться от каждого вызова метода или функции. Считаю необходимым применение исключений только там, где это действительно нужно - в математических операциях (TRY a+b EXCEPT MathError END). Более систематически об исключениях см. Гл. 8 у Кауфмана. Вот с ними нечто надо делать (в смысле представления связей на совокупности схем)... Впрочем, есть и третий путь. Он не про нас с Вами, конечно... но раз уж строим базис решений - полезно упомянуть. Но не здесь а в более подходящей ветке: viewtopic.php?p=72555#p72555. Так что не пойдём мы этим путём, наверное... как думаете?.. |
Автор: | Axcel [ Суббота, 05 Май, 2012 10:06 ] |
Заголовок сообщения: | Re: Нужны ли неатомарные алгоструктуры? |
>> to Жаринов По поводу ретонов, лупов и прочее. Здесь я согласен с Тышовым. Мне кажется товарищи вы занимаетесь имитацией деятельности. Сколько можно жевать эту жвачку. Не надо быть святее папы римского. Ну есть в Делфи goto, и чего, кажется пару раз (за все время) я даже использовал, так ради интереса. То что Ильин убирал loop ы, так это он занимался оптимизацией, а его нелюбовь к лупам чистый субъективизм. Я еще могу понять преподавателей, им надо прививать "классическую" технику, а тут-то чего. По поводу Лысенко, я с Вами принципиально и категорически не согласен (т.е. все с точностью до наоборот), и считаю что Вы не должны провоцировать. |
Автор: | Владислав Жаринов [ Суббота, 05 Май, 2012 10:53 ] |
Заголовок сообщения: | О некоторых замечаниях по неатомарности |
Дык штука в том, что согласен я с Вами... Не надо вообще все явные БП запрещать. Об этом и TAU говорил. Те, которые Паронджанов ввёл в силуэте - удачно представляют определённый тип маршрутных структур (с явным выделением состояний) - это и Ермаков показывал, и у меня есть тому примеры. И они могут и должны использоваться - в автоматных спецификациях и в программировании напрямую машин с джампом-то уж точно... Но здесь-то обсуждались БП совсем другие. И насчёт того, нужно ли гнаться за их немедленной реализацией - есть у меня серьёзные сомнения... Которые и высказал. А уж дело Эдуарда или кого другого решать - как действовать. Заметим, что и некоторые соображения даже для сомнительнго случая дал - ибо всегда ставлю общее дело прежде личной точки зрения... Про лупы и субъективизм, кстати, тоже ничего не могу возразить - ибо в этом посте вообще не призывал от них отказываться (а равно и не агитировал за них)... Привёл эту ветку просто как пример - насколько проработан д.б. вопрос с убиранием ретурнов, чтобы предлагать от них отказываться. Если идти однозначно по первому пути... Другое дело - Ваше замечание насчёт помещения сюда "третьего пути". Действительно, он очень общий - поэтому вряд ли ему место в теме конкретной - соглашусь с Вами. Потому перенёс в другую ветку: viewtopic.php?p=72555#p72555. Там же некоторые соображения по другим Вашим замечаниям. В то же время "по месту требования" одно всё-таки отмечу. Что провоцируют, думаю, как раз те, кто этому пути следуют. А не те, кто указывает на его существование... А смысл данного поста был - что БП, дающие неустранимые пересечения на схеме, вряд ли стоит сразу реализовывать в редакторе схем. И также - что не стоит затевать споры, не основанные на фактах и научном методе. Потому, что предвидел - кроме замечаний, подобных Вашим - где-то эмоциональных, но по сути верных - начнётся ведь и "пережёвывание жвачки" типа: "А правда ли, что ретурн или исключение есть БП?" или "А почему это здесь будут пересечения?"... Кстати, Вы удачно напомнили, что редактор д.б. и инструментом "постановки классической техники" в обучении - вот и ещё резон, чтобы иметь "атомарный" вариант реализации, где произвольные БП типа ретурна будут отсутствовать... |
Автор: | Владимир Паронджанов [ Вторник, 21 Август, 2012 15:42 ] |
Заголовок сообщения: | Re: Об определении лианы |
Владислав Жаринов писал(а): Уважаемый Владимир Даниелович! Всё собираюсь спросить - на практике при визуализации понятий шампур-метода я определяю лиану как цепочку от побочного выхода развилки (варианта переключателя) до первой встреченной вершины-соединителя (что можно видеть, скажем, на схемах здесь или здесь). Т.е. из понятия лианы исключается главная вертикаль примитива (ветки силуэта) - что должно соответствовать смыслу операций с лианой. Вместе с тем в Вашем текстовом определении говорится о любом выходе ветвления как о начале лианы. Тогда получается, что формально мы можем пересадить/заземлить и главную вертикаль... а куда? Уважаемый Владислав! Ваше сообщение содержит ошибочные утверждения. Владислав Жаринов писал(а): я определяю лиану как цепочку от побочного выхода развилки (варианта переключателя) до первой встреченной вершины-соединителя Вы даете НЕУДАЧНОЕ определение лианы, которое ведет к противоречию Почему только от побочного? Это не верно. Владислав Жаринов писал(а): ... из понятия лианы исключается главная вертикаль примитива (ветки силуэта) Возражаю. Из понятия лианы НЕЛЬЗЯ исключать главную вертикаль. Зачем ее исключать? Исключать лиану, находящуюся на главной вертикали, НЕ СЛЕДУЕТ. Этот путь ведет в тупик.Владислав Жаринов писал(а): в Вашем текстовом определении говорится о любом выходе ветвления как о начале лианы. Да, это верно. Так и должно быть. Любой выход ветвления может быть началом лианы. Владислав, Вы предположили, что не любой выход ветвления, а только побочный. Это и есть ГЛАВНАЯ ОШИБКА, из которой вытекают все остальные. Вы спрашиваете: Цитата: Тогда получается, что формально мы можем пересадить ... и главную вертикаль... а куда? Ответ простой и он давно опубликован. Ответ на вопрос: куда? дан на рис. 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. Высказанные Вами сомнения являются результатом путаницы в ваших определениях и рассуждениях и не требуют пересмотра текста указанных книг. |
Автор: | Владислав Жаринов [ Среда, 22 Август, 2012 10:29 ] |
Заголовок сообщения: | Re: Об определении лианы |
Владимир Паронджанов писал(а): ... Да, определение нужно расширить. При этом имея в виду, что разновидность лианы от главного выхода развилки (разветвителя маршрутов) м.б. пересажена только вперёд по той же вертикали (назад нельзя - образование цикла), а на неглавной оси порядка тела - также ещё и влево (на главной слева уже ничего нет по определению порядка). Ну и (продолжу изложение, прерванное недоступностью форума ) лиана-вертикаль на любой оси (где она существует - т.е. кроме самого низшего порядка, на котором м.б. уже только побочные лианы, определённые сейчас) м.б. пересажена вправо - в пределах контура, ограниченного её развилкой и её соединителем (от которого отрываем). Т.е. на побочную вертикаль от той же развилки.Владислав Жаринов писал(а): ... из понятия лианы исключается главная вертикаль примитива (ветки силуэта) Возражаю. Из понятия лианы НЕЛЬЗЯ исключать главную вертикаль. Зачем ее исключать? Исключать лиану, находящуюся на главной вертикали, НЕ СЛЕДУЕТ. Этот путь ведет в тупик.Вы спрашиваете: Цитата: Тогда получается, что формально мы можем пересадить ... и главную вертикаль... а куда? Ответ на вопрос: куда? дан на рис. 129 книги " Как улучшить работу ума".На рис. 180 книги "Дружелюбные алгоритмы, понятные каждому". На рис. 249 книги " Учись писать, читать и понимать алгорритмы". Во всех книгах изображен один и тот же рисунок. ... Кстати, линия с ретурнами имеет практическое продолжение... которое, очевидно, имеет обоснование в теории структурного программирования. Интересно, скажет ли что-нибудь Иван по этому вопросу... P.S. Пока, очевидно, высказываться нет желания... впрочем, на эту тему уже было где-то... |
Страница 2 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |