DRAKON.SU

Текущее время: Пятница, 29 Март, 2024 00:10

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




Начать новую тему Ответить на тему  [ Сообщений: 100 ]  На страницу Пред.  1, 2, 3, 4, 5
Автор Сообщение
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Среда, 23 Март, 2011 22:14 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
alexus писал(а):
Исполнитель один, а результатов много. Это давняя дискуссия. Например, что делать, если из функции надо вернуть более одного значения? Создавать временные структуры? Вводить формальные var параметры? Костыли?..
Что-то я тут проблемы не вижу. Отработала некая процедура, изменила вектор состояния системы. Что тут удивительного? Параметризация - это уже в известной мере от лукавого, как попытка всюду, где только можно, оптимизировать всё, что ни попадя... Хотя и природа поступает так же - везде фрактальные подобия с простыми "правилами вывода"... да и то сказать, ведь из стандартных кирпичиков собрано всё ;)
В общем, как хотите, не вижу тут принципиальных проблем...
Может, играет роль моё многолетняя работа со сложными имитационными моделями? И я легко воспринимаю пространство состояния, квант его изменения (выражаемый в том числе и алгоритмически)... Мне по барабану аргументы функций, однако ;)

Цитата:
Нет, не так, если под алгоритмом понимать заданную последовательность действий. Чтобы было понятнее, попробую пояснить. Перед пользователем на экране монитора "висит" форма. Что на этой форме в следующий момент времени нажмет, введет, отметит пользователь? Неизвестно. Является ли форма алгоритмом? В систему из разных источников поступает много самой разной информации, которая внутри системы как-то обрабатывается, и в результате получается некая реакция. Является ли система алгоритмом?
Есть набор данных. Есть тип данных "событие". Есть тип данных "обработчик события". Последний выражается алгоритмом. В чём проблемы? Всё элементарно же!

Мы НЕ ЗАДАЁМ единый алгоритм формы.
Мы задаём специфический набор данных, обладающих собственным поведением.
Проблем нет.

Цитата:
Так я Вам еще раньше намекал на 3D очки...
Так это не мне намекать надо, я об этом здесь давно талдычу ;)

Цитата:
"Дык, а "правила оформления" - это ж и есть язык!"
Нет, ни в коем случае... Есть язык, а есть правила оформления отступов, правила комментирования, правила использования GoTo и т.д. и т.п. К языку это прямого отношения не имеет.
Имеет. Это тоже язык.
Если угодно, можно назвать метаязыком, языком другого уровня.
Любая формальная система представления есть язык.

В данном случае язык более формален, а метаязык - нечёток. Но это вовсе не обязательное разделение.
Можно потребовать совместить оба уровня... в синтаксисе даже...

А возникают эти уровни, имхо, из-за изначальной неадекватности инструмента-языка решаемой задаче.
Вот тут и рождаются правила по применению языка, правила по формализации правил (ака стандарты), научные школы и т.д. и т.п.
Может, лучше задачу решать? ;)


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Среда, 23 Март, 2011 22:54 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 54
Alexey_Donskoy писал(а):
alexus писал(а):
Исполнитель один, а результатов много. Это давняя дискуссия. Например, что делать, если из функции надо вернуть более одного значения? Создавать временные структуры? Вводить формальные var параметры? Костыли?..
Что-то я тут проблемы не вижу. Отработала некая процедура, изменила вектор состояния системы. Что тут удивительного?
Нет ничего удивительного. Но не о векторах состояний системы речь. Речь о том, что надо вернуть из подпрограммы (процедуры, функции, метода) несколько значений, как результат работы алгоритма.
Alexey_Donskoy писал(а):
Цитата:
Нет, не так, если под алгоритмом понимать заданную последовательность действий. Чтобы было понятнее, попробую пояснить. Перед пользователем на экране монитора "висит" форма. Что на этой форме в следующий момент времени нажмет, введет, отметит пользователь? Неизвестно. Является ли форма алгоритмом? В систему из разных источников поступает много самой разной информации, которая внутри системы как-то обрабатывается, и в результате получается некая реакция. Является ли система алгоритмом?
Есть набор данных. Есть тип данных "событие". Есть тип данных "обработчик события". Последний выражается алгоритмом. В чём проблемы? Всё элементарно же!
Тип данных "обработчик события" - это интересно... Но речь о том, что алгоритма может не быть. Сама форма или система не являются алгоритмом. Да, конечно, они могут содержать алгоритмы в каких-то своих частях, но это не превращает их самих в алгоритмы. Взаимодействие с формой/системой происходит произвольно и не определяется последовательностью действий. Поэтому Дракон не то средство, которое можно/нужно использовать для проектирования систем.
Alexey_Donskoy писал(а):
Мы НЕ ЗАДАЁМ единый алгоритм формы.
Мы задаём специфический набор данных, обладающих собственным поведением.
Проблем нет.
Проблем нет до тех пор пока не используются алгоритмические языки для описания "неалгоритмов". А когда используют, то получается то, о чем Вы сами пишите, как о проблеме:
Alexey_Donskoy писал(а):
1) К сожалению, пока рассматриваемые визуальные технологии (включая Дракон) никак не помогают решать главную задачу - проектирование программной системы. К тем вопросам, которые А.Седов ставил в Фидо ещё 15 лет назад, и близко не подошли.
2) Дракон помогает уменьшить издержки в ряде частных случаев. Но также и вводит дополнительные издержки в других местах. Средняя температура по больнице не изменяется.

Alexey_Donskoy писал(а):
Цитата:
"Дык, а "правила оформления" - это ж и есть язык!"
Нет, ни в коем случае... Есть язык, а есть правила оформления отступов, правила комментирования, правила использования GoTo и т.д. и т.п. К языку это прямого отношения не имеет.
Имеет. Это тоже язык.
Если угодно, можно назвать метаязыком, языком другого уровня.
Любая формальная система представления есть язык.
Это не представление, а правила оформления. Язык не заставляет рисовать "шампуры", не делать пересечений... разбивать на процедуры длинные фрагменты кода, включать комментарии и т.п. Все это правила.
Alexey_Donskoy писал(а):
В данном случае язык более формален, а метаязык - нечёток. Но это вовсе не обязательное разделение.
Можно потребовать совместить оба уровня... в синтаксисе даже...
Зачем???
Alexey_Donskoy писал(а):
А возникают эти уровни, имхо, из-за изначальной неадекватности инструмента-языка решаемой задаче.
Вот тут и рождаются правила по применению языка, правила по формализации правил (ака стандарты), научные школы и т.д. и т.п.
Может, лучше задачу решать? ;)
Да, нормальный инструмент... для записи алгоритмов. Но пытаться на нем рисовать процесс познания или систему какую-то я бы не стал (это не сфера применения данного средства и говорить об адекватности таким задачам, IMHO, некорректно).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 10:10 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
alexus писал(а):
Речь о том, что надо вернуть из подпрограммы (процедуры, функции, метода) несколько значений, как результат работы алгоритма.
Для чего?
Мы же вроде как обсуждаем достаточно глобальные вопросы - причём тут мелкая техническая привязка к реализации подпрограммы?

И чем, кстати, Вам не нравится передача кучи параметров по ссылке?

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

Цитата:
Но речь о том, что алгоритма может не быть. Сама форма или система не являются алгоритмом. Да, конечно, они могут содержать алгоритмы в каких-то своих частях, но это не превращает их самих в алгоритмы. Взаимодействие с формой/системой происходит произвольно и не определяется последовательностью действий.
Форма в данном случае является контейнером данных и алгоритмов, если уж на то пошло.
Любое преобразование данных (включая передачу их по интерфейсу GUI) задаётся алгоритмами. Куда ни копни, внутри в качестве элементарного кирпичика будет алгоритм. Сама по себе форма, конечно же, алгоритмом не является, но это нам ничего не даёт.
В данном случае нам нужно иметь средства проектирования:
- внутренней структуры контейнера (взаимосвязи кирпичиков данных и алгоритмов);
- внешних интерфейсов контейнера;
- самих алгоритмов-кирпичиков;
- визуальных представлений контейнера...

Цитата:
Поэтому Дракон не то средство, которое можно/нужно использовать для проектирования систем.
Так я и не говорю про Дракон. Просто он является поводом поговорить о проектировании в целом.

Цитата:
Проблем нет до тех пор пока не используются алгоритмические языки для описания "неалгоритмов".
Ну так я и пишу об адекватности инструмента ;)

Цитата:
Это не представление, а правила оформления. Язык не заставляет рисовать "шампуры", не делать пересечений... разбивать на процедуры длинные фрагменты кода, включать комментарии и т.п. Все это правила.
Таки язык, Александр, язык. Пусть неформальный, пусть мета, но язык.
А любой язык организует ПРЕДСТАВЛЕНИЕ рассматриваемого предмета С ОПРЕДЕЛЁННОЙ ТОЧКИ ЗРЕНИЯ. Это - основная функция языка, имхо :)

Цитата:
Да, нормальный инструмент... для записи алгоритмов.
Даже для рисования алгоритмов - не самый нормальный. Нужны же ведь 3д очки! :D


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 10:52 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 54
Alexey_Donskoy писал(а):
alexus писал(а):
Речь о том, что надо вернуть из подпрограммы (процедуры, функции, метода) несколько значений, как результат работы алгоритма.
Для чего?
Мы же вроде как обсуждаем достаточно глобальные вопросы - причём тут мелкая техническая привязка к реализации подпрограммы?
Я просто пример привел. Конкретный пример это всегда частность.
Alexey_Donskoy писал(а):
И чем, кстати, Вам не нравится передача кучи параметров по ссылке?
Дело не в том, что нравится или не нравится. Нелогичным кажется тот момент, что N-параметров возвращаются, как VAR-параметры, а один, как результат функции.
Alexey_Donskoy писал(а):
Цитата:
Но речь о том, что алгоритма может не быть. Сама форма или система не являются алгоритмом. Да, конечно, они могут содержать алгоритмы в каких-то своих частях, но это не превращает их самих в алгоритмы. Взаимодействие с формой/системой происходит произвольно и не определяется последовательностью действий.
Форма в данном случае является контейнером данных и алгоритмов, если уж на то пошло.
Да, конечно.
Alexey_Donskoy писал(а):
Любое преобразование данных (включая передачу их по интерфейсу GUI) задаётся алгоритмами.
Почему передача включена в преобразование?.. И почему Вы решили, что преобразование данных обязательно задается алгоритмами? А если преобразование выбирается самими данными, по одним им ведомой причине... то есть, не задано в виде последовательных шагов...
Alexey_Donskoy писал(а):
Куда ни копни, внутри в качестве элементарного кирпичика будет алгоритм.
Хорошо, давайте копнем... атом - это алгоритм или система? А человек? А вселенная?
Alexey_Donskoy писал(а):
Сама по себе форма, конечно же, алгоритмом не является, но это нам ничего не даёт.
Почему ничего не дает?
Alexey_Donskoy писал(а):
В данном случае нам нужно иметь средства проектирования:
- внутренней структуры контейнера (взаимосвязи кирпичиков данных и алгоритмов);
Построитель форм + набор компонентов + компилятор в некое подобие .RC-файлов.
Alexey_Donskoy писал(а):
Цитата:
Поэтому Дракон не то средство, которое можно/нужно использовать для проектирования систем.
Так я и не говорю про Дракон. Просто он является поводом поговорить о проектировании в целом.
А!.. Простите великодушно, я этого не понял...
Alexey_Donskoy писал(а):
Цитата:
Это не представление, а правила оформления. Язык не заставляет рисовать "шампуры", не делать пересечений... разбивать на процедуры длинные фрагменты кода, включать комментарии и т.п. Все это правила.
Таки язык, Александр, язык. Пусть неформальный, пусть мета, но язык.
А любой язык организует ПРЕДСТАВЛЕНИЕ рассматриваемого предмета С ОПРЕДЕЛЁННОЙ ТОЧКИ ЗРЕНИЯ. Это - основная функция языка, имхо :)
Мы, наверно, слишком различно смотрим на понятие "язык"...
Alexey_Donskoy писал(а):
Цитата:
Да, нормальный инструмент... для записи алгоритмов.
Даже для рисования алгоритмов - не самый нормальный. Нужны же ведь 3д очки! :D
А почему, собственно, алгоритмы должны быть плоскими?.. Может для того, чтобы появился повод обсуждать пересечения? :roll:


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 11:17 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
alexus писал(а):
Почему передача включена в преобразование?.. И почему Вы решили, что преобразование данных обязательно задается алгоритмами? А если преобразование выбирается самими данными, по одним им ведомой причине... то есть, не задано в виде последовательных шагов...
Дык, раз уж мы говорим о программной системе, то в ней таки есть строго определённый инвариант - это исполнитель (hardware).
А исполнитель любое преобразование данных осуществляет по алгоритму. И решительно неважно, откуда взялся этот алгоритм - то ли он железно прошит на уровне связей программной системы, то ли он определяется данными (кстати, здесь часто бывает и крайний случай - данные являются кодом, и промежуточные - данные задают структуру связей управления).
Так что, если копнуть достаточно глубоко, алгоритм всегда в основе есть :)

Цитата:
Хорошо, давайте копнем... атом - это алгоритм или система? А человек? А вселенная?
"Атомов не существует, поверьте квантовому химику!" (с) А.Хаврюченко

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

Цитата:
А почему, собственно, алгоритмы должны быть плоскими?.. Может для того, чтобы появился повод обсуждать пересечения? :roll:
Да, у меня как раз и сложилось такое впечатление! :lol:
Потому что здесь, на форуме, слишком выражена тенденция консервации авторского взгляда на язык Дракон и его применение :(
Противоположные тенденции тоже есть, но пока нет вразумительной формулировки желаемого. А о когнитивной эргономике все благополучно забывают, а ведь это именна та жемчужина, которую Паронджанов нам подарил своими работами!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 12:38 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 51
Alexey_Donskoy писал(а):
alexus писал(а):
А почему, собственно, алгоритмы должны быть плоскими?.. Может для того, чтобы появился повод обсуждать пересечения? :roll:
Да, у меня как раз и сложилось такое впечатление! :lol:

Поздравляю вас с этим "открытием". :wink:

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 12:52 
Аватара пользователя

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 13:39 

Зарегистрирован: Вторник, 13 Ноябрь, 2007 20:38
Сообщения: 51
Alexey_Donskoy писал(а):
никто пока толком не объяснил (или я не заметил), что такое "требования структурности" в применении к алгоритмам ;)
Под "требованиями структурности" применительно к алгоритмам я понимаю дисциплину, которая ограничивает применение управляющих конструкций, устанавливает особые правила их использования. В качестве элементарной "управляющей конструкции" можно рассматривать точку ветвления вычислительного процесса в зависимости от какого-либо условия.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 16:59 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 54
Alexey_Donskoy писал(а):
alexus писал(а):
Почему передача включена в преобразование?.. И почему Вы решили, что преобразование данных обязательно задается алгоритмами? А если преобразование выбирается самими данными, по одним им ведомой причине... то есть, не задано в виде последовательных шагов...
Дык, раз уж мы говорим о программной системе, то в ней таки есть строго определённый инвариант - это исполнитель (hardware).
А исполнитель любое преобразование данных осуществляет по алгоритму.
Или по команде?..
Alexey_Donskoy писал(а):
И решительно неважно, откуда взялся этот алгоритм - то ли он железно прошит на уровне связей программной системы, то ли он определяется данными (кстати, здесь часто бывает и крайний случай - данные являются кодом, и промежуточные - данные задают структуру связей управления).
Так что, если копнуть достаточно глубоко, алгоритм всегда в основе есть :)
Ничуть не сомневаюсь. Особенно важно в этом случае... желание видеть или не видеть!.. 8)
Alexey_Donskoy писал(а):
Цитата:
Хорошо, давайте копнем... атом - это алгоритм или система? А человек? А вселенная?
"Атомов не существует, поверьте квантовому химику!" (с) А.Хаврюченко
А.Хаврюченко я 15 лет назад не слишком верил, и с тех пор ничего не изменилось.
Alexey_Donskoy писал(а):
Но таки да, алгоритм в чистом виде действительно не существует.
И я ужде писал выше, что целесообразность алгоритмического взгляда на систему иногда бывает сомнительна.
Ну, вот и хорошо.
Alexey_Donskoy писал(а):
Однако ж вон тот самый вышеупомянутый хардвер накладывает сильное ограничение на возможные способы работы с системой. Так появляется необходимость в алгоритмическом представлении.
Нет, истоки алгоритмизации в другом: закрепление позитивного опыта с последующим возможным планированием, исполнением... и, следовательно, появлении нового опыта и т.д. Программирование просто идет по пути, который протоптали до него.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 17:00 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 54
igor писал(а):
Принимать решение относительно легитимности пересечений нужно исходя из требований структурности, предъявляемых к алгоритмам. Если принятое решение каким-то боком будет не удобно с точки зрения восприятия Дракон-схем, то это будет проблема самих Дракон-схем, а не этого решения.
+100


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 17:10 

Зарегистрирован: Четверг, 21 Январь, 2010 18:06
Сообщения: 63
Откуда: Нижний Новгород
"Алгори́тм, от имени учёного аль-Хорезми — точный набор инструкций, описывающих порядок действий исполнителя для достижения результата решения задачи за конечное время. " - Это википедия. Система есть совокупность статических и динамических объектов, каждый из которых работает по собственному "алгоритму". Зачем смешивать понятия ?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 17:22 
Аватара пользователя

Зарегистрирован: Суббота, 27 Февраль, 2010 23:34
Сообщения: 54
igor писал(а):
Alexey_Donskoy писал(а):
никто пока толком не объяснил (или я не заметил), что такое "требования структурности" в применении к алгоритмам ;)
Под "требованиями структурности" применительно к алгоритмам я понимаю дисциплину, которая ограничивает применение управляющих конструкций, устанавливает особые правила их использования. В качестве элементарной "управляющей конструкции" можно рассматривать точку ветвления вычислительного процесса в зависимости от какого-либо условия.
Структуризация кода позволила, в свое время, существенно снизить сложность программ. А снижение сложности создания программ, в свою очередь, позволило повысить сложность решаемых задач. Для примера...
Снижение сложности за счет локализации кода:
Код разбит на подпрограммы, вход в подпрограммы выполняется через единственную точку входа. Таким образом, функционально единая часть код локализована в теле подпрограммы и на нее не может быть совершен произвольный переход. Происходит существенное снижение количества потенциально возможных связей и, следовательно, сложности программы в целом.
Снижение сложности за счет локализации данных:
Данные в структурном программировании выступают в трех видах:
1. Глобальные данные, отвечающие за сохранение значений между вызовами подпрограмм и доступные из всех подпрограмм (глобальная область видимости);
2. Локальные данные, доступные только внутри подпрограммы и недоступные для других подпрограмм;
3. Фактические параметры, передаваемые в подпрограмму извне.
Механизм формально/фактических параметров, в частности, позволил избавиться от зависимости от глобальных данных, а, следовательно, создал возможность переносимости отлаженных подпрограмм между разными программами.
Механизм локальных данных позволил подпрограмме изолировать свои данные от модификации извне. То есть, обеспечить снижение связности по данным.

Сказанное выше не исчерпывает то, что привнесено структурным программированием или им "узаконено".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Четверг, 24 Март, 2011 22:33 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 1098
Откуда: Россия, Чебоксары
alexus писал(а):
Особенно важно в этом случае... желание видеть или не видеть!.. 8)
Ну не знай, не знай! ;)
Имеющий глаза, как говорится, да увидит по вере своей! ;)

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

Хотя могло бы быть интересно :roll:

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Понедельник, 20 Июнь, 2011 23:04 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
albobin писал(а):
А, если, на шампур нанизать q1 s1 q2 s2 q3 конец
тогда боковые ветви
от q3 на s3 s4 s5
от q2 на s4
от q1 на s5

Уважаемым albobin был предложен вариант, который остался вроде бы незамеченным. Наверно, потому что не был визуализирован : )
Визуализирую : ) см. рисунок справа.

Alexey_Donskoy писал(а):
Это кусок тела большого цикла (или, если угодно, обработчик прерывания от таймера).
q1 - проверка каждого 1000-го цикла.
s5 - действие, которое должно выполняться в каждом цикле
q3 - выход по ошибке, когда нельзя выполнять действие s5.
На первой схеме представлен основной порядок действий (хотя выполняется 1 раз на 1000 циклов, но весь смысл тут).

Вложение:
fig.png
fig.png [ 49.83 КБ | Просмотров: 20155 ]

Учитывая, что q3 выход по ошибке, то алгоритм стал даже понятнее. Конечно, имхо.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Воскресенье, 26 Июнь, 2011 13:50 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ильченко Эдуард писал(а):
...
Визуализирую : ) см. рисунок справа.
Alexey_Donskoy писал(а):
Это кусок тела большого цикла (или, если угодно, обработчик прерывания от таймера).
q1 - проверка каждого 1000-го цикла.
s5 - действие, которое должно выполняться в каждом цикле
q3 - выход по ошибке, когда нельзя выполнять действие s5.
На первой схеме представлен основной порядок действий (хотя выполняется 1 раз на 1000 циклов, но весь смысл тут).
Вложение:
fig.png
Учитывая, что q3 выход по ошибке, то алгоритм стал даже понятнее. Конечно, имхо.
IMHO - если из словесной спецификации Алексея исходить, то именно s5 д.б. на главном маршруте фрагмента (ох, жаль, что "туннели" не используем - вот и рисуем часть как целое :wink: ) - а альтернатива по q3 на побочном. Так что с этой т. зр., если не разрешать пересечения - лучше правая схема на цветном фоне.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Преобразование графов
СообщениеДобавлено: Воскресенье, 26 Июнь, 2011 19:37 

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

Не могли бы Вы графически изобразить вышеуказанный алгоритм, с использованием "туннелей"? По Вашей ссылке не могу сообразить что к чему ... : (


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Июнь, 2011 12:03 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1443
Ильченко Эдуард писал(а):
...
Не могли бы Вы графически изобразить вышеуказанный алгоритм, с использованием "туннелей"? По Вашей ссылке не могу сообразить что к чему ... : (
В принципе там определение, а примеры разбросаны по иллюстрациям :) Вот я сделал специально эскиз (заодно уж и с областями - раз уж о них писал). Варианту А соответствует на этом рисунке, допустим, правая из схем на цветном фоне, варианту Б - Ваша схема.
Тела схем рисовать не стал - обозначил шампур-заместителями :wink:: P.S. Посмотрел - в альбомном формате лучше компонуется. Заодно кое-что изменил - чтобы ещё некоторые вещи показать.
Вложение:
Комментарий к файлу: Визуальная "очная ставка" двух способов вариантной декомпозиции по графит-методу.
Рисунки А3LS Туннели и Область (для Эдуарда).png
Рисунки А3LS Туннели и Область (для Эдуарда).png [ 305.19 КБ | Просмотров: 19963 ]

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

P.P.S. Взял больший формат и разделил способы. Видно, что автономная область отличается от выноски отсутствием атрибуции статуса сочинения. А кроме того, любая вынесенная область - элемент своеобразного каталога вариантов (палетты) для оперативного подключения к любой модели (в т.ч. из другого документа). Выноска же делается всегда в том же документе и частью модели не является - м.б. связана только по ссылке с ограничителем, который указал сочинитель - в общем, в терминах IDEF, это "схема FEO".
    Да, об индексах областей (в т.ч. группах подстановки) см. в этом подпункте; там же - о смысле атрибутов 'Вх?' и 'SUBSTEXT' (на примере определения синт-переключателя во второй части). О цветовых обозначениях текста для графит-макетов - стр.1 в словаре на этой схеме.


Вложения:
Комментарий к файлу: Оригинал того же образа.
Рисунки А3LS Туннели и Область (для Эдуарда).odg [39.98 КБ]
Скачиваний: 449


Последний раз редактировалось Владислав Жаринов Вторник, 28 Июнь, 2011 05:43, всего редактировалось 3 раз(а).
Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Июнь, 2011 18:58 

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

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

Ну, да ладно : ) Всё равно большое спасибо!


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 27 Июнь, 2011 19:18 

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

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


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

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


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

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


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

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


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

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