DRAKON.SU

Текущее время: Вторник, 19 Февраль, 2019 22:01

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




Начать новую тему Ответить на тему  [ Сообщений: 249 ]  На страницу Пред.  1 ... 7, 8, 9, 10, 11, 12, 13  След.
Автор Сообщение
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 14:09 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4011
Откуда: Москва
Спасибо. Меня это интересует вот почему. Привожу цитату из Википедии статья ДРАКОН:

Цитата:
Гибридные языки ДРАКОН-семейства и оператор GOTO

Чтобы глубже понять роль оператора GOTO, можно выделить два этапа в истории развития языков программирования.

На первом этапе — после изобретения структурного программирования и призыва Эдсгера Дейкстры: «оператор go to должен быть отменен в языках программирования высокого уровня»[28] — начался процесс исключения GOTO из вновь создаваемых языков. Сегодня имеется целый ряд языков без GOTO: Java, Python, Tcl, Модула-2, Оберон и др.

На втором этапе появился язык ДРАКОН, в котором исключен не только GOTO, но и все остальные текстовые управляющие операторы. Начался постепенный переход к гибридным языкам с целью дальнейшего повышения производительности труда.

При этом открылись два обстоятельства. Транслятор из ДРАКОНа в целевой язык лучше всего делать с использованием GOTO, имеющемся в целевом языке. Если же оператор GOTO в целевом языке отсутствует, этот оператор приходится эмулировать.[29]

Подобная эмуляция оператора GOTO вносит мелкие неоправданные сложности. Эти сложности сразу исчезают, если в целевом языке есть оператор GOTO. Следовательно, с точки зрения языка ДРАКОН, было бы лучше, если бы в целевом языке был предусмотрен оператор GOTO.

Цитата:
Оператор GOTO нежелательно использовать именно в текстовых языках, так как контроль за соблюдением структурности программы остается за исполнителем (программистом). В языке ДРАКОН есть свои собственные правила, позволяющие сохранять структурность.[30]


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

При описанных условиях ввод оператора GOTO не представляет никакой опасности. Он не приведет к нарушению структурности и появлению «спагетти», так как GOTO будет вводиться в текст целевого языка только автоматически в результате работы транслятора, а не в результате действий человека. Человек будет иметь доступ только к дракон-схеме.

В свою очередь, дракон-схема имеет надежную защиту от подобных неприятностей благодаря использованию ДВУМЕРНОГО структурного программирования. Принципы двумерного структурного программирования подробно описаны в литературе.[31][32][4]


Таким образом, возникает проблема "попятного движения". Сначала (под влиянием рекомендаций Э. Дейкстры) исключаем goto из языка. Но потом (после дополнительного тщательного размышления) разворачиваемся на 180 градусов и снова вводим в язык оператор goto.

Вопрос: Lua — это единственный язык, в котором наблюдается эффект попятного движения.
Или есть другие примеры?
Кто знает, подскажите, please...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 15:00 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 998
Откуда: Россия, Чебоксары
Владимир Паронджанов писал(а):
В свою очередь, дракон-схема имеет надежную защиту от подобных неприятностей благодаря использованию ДВУМЕРНОГО структурного программирования.
В свою очередь, повторю, что:
- структурность по сути означает ориентированность графа, состоящего из целостных блоков, интерфейс каждого из которых сводится к одному входу и одному выходу;
- "структурное программирование" само по себе не может иметь конкретную размерность (в т.ч. двумерную);
- вводимый Вами "силуэт", также, как и goto, нарушает принцип структурности;
- "силуэт" отнюдь не делает алгоритм двумерным, а просто нарезает его на слабо связанные части;
- для сохранения структурности "силуэт" требует дополнительных, до сих пор не формализованных правил соединения этих частей;
- введение "силуэта" может быть эргономически оправдано только в отдельных частных случаях (типах алгоритмов).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 16:36 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 237
Владимир Паронджанов писал(а):
...
Таким образом, возникает проблема "попятного движения". Сначала (под влиянием рекомендаций Э. Дейкстры) исключаем goto из языка. Но потом (после дополнительного тщательного размышления) разворачиваемся на 180 градусов и снова вводим в язык оператор goto.

Вопрос: Lua — это единственный язык, в котором наблюдается эффект попятного движения.
Или есть другие примеры?
Кто знает, подскажите, please...


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 18:16 

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

Я с Вами полностью согласен. За исключением одного небольшого пункта.

PSV100 писал(а):
... всё развивается под требованиями практики.
Согласен.

PSV100 писал(а):
Из языков, где goto есть, его исключить невозможно.
Согласен.

PSV100 писал(а):
Более того, там, где использование соответствующего инструмента оправдано, этот goto-механизм даже развивают.
Согласен

PSV100 писал(а):
И когда идёт борьба против каждого лишнего тика процессора, то вся структурность и прочее идёт лесом.
Согласен.

PSV100 писал(а):
... например, в относительно новом Go от рождения goto имеется, но тоже с ограничениями для структурности.
Согласен

PSV100 писал(а):
Беспорядочно goto никто не использует (среди вменяемых, конечно), когда целесообразно - в принципе, в вики написано.
Согласен
____________________

PSV100 писал(а):
Да нет никакого "попятного движения"
А вот тут согласиться не могу.
Под попятным движением я понимаю ситуацию, когда в языке СНАЧАЛА исключают goto, а ПОТОМ вводят.

В языке Lua именно так и произошло.

На первом этапе (до 2011 года) разработчики языка Lua приняли решение (по-видимому, под влиянием рекомендаций Э. Дейкстры) исключить goto из языка.

А на втором этапе (начиная с декабря 2011 года) подвлиянием требований практики они пришли к выводу о необходимости пересмотреть ранее принятое решение (то есть развернулись на 180 градусов) и ввели в язык Lua оператор goto. Да. разумеется, они ввели его с разумными ограничениями.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 21:26 

Зарегистрирован: Понедельник, 09 Август, 2010 22:28
Сообщения: 128
Alexey_Donskoy писал(а):
"силуэт" отнюдь не делает алгоритм двумерным, а просто нарезает его на слабо связанные части;

Силуэт изоморфен добавлению множества вставок. Просто они раскрываются на этой же схеме.

Alexey_Donskoy писал(а):
"структурное программирование" само по себе не может иметь конкретную размерность


Да, размерность имеет только схема алгоритма, представленная в виде графа. Я тоже сторонник соблюдения правильной терминологии.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Вторник, 11 Сентябрь, 2012 23:00 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 998
Откуда: Россия, Чебоксары
usr345 писал(а):
Силуэт изоморфен добавлению множества вставок. Просто они раскрываются на этой же схеме.
К сожалению, не изоморфен, потому что там есть переходы, которые нарушают структурность.
Другими словами, (а) любой структурный орграф можно превратить в "силуэт", но (б) обратное неверно.
Чтобы сохранить структурность при обратном преобразовании, нужны дополнительные условия (запрет "веточных циклов", например).
Справедливости ради скажу, что доказательством теоремы (б) я не занимался, утверждать на 100%, что она верна, - не могу. :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 05:37 

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

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

Мерность - это да... причём ведь надо учесть ещё различие между мерностью физики и логики представления (в очередной раз говорилось здесь: viewtopic.php?p=74179#p74179)...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 06:01 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
PSV100 в viewtopic.php?p=74586#p74586 писал(а):
...
Кстати, на практике такие механизмы "кондукторов" и "редукторов" крайне проблематичная штуковина выходит, некая универсальность, пусть и мощная, но, всё-таки, ограниченная. И если "кубик" легко и быстро "не перепрограммируется" под конкретные потребности, то его эксплуатация возможна только через методы "ERP-впаривания" (описанные в пред. посте), что является, фактически, болезнью многих крупных ERP-систем (да и не только).


Спасибо за разъяснения. Темы форумов насчёт Усова я пока смог посмотреть лишь поверхностно да по диагонали, как и демонстрацию "КУБа". Как я понимаю, ключевая идея "системного подхода" в том, что любой процесс в оргсистеме можно представить как техпроцесс, в т.ч. и любой из "нетехпроцессов", по единым правилам и законам (т.е. пока оставить в стороне сами размышления на тему что такое "система", её свойства и функции, цели т.д.). Если сжато сказать, то всю оргсистему можно задать как систему графа ТП и графа ПМ, сопоставив их, включая и компоновку РМ в рамках ПМ. Вроде, так и происходит в реальной жизни. Отличие только во взглядах, с какой стороны посмотреть, и, прежде всего, даже с какой высоты. ...
Думаю, всё верно. Только уточнил бы - достижение любого мыслимого результата в таком подходе определяется как техпроцесс.
В систему при этом также входят описания предметов и результатов труда (тех же входных и выходных данных в их организации по экранным/печатным формам). По сути, КД на сырьё/полуфабрикаты/готовую продукцию...
Среда поддержки не "пере-" а скорее "допрограммироваться" должна. Для чего мы с каждой техоперацией всегда связываем определение процесса её исполнения на текущих ПМ. При "лоскутной" автоматизации это часто и бывают макросы и скрипты... включаем их практические представления (скажем, в виде шаблона целевого приложения) в атрибуты ТО в среде - и активируем, когда надо (или вручную извлекаем/подключаем/обрабатываем). Т.е. это часть ЕСТД-шной доки, можно сказать...

И сложившаяся ситуация, конечно, отражается - но только через перепроектирование РМ/ТП/КД. Как в проектном производстве плановом - так и в порядке рационализации (просто другой случай).

Как можно видеть, ваше определение тут нужно уточнить - проектное производство не вспомогательное, а просто с другим предметом. Созданием/совершенствованием проекта системы - как продукта и/или как средства получения этого продукта. И конечно, там есть и своё планирование... и сопровождение предмета... всё как было рассмотрено... И его техпроцессы тоже исполняются на своих ПМ - как в той же оргсистеме (силами специалистов и рационализаторов), так и внешними (типа "Оргэнергогаза" в "Газпроме", разных "<отрасль>[завод]проект[строй]")...
Есть и своя специфика - но это опять же к Александру Сергеевичу... пока только в личку...

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 06:20 

Зарегистрирован: Вторник, 20 Ноябрь, 2007 10:45
Сообщения: 31
usr345 писал(а):
Alexey_Donskoy писал(а):
"силуэт" отнюдь не делает алгоритм двумерным, а просто нарезает его на слабо связанные части;

Силуэт изоморфен добавлению множества вставок. Просто они раскрываются на этой же схеме.
Если под вставкой понимать вызов функции, то неизоморфен. Икона "Адрес" ветки силуэта это как раз безусловный или автоматный переход, а выход из вставки это возврат в точку следующую за иконой "Вставка" (т.е. через стек в ЯВУ). Была бы, например, в Драконе наряду с иконой "Адрес" икона "Возврат" (могла бы изображаться также как "Адрес" только без соединения с контуром силуэта"), то тогда да - силуэт был бы изоморфен шампур-схеме со вставками.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 07:13 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Да есть уже... как линейное (по сути - абстрактно-машинное) расширение синтаксиса... :)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 12:13 

Зарегистрирован: Понедельник, 09 Август, 2010 22:28
Сообщения: 128
Alexey_Donskoy писал(а):
- структурность по сути означает ориентированность графа, состоящего из целостных блоков, интерфейс каждого из которых сводится к одному входу и одному выходу;
- "силуэт" отнюдь не делает алгоритм двумерным, а просто нарезает его на слабо связанные части;
- для сохранения структурности "силуэт" требует дополнительных, до сих пор не формализованных правил соединения этих частей;

То есть вот такого быть не должно:


Вложения:
0Рис. Колдунья png.png
0Рис. Колдунья png.png [ 370.54 КБ | Просмотров: 7314 ]
Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 12:26 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Вроде как, если применить правила отсюда: viewtopic.php?p=70770#p70770 - то здесь обнаружится пересечение петель циклов... собственно, "примитивизировать" в данном случае проще...
Если это гибридный язык с Фортран 66 - то вроде как не нарушением будет... :) Так что не всё определяется без разметки опять же...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 18:15 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 237
Владислав Жаринов писал(а):
Думаю, всё верно. Только уточнил бы - достижение любого мыслимого результата в таком подходе определяется как техпроцесс...

Одним словом, я причастен к "кубику", где идеологические принципы организации учёта, аналитики и пр., фактически, те же (ну, м.б. со взглядом чуть под другим углом, исходя из =>), но принципы построения самого кубика несколько иные. Это интересно, тем более, что пока практика заставляет именно больше программировать (и до- и перепрограммировать, особенно, если учесть, что наши законодательные деятели точно без работы не оставят :) ), чем конструировать (настраивать, конфигурировать и т.п., супер-универсал очень тяжело слепить, имея в виду то, чтобы его возможности отличались от монстро-ERP-кубиков, характеристики которых были выше).
В любом случае, необходимо посмотреть "поширше". И ещё раз спасибо, что обратили моё внимание.

Владислав Жаринов писал(а):
И схемы там нужны на разных уровнях - и вполне определённые. Например, схемы ТП такие, чтобы выражали параллельное по умолчанию исполнение...


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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 18:25 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 237
Мне на глаза попалась статья на сайте drakon.pbworks.com (извиняюсь, если это снова "баян" на этом форуме, я не в курсе). Автор явно не указан, но, в любом случае, там отражены взгляды Владимира Даниеловича по поводу затронутых вопросов насчёт структурности и проблем с goto. Действительно, визуальные техники в ДРАКОНе, фактически, это альтернатива "благородным goto" в текстовых языках (как break, continue и пр., в т.ч. и самому "грязному goto"), и всё сведено к формальным методам. Но решение проблем, затронутых выше by Alexey_Donskoy, в статье нет. К тому же, на мой скромный взгляд как человека, не занимающегося теоретическими разработками, в текстовых языках программирования уже как-то разобрались со всей структурностью (в т.ч. и со всеми надстройками, процедурными, ООП и пр.), и о goto вспоминают довольно редко (массовых обсуждений вокруг goto в том же Lua, как-то, замечено не было). Более того, сейчас в императивный мир всё больше и больше проникает техник из функционального программирования (и весьма оправданных), и в императивном коде всё меньше и меньше проглядывается явный "драконовский поезд", т.е. прямой детальный маршрут. Иными словами, ДРАКОН-паровозик в таком виде всё больше и больше отстаёт от локомотива отрасли, и его сфера применения в практичном программировании всё больше и больше сужается.

Кстати, в статье есть оценка взглядов Вельбицкого насчёт структурного и визуального программирования. Цитата из статьи:
Цитата:
...
Размышляя о причинах неудачи и стремясь поправить дело, И. Вельбицкий предлагает радикальным образом пересмотреть само понятие “структура программы”. По его мнению, “структура — понятие многомерное. Поэтому отображение этого понятия с помощью линейных текстов (последовательности операторов) сводит практически на нет преимущества структурного подхода. Огромные ассоциативные возможности зрительного аппарата и аппарата мышления человека используются практически вхолостую — для распознавания структурных образов в виде единообразной последовательности символов”.

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

В настоящее время визуальное программирование бурно развивается, число его сторонников растет. Тем не менее, уместно спросить: в какой мере предлагаемый Вельбицким пересмотр понятия “структура программы” согласуется с пионерскими взглядами Дейкстры?
...


А продолжения сущности в статье и нет. Суть вопроса, например, немного раскрыта в этой статье: Языки программирования. Цитата:
Цитата:
...
Изучение абстракции управления мы начнем со структурного программирования. Самое общеизвестное определение структурного программирования - подход к программированию, в котором для передачи управления в программе используется три конструкции: последовательная, выбора и итеративная.

Примерно так выглядело историческое становление концепции структурного программирования:

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

Эдсгер Дейкстра [Дейкстра 1975] предложил отказаться от оператора безусловного перехода и ограничиться тремя конструкциями - последовательностью, выбором и циклом;

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

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

И идеи Глушкова мы наблюдаем в Р-схемах Вельбицкого. Откровенно говоря, сугубо личное имхо, в таком виде Р-схемы лучше адаптированы к практичному программированию, чем ДРАКОН, в т.ч. у них лучше потенциал и для функционального подхода.

Кстати, в статье о языках есть упоминание и о ДРАКОНе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 18:49 

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

Ваши размышления важны в том отношении, что сейчас центр тяжести перемещается на реализацию проектного производства в реальной среде поддержки. Можно посмотреть здесь: viewtopic.php?f=93&t=1542&start=500.

В частности, интересны будут Ваши результаты в указанном здесь: viewtopic.php?p=74627#p74627 и здесь: viewtopic.php?p=74656#p74656.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 19:15 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Да, упоминаемые там среды PECAN и FIELD Стивена Рейсса с коллегами представлены здесь: viewtopic.php?f=97&t=4040 (в разных постах ветки). Как и новая разработка Дагаева... которая, возможно, имеет шансы войти в архитектуру таких сред... и вашего "кубика"...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 20:27 

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


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

Могу также сказать, что если у программиста отбирают удобство эмакса, вима, JEdit, Sublime, то должны быть серьёзные основания, это только Майкрософт или какой-нибудь Оракл смогут "нагнуть" под любую платформу, любой степени убогости :)


И по поводу Р-схем. Вот рисунок из выше указанной статьи про языки программирования:

Вложение:
r_stat_pl.PNG
r_stat_pl.PNG [ 21.61 КБ | Просмотров: 7256 ]


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

А большие кружочки не по ГОСТУ, как "дизайнерский ход", можно взять на вооружение. Короче говоря, в потенциальном редакторе должны быть настройки для всего: диаметр вершин, толщина линий, тип стрелок, шрифты и пр., в т.ч. и поддержка "чертёжного" стиля.

Кстати, если кому нужны чертёжные шрифты, то обращаю внимание, что появился OpenGostFont.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Среда, 12 Сентябрь, 2012 21:47 

Зарегистрирован: Понедельник, 09 Август, 2010 22:28
Сообщения: 128
Цитата:
Вот рисунок из выше указанной статьи про языки программирования


Уважаемый PSV100, поскольку я еще не очень разбираюсь в P-схемах, прошу посмотреть, насколько правильно я транслировал приведенные вами схемы в код:

Код:
if(x > y)
    z := x;
else
    z := y;


Код:
    input(a);
    s := 0;
    for(i := 1; i <= 10; ++i)
    {
         if(a[i] > 3)
              s := s + a[i];
    }
    print(s);


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 00:24 

Зарегистрирован: Понедельник, 25 Июнь, 2012 17:26
Сообщения: 237
usr345 писал(а):
Уважаемый PSV100, поскольку я еще не очень разбираюсь в P-схемах, прошу посмотреть, насколько правильно я транслировал приведенные вами схемы в код:
...

Вы думаете, что я разбираюсь ? :) Вроде, всё верно. Ну, можно сказать, что для второй схемы в "if" не хватает пустой части "else", если транслировать "в лоб". Но, действительно, лучше пусть "Р-оптимизатор" отрабатывает свой хлеб.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: ДРАКОН vs Р-схемы
СообщениеДобавлено: Четверг, 13 Сентябрь, 2012 05:31 

Зарегистрирован: Вторник, 26 Январь, 2010 09:31
Сообщения: 34
PSV100 писал(а):
Здесь не раскрыт ещё один вопрос про обратные дуги, как их интерпретировать. Когда мы находимся в левой вершине (стартовой, и не только циклов), то можем ли мы анализировать обратные дуги, т.е. если переход сработает, то это будет переход в "саму себя". Если глянуть на эти картинки:

Вложение:
r_pereh.PNG


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

Я поэкспериментрировал с циклами, и вот что получилось:
Базовый цикл-паук как паук и работает - после выполнения условно прямой дуги ищется проходимая условно обратная дуга, в случае наличия выполняется и цикл завершается, в противном случае вновь анализируются условно прямые дуги на проходимость. Если ни прямых ни обратных проходимых дуг нет, то программа завершается с сообщением о непроходимой структуре.
Но не всё так просто - как я уже говорил, семантика специальной дуги и, соответственно, семантика структуры, основанной на специальной дуге зависит от конкретной реализации. Эта семантика определяется надписью над дугой. И для цикла FOR, к примеру, внутренние дуги рассматриваются не как условия прохождения цикла, а просто как операторы цикла.
А вот для цикла WHILE это именно условия входа (многоветочный цикл)


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

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


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

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


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

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