DRAKON.SU

Текущее время: Воскресенье, 20 Сентябрь, 2020 14:29

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




Начать новую тему Ответить на тему  [ Сообщений: 38 ]  На страницу 1, 2  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 27 Июль, 2012 13:58 

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

Вы задали вопрос про цикл в примитиве здесь.
viewtopic.php?p=70268#p70268

Цитата:
Вопрос знатокам.

Разрешено ли построение цикла как на рисунке внизу? (доп. вход в цикл через точки А, B)
Если нет, то каким правилом пользоваться?


Мой ответ таков.

1. Язык ДРАКОН определен через графический синтаксис. Текстовый синтаксис не определен и может быть любым.

2. Как определен графический синтаксис? Он определен ДВОЯКО.
Во-первых, он определен через формальное описание (37 тезисов, изложенных в главе «Графический синтаксис языка ДРАКОН»). В последней книге это Глава 33, стр. 416—424.
Во-вторых, что очень важно, графический синтаксис определен через мое описание дракон-редактора. В последней книге это «Глава 32. Конструктор алгоритмов (помощник человека)», стр. 395—415.
http://drakon.su/_media/biblioteka/chas ... isanie.pdf

3. Оба описания (формальное и через действия редактора) должны быть тождественны. Если они не совпадают, значит, это ошибка. Мне о таких ошибках неизвестно. Я исхожу из того, что ошибок нет и оба описания тождественны.

4. Отсюда вытекает, что правильно построенный дракон-редактор является инструментом не только для конструирования правильных дракон-схем, но и инструментом ДЛЯ ПРОВЕРКИ готовой дракон-схемы, относительно которой есть сомнения, что она правильная. Это именно Ваш случай, Эдуард.

5. Отсюда следует порядок действий. Глядя на Вашу схему, следует провести мысленный эксперимент (а лучше эксперимент с помощью карандаша и бумаги). Попробуйте преобразовать заготовку-примитив в Вашу схему, с помощью конечного числа шагов идеального дракон-редактора, соответствующего моему описанию.
Если получится, значит, Ваша схема правильная. И наоборот.

6. Описанная проверка (через действия редактора) не заменяет проверку на соответствие формальному описанию, а дополняет ее. Хотя по сути эти проверки тождественны. Преимущество проверки через действия редактора состоит в том, что она более наглядна. В том смысле, что «метод через построение» позволяет пощупать построение руками (на каждом шаге построения).

ВЫВОДЫ

В1. Графический синтаксис языка ДРАКОН определен двумя разными методами: декларативным и процедурным, каждый из которых является математически строгим.

В2. Декларативный метод представляет собой формальное описание графического синтаксиса с помощью 37 тезисов.

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

В4. Все сказанное выше про примитив относится и к силуэту.

==============================================

Повторю главную мысль. Графический синтаксис языка ДРАКОН описан не одним, а двумя разными способами. Это улучшает надежность описания и упрощает возможность его проверки.
http://drakon.su/_media/biblioteka/chas ... isanie.pdf


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Июль, 2012 04:53 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Точнее, в двух разных формах - т.к. глава о конструкторе есть в своей основе Гл.14 из "Как улучшить..." - и представляет описание реализации исчисления, т.е. другую форму операционного же (как ещё говорят математики) способа определения. Илья то же называл конструктивным - "КАК <правильно> построить из базиса" (в данном случае - шампур-схему): viewtopic.php?p=39784#p39784.

Декларативный же (в математике мне привычней "денотационный") способ - это указать, "ЧТО есть правильно построенное" (и д.б. справедливо на любом шаге построения по операционному определению). А у Ильи говорится там же об аксиоматическом, причём эти два понятия и отделяют друг от друга как два разных подхода - здесь математическая специфика или подходы разных школ - это надо подумать теоретикам. В таком ключе в рамках исходной ветки высказывались как Илья: viewtopic.php?p=70288#p70288, так и Алексей: viewtopic.php?p=70524#p70524 - и сам Эдуард указал на вопросы, сохраняющиеся при "процедурном" определении по тезисам к результату с "декларативных" (денотационных) позиций: viewtopic.php?p=70569#p70569.

Ключевая мысль - в многоадресном силуэте появляется подмножество адресов веток, не детерминируемое каким-то линейным порядком на схеме. Это адреса в побочных выходах (заземлённых). Эти адреса назначаются сочинителем в общем случае произвольно. Именно такой случай и задан авторским определением ШМ для силуэтов. Что при этом получается - сказал опять же Алексей: viewtopic.php?p=70384#p70384. А для отражения частных случаев, когда какие-то типы переходов с побочных выходов недопустимы, нужно различать типы структур многоадресных силуэтов и порождающие их типы побочно-силуэтных БП. И уже на этой базе формулировать ограничения, исключающие структуры, недопустимые исходя из заданных целей (напр, структурность по Бёму-Джакопини, Дейкстре или что-нибудь менее строгое).

Тут что важно? Все перечисленные участники вводили разметку графа, индивидуализирующую и ветки, и веточные макроциклы. Т.е. уходили от ограничения предмета определения только "слепышами". На самом-то деле попытки денотации просто показали, что точное определение многоадресного силуэта при любом подходе требует такой разметки. Как она используется в конструктивном определении - можно видеть, скажем, здесь: viewtopic.php?p=70770#p70770 (тот же мотив можно видеть у Алексея, когда он говорит о "допограничениях" - ибо их можно сформулировать, лишь различая ветки и ВМЦ между собой).
Но, коль скоро опять сказано, то, что в стартовом посте под 1) - ясно, что дальнейшее обсуждение наиболее вероятно по схеме "есть два мнения - моё и неправильное"... :wink: Ибо чисто теоретически, быть может, можно индивидуализировать каждую ветку и ВМЦ в схеме и графически - но реально естественной формой разметки будет текст... Если так произойдёт - полезность обсуждения станет сомнительна.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Июль, 2012 14:42 

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

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

1. Первый веточный цикл (Овладение мудростью) помечен черными треугольниками.
2. Второй веточный цикл (Похищение сокровищ) помечен черными треугольниками с белым пятном.

Оба цикла — благодаря белому пятну на черном фоне — зрительно хорошо отличаются друг от друга.
Сразу видно, где один цикл, а где второй.
По моему, никаких проблем нет. Как Вы считаете?

Вложение:
Комментарий к файлу: Два веточных цикла в силуэте
0Рис. Колдунья png.png
0Рис. Колдунья png.png [ 370.54 КБ | Просмотров: 14984 ]


Это рис. 148 из книги "Дружелюбные алгоритмы".
Похожие алгоритмы для атомного реактора есть в книге "Учись писать. читать и понимать алгоритмы" (рис. 183 и 184).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Июль, 2012 21:53 

Зарегистрирован: Понедельник, 09 Август, 2010 22:28
Сообщения: 128
Цитата:
Оба цикла — благодаря белому пятну на черном фоне — зрительно хорошо отличаются друг от друга.
Сразу видно, где один цикл, а где второй.
По моему, никаких проблем нет. Как Вы считаете?


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

Это позволяет облегчить работу читателя подобного сложного алгоритма с непоследовательной структурой.

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

Хотя можно, например, не помещать фигуры, а закрашивать треугольники разными цветами: это еще проще. Правда метки будут нечитаемы при черно-белой печати.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Июль, 2012 13:17 

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

1. Первый веточный цикл (Овладение мудростью) помечен черными треугольниками.
2. Второй веточный цикл (Похищение сокровищ) помечен черными треугольниками с белым пятном.

Оба цикла — благодаря белому пятну на черном фоне — зрительно хорошо отличаются друг от друга.
Сразу видно, где один цикл, а где второй.
По моему, никаких проблем нет. …
Вложение:
0Рис. Колдунья png.png
0Рис. Колдунья png.png [ 370.54 КБ | Просмотров: 14949 ]


Действительно, начало и конец каждого цикла прекрасно различимы.
Но, что делать если веточных циклов больше 2-х? В чёрные треугольники вписывать различные белые геометрические фигуры?


Уважаемый Владимир Паронджанов!

Опять у меня вопрос о дополнительных входах СПРАВА в веточных циклах.
Я смотрю на представленный Вами рисунок (см. выше) и вижу два пересекающихся веточных цикла.
Описания пересекающихся веточных циклов у Вас я не нашёл.

На мой взгляд цикл «Овладение мудростью» имеет дополнительный второй вход через икону Имя Ветки «Похищение сокровищ». Вроде бы раньше утверждалось, что ЛЮБЫЕ циклы не могут иметь дополнительных входов. Возможно я что-то пропустил или не так понял.

Для того чтобы явно увидеть пересекающиеся циклы я построил схему-примитив (см. ниже) аналогичную представленной схеме-силуэт (если нигде не ошибся).
Вложение:
cross.png
cross.png [ 30.71 КБ | Просмотров: 14949 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Июль, 2012 14:28 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 4832
Откуда: Москва
Ильченко Эдуард писал(а):
Действительно, начало и конец каждого цикла прекрасно различимы.
Но, что делать если веточных циклов больше 2-х? В чёрные треугольники вписывать различные белые геометрические фигуры?
Если число веточных циклов больше 2-х, можно, например, поступить так, как предложили Вы, то есть с помощью различных белых геометрических фигур.

Пример 1. Если число веточных циклов больше 2-х, можно, например, для третьего веточного цикла черный треугольник рассечь шестью белыми вертикалями.

Пример 2. Для четвертого веточного цикла черный треугольник рассечь двумя белыми горизонталями.

Если число веточных циклов больше 4-х, можно, например, поступать так, как в книге "Как улучшить работу ума" в главе 13 Стр. 206, 207 (рис. 105). То есть, нумеровать 5, 6, 7 и т. д.

На сегодня более точного ответа у меня нет.

Ильченко Эдуард писал(а):
Опять у меня вопрос о дополнительных входах СПРАВА в веточных циклах.
Я смотрю на представленный Вами рисунок (см. выше) и вижу два пересекающихся веточных цикла.
Описания пересекающихся веточных циклов у Вас я не нашёл.

На мой взгляд цикл «Овладение мудростью» имеет дополнительный второй вход через икону Имя Ветки «Похищение сокровищ». Вроде бы раньше утверждалось, что ЛЮБЫЕ циклы не могут иметь дополнительных входов.
Вы правы. Возникает вопрос: как быть?
Я склоняюсь к тому, что подобные веточные циклы следует разрешить.

Вы согласны? Или у Вас есть возражения?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Июль, 2012 14:59 

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

Лично я согласен : )


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Июль, 2012 17:54 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ильченко Эдуард писал(а):
...
Уважаемый Владимир Паронджанов!

Опять у меня вопрос о дополнительных входах СПРАВА в веточных циклах.
Я смотрю на представленный Вами рисунок (см. выше) и вижу два пересекающихся веточных цикла.
Описания пересекающихся веточных циклов у Вас я не нашёл.
...
Дык оно и не нужно. Потому и говорил:
Владислав Жаринов в viewtopic.php?p=73618#p73618 писал(а):
...
Ключевая мысль - в многоадресном силуэте появляется подмножество адресов веток, не детерминируемое каким-то линейным порядком на схеме. Это адреса в побочных выходах (заземлённых). Эти адреса назначаются сочинителем в общем случае произвольно. Именно такой случай и задан авторским определением ШМ для силуэтов.
...
Как раз отсутствие в исходных ШМ-определениях какой-либо атрибуции для вершин, рёбер (кроме базовых типов ввода - если их понимать по Рэйлвей Кагену, то это атрибут именно ребра, а если по В.Д. - то точки ввода), а также для к.-л. подсхем (в частности, веток и ВМЦ) и соответственно - любых правил, связанных с такой атрибуцией (кроме опять же типизации ввода - по срочности), и означает, среди прочего, что допустима любая связность побочных выходов со входами веток в силуэте. И ни в каком специальном указании это не нуждается - м.б. только в пояснении, что оно именно так потому, что мы не включаем в рассмотрение свойства (естественно выражаемые через текст).
Примером "декларативного" определения схем, кстати, может служить эта графит-схема. Здесь общий случай адресации выражен графически - через БП-рёбра (выделяемые нетонким серым пунктиром - дальнейшие вариации по толщине линии/градации серого уже связаны с указанием областей действия ИЛИ-выбора).

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

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

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

А что же с теми самыми выходами "справа-слева", т.е. обсуждавшимся здесь: viewtopic.php?p=70770#p70770? Как это выразить? Можно через отношение порядка, как и задано в посте. Но. Мы должны либо снова строить "объёмные связи", как говорит Дмитрий_ВБ - т.е. "снимать кросс силуэта", показывая каждый переход отдельно. При этом полученные контуры не должны пересекаться - тогда и при "примитивизации" (которую выполнил Эдуард выше) это сохранится. Либо всё-таки индексировать ветки и петли ВМЦ и сформулировать системы неравенств от этих индексов. Т.е. ввести в метод неграфовый компонент.
    Замечу - обсуждавшиеся выше нецифровые обозначения (для ВМЦ) на самом деле не относятся к графам. Ибо есть по сути те же цифры, только по-иному записанные... :) Т.е. мы не можем говорить, что с их помощью мы ушли от текста. Вот вводя новые рёбра/вершины/подграфы для выражения - можем.
И вот вопрос по существу - а всё ли хотя бы сформулированное в указанном посте мы можем выразить через графы для общего случая? И даже если что-то можем - не слишком ли это усложнит определение? Не проще ли сочетать графовое с текстовым - для чего ввести атрибуты элементов и отдельных видов подсхем в исчисление?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 29 Июль, 2012 18:20 

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

Если число веточных циклов больше 4-х, можно, например, поступать так, как в книге "Как улучшить работу ума" в главе 13 Стр. 206, 207 (рис. 105). То есть, нумеровать 5, 6, 7 и т. д.

На сегодня более точного ответа у меня нет.
Ну, более точный ответ, очевидно, даёт математика. В данном случае дискретная. Если исходные посылки математики непрерывной можно шутливо выразить фразой одного из героев Стругацких "- Извлечём из чего-нибудь квадратный корень" :) (формально и общо - возьмём некие приближённые числа и вычислим/сравним их неким приближённым образом), то дискретной - "- Занумеруем что-нибудь и попробуем расположить как-нибудь". Т.е. атрибутируем наши дискреты числами (обычно - из натурального ряда) и зададим любые (или какие-то интересующие нас) их порядки. Ну а дальше - анализ и синтез...
Вот и Вы предложили нумерации ВМЦ - нечисловую (для 2..4 ВМЦ) и числовую (для 5 и более). Но в любом случае неграфовую - ибо порядок не выражен через связи элементов (в данном случае - петель ВМЦ, "вписанных" в петлю силуэта)...

Владимир Паронджанов писал(а):
...
Ильченко Эдуард писал(а):
...
На мой взгляд цикл «Овладение мудростью» имеет дополнительный второй вход через икону Имя Ветки «Похищение сокровищ». Вроде бы раньше утверждалось, что ЛЮБЫЕ циклы не могут иметь дополнительных входов.
Вы правы. Возникает вопрос: как быть?
Я склоняюсь к тому, что подобные веточные циклы следует разрешить.

Вы согласны? Или у Вас есть возражения?
Есть вопрос - а почему нужно разрешить? и что значит "подобные"?
В джамп-коде и неструктурном ВУ-представлении потока управления можно разрешать ведь вообще любые переходы...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 30 Июль, 2012 15:29 

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Август, 2012 13:21 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1082
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
Если так произойдёт - полезность обсуждения станет сомнительна.
По-моему, так она уже давно сомнительна, поскольку идёт не в том направлении. Поэтому возьму на себя смелость ответить на вопросы, заданные в ЛС, здесь - как повод ещё раз изложить основные тезисы, претензии и надежды на опыт Паронджанова и его дальнейшее развитие.

Владислав Жаринов писал(а):
Однако на самом деле возникает сомнение - а ответил ли вообще В.Д. Эдуарду?..
По-моему, ясно ответил: "На сегодня более точного ответа у меня нет", что по сути означает: не прорабатывал этот вопрос ни теоретически, ни практически (видать, писали программы так, чтобы не встречались столь "сложные" случаи).

Цитата:
Но главное - что Вы думаете о сказанном здесь: viewtopic.php?p=73618#p73618? Есть ли способ задать ограничения на порядок побочных переходов, не размечая ветки?..
Моё мнение - нет.
И даже думать на эту тему бессмысленно - ибо я принципиально против силуэта.
Поскольку он есть по сути фиговый листок для сокрытия беспорядочных goto вместо чёткой структуры циклов.
То, что Паронджановской команде удавалось писать качественный код на этой штуке, говорит, видимо, просто о культуре программирования, а отнюдь не о качестве языка...

Что хочу я? Я хочу видеть тело каждого цикла.
И, если уж накладывать структурные ограничения, то полностью, а не частично, с необходимостью плясок с бубнами вокруг силуэта.

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

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

Здесь я тоже категорически возражаю Владимиру Даниеловичу, приверженцу жёсткой бумажной копии. Возможно, я не оценил прелести такой работы, ну да и ладно. У меня дома вообще принтера нет, какая нафиг бумажная копия. :lol:

Я всегда говорил о том, что неободимо не зацикливаться на пропаганде Дракона, а продолжать создание действительно эргономичного инструмента.

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


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

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 66
Откуда: Москва
Alexey_Donskoy писал(а):
И даже думать на эту тему бессмысленно - ибо я принципиально против силуэта.
Поскольку он есть по сути фиговый листок для сокрытия беспорядочных goto вместо чёткой структуры циклов.
...
Что хочу я? Я хочу видеть тело каждого цикла.
...
Ну и, соответственно, веточный цикл - бред, бред и ещё раз бред.
Ну вот, в кои-то веки, послышался голос Разума.
Браво, Alexey_Donskoy!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 01 Август, 2012 14:08 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1082
Откуда: Россия, Чебоксары
Peter Almazov писал(а):
Ну вот, в кои-то веки, послышался голос Разума.
Уж не знаю, разум там или недоразумение, но я об этих проблемах как бы с самого начала говорил, вроде ещё в первой рецензии упоминал кое-что... а воз и ныне там... :(


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

Зарегистрирован: Пятница, 24 Апрель, 2009 16:28
Сообщения: 66
Откуда: Москва
Моя дата - 24 Апрель, 2009 :)
Цитата:
5. Самое важное. Я никогда не использовал Дракон, что неудивительно. И только сейчас почувствовал, насколько т. н. "наглядный рисунок" СКРЫВАЕТ границы циклов.


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

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

Если число веточных циклов больше 4-х, можно, например, поступать так, как в книге "Как улучшить работу ума" в главе 13 Стр. 206, 207 (рис. 105). То есть, нумеровать 5, 6, 7 и т. д.

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

Другое дело - что насчёт деления маршрутной структуры силуэтными соединителями я с Вами соглашусь. Тут только я бы уточнил кое-что.
Alexey_Donskoy писал(а):
...
Цитата:
Но главное - что Вы думаете о сказанном здесь: viewtopic.php?p=73618#p73618? Есть ли способ задать ограничения на порядок побочных переходов, не размечая ветки?..
Моё мнение - нет.
И даже думать на эту тему бессмысленно - ибо я принципиально против силуэта.
Поскольку он есть по сути фиговый листок для сокрытия беспорядочных goto вместо чёткой структуры циклов.
...
На самом деле он скорее выявляет реализацию петель циклов как БП на асме... конечно, загромождая её деталями описание... Но для программирования БЦВМ в командах и в ограничениях памяти это м.б. и плюсом... где-то способствуя написанию более качественного кода, мне кажется... конечно, в предположении "мозговых проверок" как основного метода обеспечения качества...

Alexey_Donskoy писал(а):
...
Что хочу я? Я хочу видеть тело каждого цикла.
И, если уж накладывать структурные ограничения, то полностью, а не частично, с необходимостью плясок с бубнами вокруг силуэта.
А вот тут согласен - особенно в предположении, что основным методом достижения качества становится расчётно-логическое проектирование программы (и инструкции). И тут конкретный вопрос:
Alexey_Donskoy писал(а):
...
По крайней мере, если уж силуэт - то строго из одноранговых операций.
Вложенные циклы никак в силуэт не вписываются в принципе. Это просто противоречит задаче их адекватного визуального представления.

Ну и, соответственно, веточный цикл ... - ... упаковать всё поплотнее и чтобы всё было обозримо.
Однако гораздо целесообразнее рассматривать ветку как цельное, неделимое действие.
Точнее, нарезать тело схемы на равновысотные фрагменты, чтобы скомпоновать схему в целом под нужный формат/размер диосцены... то, что здесь я называл "эргопереходом к силуэту"...
Вопрос - а если не используем goto, как в случае ЦД - как думаете, на две и более ветви декомпозировать то или иное укрупнённое действие по такому же основанию неоправданно?..


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 02 Август, 2012 07:37 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1082
Откуда: Россия, Чебоксары
Владислав Жаринов писал(а):
это можно понимать и иначе в свете сказанного полностью:
Обратите внимание, что "рассмотрен" и "глубоко проработан" - разные вещи. Как разны и позиции автора в тех моментах, где он не может поступиться принципами и где "можно, например, поступать так"...

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

Цитата:
Другое дело - что насчёт деления маршрутной структуры силуэтными соединителями я с Вами соглашусь.
Есть инструменты адекватные и не очень. Силуэт прекрасен для автоматной логики, как уже много раз говорили.

Цитата:
На самом деле он скорее выявляет реализацию петель циклов как БП на асме...
Категорически неверно. Вот условный оператор - выявляет. Да и то не всегда. Чтобы выявить полноценно, он должен быть не ромбиком, а несимметричной фигурой, явно указывающей направление условного перехода.
В то же время семантика цикла находится уровнем выше, чем семантика условного перехода.
Конструкция цикла, в отличие от условного перехода, не имеет аппаратной реализации (за некоторыми исключениями вроде префикса REP - интеловских макрокоманд :) ).
Так что цикл вводится как метаинформация, мнемоника, внешняя характеристика программного кода, не имеющая прямого отношения к железу вообще и к асму в частности.

Цитата:
Но для программирования БЦВМ в командах и в ограничениях памяти это м.б. и плюсом...
Вы издеваетесь? Я специально пробовал решить таким путём элементарную задачу копирования - что-то путное из этого вышло?!

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

Цитата:
Вопрос - а если не используем goto, как в случае ЦД - как думаете, на две и более ветви декомпозировать то или иное укрупнённое действие по такому же основанию неоправданно?..
Категорически не оправданно.
Повторю ещё раз:
- в настоящее время силуэт призван решать только задачу визуальной компоновки кода, исходя из требования твёрдобумажного его представления;
- однако требуется компоновка по смыслу действий; а эргономика визуальных представлений должна решаться совсем другими способами.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 03 Август, 2012 20:35 

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

Цитата:
Другое дело - что насчёт деления маршрутной структуры силуэтными соединителями я с Вами соглашусь.
Есть инструменты адекватные и не очень. Силуэт прекрасен для автоматной логики, как уже много раз говорили.
Возможно, в "примитиве" указание петель циклов тоже будет обосновано - и именно при представлении автоматной логики (если точно - то информатизации диаграмм переходов). Имеется в виду описанное здесь в п. 2: viewtopic.php?p=65423#p65423. Сверхциклы по цепочкам состояний (для них, кстати, приставка "макро" м.б. естественнее, чем для веточных) полезно прослеживать.

Alexey_Donskoy писал(а):
...
Цитата:
На самом деле он скорее выявляет реализацию петель циклов как БП на асме...
Категорически неверно. Вот условный оператор - выявляет. Да и то не всегда. Чтобы выявить полноценно, он должен быть не ромбиком, а несимметричной фигурой, явно указывающей направление условного перехода.
В то же время семантика цикла находится уровнем выше, чем семантика условного перехода.
Конструкция цикла, в отличие от условного перехода, не имеет аппаратной реализации (за некоторыми исключениями вроде префикса REP - интеловских макрокоманд :) ).
Так что цикл вводится как метаинформация, мнемоника, внешняя характеристика программного кода, не имеющая прямого отношения к железу вообще и к асму в частности.
Но, вероятно, возможны и машины с реализацией цикла в СК?
Замечу, что я-то как раз ограничивался реализацией именно петли цикла - в смысле разобранного здесь. Вы смотрите шире - что правильно.

Alexey_Donskoy писал(а):
...
Цитата:
Но для программирования БЦВМ в командах и в ограничениях памяти это м.б. и плюсом...
Вы издеваетесь? Я специально пробовал решить таким путём элементарную задачу копирования - что-то путное из этого вышло?!
Ну я ж не зря сказал дальше "при условии..." :) Смотрят люди на схему - и при сложившихся навыках визуально-структурного анализа и ряд аспектов работоспособности выявляют, и оптимизировать могут... полуформально, но им достаточно...

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

Alexey_Donskoy писал(а):
...
Наконец, возвращаясь к циклу, мы видим, что можем изобразить его двумя путями (!): как обычный цикл, с условным оператором и возвратом, и как веточный цикл, где дуга возврата разрывается, проходя через адресные конструкции силуэта. Подобная двусмысленность представляется мне как минимум эргономически неоправданной, да и вообще методически неверной.
Не говоря уж, как разрывается в цикле ДЛЯ (что идёт уже из ГОСТ/ИСО)...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 04 Август, 2012 01:30 

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


Цикл можно изобразить ещё одним способом (см. ниже), не привлекая сущности за пределами описанного множества элементов языка ДРАКОН.
Правда при этом появляется некоторая избыточность.
Но эту избыточность можно попробовать попользовать с пользой.
Пока думаю как : )
Вложение:
cycle3.png
cycle3.png [ 3.49 КБ | Просмотров: 14765 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 04 Август, 2012 07:29 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1082
Откуда: Россия, Чебоксары
Ильченко Эдуард писал(а):
Цикл можно изобразить ещё одним способом...
Скорее, это не "ещё один способ", а попытка шага в сторону формального отображения семантики цикла. Обобщённого.
По сути с этого бы и надо было начинать :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 04 Август, 2012 08:08 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Короче, ещё один способ показать LOOP-EXIT?.. :) А как обобщённый цикл в Вашем понимании соотносится с "гибридным" (см. здесь)?..


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

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


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

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


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

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