DRAKON.SU

Текущее время: Четверг, 28 Март, 2024 14:35

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




Начать новую тему Ответить на тему  [ Сообщений: 61 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 16 Январь, 2014 14:57 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Спасибо, Степан Борисович


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 27 Март, 2015 21:48 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Предлагаю последнюю редакцию для "Макроиконы языка ДРАКОН"
Вложение:
Комментарий к файлу: Макроиконы
Fig. 18 Macroicons Rev2 .png
Fig. 18 Macroicons Rev2 .png [ 402.27 КБ | Просмотров: 16242 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Март, 2015 09:07 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Геннадий Тышов опубликовал замечания:
Геннадий Тышов писал(а):
На Fig. 18 представлены все образованные макроиконы с иконой Синхронизатор, но нет макроикон с иконой Событие. При сходном начертании икон Синхронизатор и Событие, область их применения разная и макроиконы должны быть различными по сочетанию входящих икон и по наименованию.
Полезное замечание. Спасибо. Учту. Внесу изменения в английский текст.

Геннадий Тышов писал(а):
В ИС Дракон для иконы Событие в качестве прототипа выбрана икона ПараллельныйПроцесс, а у В.Д. Паронджанова Синхронизатор.
В ИС Дракон икона Событие присоединяется к иконам Заголовок, Вопрос или Выбор, что позволяет отобразить процедуру Обработчик события или проверить наличие события и отобразить его обработку.
Здесь мне преимущества не очевидны.

Геннадий Тышов писал(а):
В ИС Дракон икона Событие имеет два поля: для указания источника вызвавшего события и для указания вида события у источника. У В.Д. Паронджанова для иконы События разделения источника и вида события нет, это большой недостаток в визуальном алгоритме.
Какой недостаток?

Геннадий Тышов писал(а):
В Fig. 17 и Fig.18 различное начертание или стиль начертания иконы Параметры.

----

В ГОСТ 19.701-90 стандартизована международная и устоявшаяся десятилетиями практика отображения параллельных действий.
У В.Д. Паронджанова параллельные действия выполнены с большим отступлением от ГОСТ 19.701-90. Отображение является надуманным и ничем не обоснованным.
В ИС Дракон параллельные действия отображаются в соответствии со стандартом.
ДРАКОН создан для того, чтобы ЗАМЕНИТЬ этот давно устаревший стандарт.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Март, 2015 17:40 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Выкладываю рисунок 18 (Fig. 18) содержащий Макроиконы.
Рисунок исправлен в соответствии с замечанием Геннадия Тышова.

Геннадий Николаевич, спасибо за подсказку.

Вложение:
Комментарий к файлу: Макроиконы языка ДРАКОН
Fig. 18 Macroicons Rev2 .png
Fig. 18 Macroicons Rev2 .png [ 507.46 КБ | Просмотров: 16217 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 28 Март, 2015 23:48 

Зарегистрирован: Четверг, 10 Январь, 2013 16:59
Сообщения: 70
Владимир Паронджанов писал(а):
Выкладываю рисунок 18 (Fig. 18) содержащий Макроиконы. Рисунок исправлен в соответствии с замечанием Геннадия Тышова.


Владимир Даниэлович, здравствуйте.

Меня на премодерацию поставили, теперь пытаюсь публиковать свои посты в виде цитат. То есть, разрешаю это править и публиковать.

--

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 31 Март, 2015 22:16 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Цитата:
1) Не понятно, чем отличаются параллельные действия от параллельных процессов. Если этот вопрос обсуждался, намекните. Попробую найти.


Читать надо здесь
http://drakon.su/knigi_vladimira_parondzhanova._skachat

Особенно здесь см. глава 13 и 14
http://drakon.su/_media/biblioteka_1/01 ... linnik.pdf

Цитата:
Подпрограмма всяко-разно разрывает шампур.
Это неверно.
Вставка (подпрограмма) не может разорвать шампур. Вызов подпрограммы приостанавливает выполнение основной программы, это верно. Но шампур тут ни при чем.

Надо сначала почитать, азы надо знать.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Вторник, 07 Апрель, 2015 14:30 

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

Выкладываю последний и окончательный вариант ИКОН и МАКРОИКОН
предназначенный для издания моей книги на английском языке.

Представленный вариант получен по результатам обсуждения
на этом форуме в период 2008—2015 годы.

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

Представленный вариант (состоящий из 28 икон и 22 макроикон)
был бы невозможен без Ваших советов и критических замечаний.
Еще раз, большое спасибо.

ИКОНЫ
Вложение:
Fig. 17  Icons   Rev2  .png
Fig. 17 Icons Rev2 .png [ 376.25 КБ | Просмотров: 16119 ]


МАКРОИКОНЫ
Вложение:
Fig. 18 Macroicons Rev2 .png
Fig. 18 Macroicons Rev2 .png [ 507.46 КБ | Просмотров: 16119 ]


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2015 15:23 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Паронджанов писал(а):
Уважаемые коллеги!

Выкладываю последний и окончательный вариант ИКОН и МАКРОИКОН
предназначенный для издания моей книги на английском языке.

Представленный вариант получен по результатам обсуждения
на этом форуме в период 2008—2015 годы.
Очень интересная тема - давно хотел ее почитать.
Попутно дополнительно подковался на аглицкий вариант алгоритмической лексики - всем спасибо
(и тем природным англичанам, которые привлекались к тестированию терминологии).

Цитата:
Про concurrent.

Насколько я знаю, параллельный процесс на английский переводится двояко:
— parallel process так я обозначил параллельный процесс реального времени.
— concurrent process так я обозначил "обычный" параллельный процесс, который по Госту 19.701—90 и по ISO 5807-1985.

Отличие от Госта (и ISO) есть, но небольшое.

Есть вопросы и замечания - не поперек, а попутная информация к размышлению.

1. По терминологии - в порядке полезного концептуального занудства.
Термин concurrent process иногда переводится буквально (в транслитерации) как конкурентные процессы:
в смысле конкурирующие параллельные процессы - с конкуренцией за ресурсы и со средствами взаимоисключения
(с понижением степени параллелизма на соответствующих участках общего процесса).
Но в словарном переводе с английского дается однозначное толкование:
Цитата:
concurrent - параллельные;
concurrent [kənˈkʌrənt]
прил.
одновременный, параллельный
(simultaneous, parallel)
concurrent connection – одновременное подключение
concurrent connections – параллельные соединения
А в обратном переводе с русского термин "конкурентный" имеет другой перевод:
Цитата:
конкурентный - competitive:
конкурентный
прил.
1 competitive
(конкурентоспособный)
конкурентное преимущество – competitive advantage
2 competition, competitiveness, competitor
Очевидная нестыковка терминологии (в указанной ранее интерпретации).
Возможно здесь имеет место дрейф этимологии (смыслов исходного происхождения терминов).

Появляются вопросы:
1) Есть ли у кого-то на форуме свои представления
по этой смысловой англо-русской терминологической развилке
в отношении конкурирования и взаимоисключения процессов?
2) Если ли (или предполагается ли) в Драконе средства отображения таких задач?

2. В отношении отображения параллелизма.
Цитата:
Я принял нотацию Степана Борисовича Митькина,
который требует доводить горизонтальные параллели только до вертикали
и запрещает продолжать их "хвосты" за границей вертикали.

Вложение:
ParIcon01.PNG
ParIcon01.PNG [ 49.15 КБ | Просмотров: 16101 ]

Есть вопросы:

1) Почему начало параллельного участка (п. 27) отображается двойной поперечной линией,
а конец параллельного участка (п. 28) отображается одинарной поперечной линией?.
Здесь есть какая-то осмысленная аргументация?
Она где-то обсуждалась и отфиксировалась?

2) Откуда проистекает ограничение?:
запрет на продолжение поперечных "хвостов" за продольные линии потоков.
Строго говоря, быть или не быть (этим хвостам) - это аналогично спору,
как правильно разбивать яйца - с тупого или острого конца (или по середине).
В разных автоматизированных технологиях бывает и так и этак.
В данном случае - это ориентация на конкретные аналоги?
Или как?

--------------------------------------------
Далее приводятся примеры схем с "с хвостами" - какие могут быть по ним возражения?
Вложение:
хвосты01.PNG
хвосты01.PNG [ 44.35 КБ | Просмотров: 16101 ]

Представлен алгоритм пошаговых вычислений по формуле:
y = Sin(x1 + x2) * Cos(x1 +x2).

Параллелизм отражается (примерно) "по Госту 19.701—90 и по ISO 5807-1985".
Это вертикальное (программно-ориентированное) исполнения
с парными поперечными линиями на входе и на выходе параллельного участка.
Чем это плохо?

Вложение:
хвосты02.PNG
хвосты02.PNG [ 42.56 КБ | Просмотров: 16101 ]

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

Вложение:
хвосты03.PNG
хвосты03.PNG [ 84.52 КБ | Просмотров: 16101 ]

Это более точное горизонтальное аппаратно-ориентированное исполнение:
пока немое в смысле узлов логики.
Очевидно происхождение поперечных "хвостов" (или "усов").

Вложение:
хвосты04.PNG
хвосты04.PNG [ 69.66 КБ | Просмотров: 16101 ]

Явная простановка логики узловых элементов - параллельная конъюнкция:
# = R: узел вилки - репитер - множественный повторитель;
o = &: узел сборки - конъюнктор (логическая операция И, And):
контроль окончания всех параллельных потоков,
срабатывание по последнему во времени событию окончания параллельных потоков.

Возможна параллельная дизъюнкция:
полностью аналогичная схема с заменой узла сборки по конъюнкции o = &
на узел сборки по дизъюнкции (Или, Or) o = V.

Вложение:
хвосты05.PNG
хвосты05.PNG [ 55.93 КБ | Просмотров: 16101 ]

Подтверждение пользы поперечных "хвостов" (усов).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 08 Апрель, 2015 23:15 

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

Икона "Формальные параметры" раньше вроде бы имела прямые углы, а теперь скруглённые.

С чем связаны изменения?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2015 00:23 

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

А так красивше : )
Вложение:
pp.png
pp.png [ 70.06 КБ | Просмотров: 16076 ]

Что-то было здесь.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2015 09:47 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
andr писал(а):
Владимир Паронджанов писал(а):

Про concurrent.

Насколько я знаю, параллельный процесс на английский переводится двояко:
— parallel process так я обозначил параллельный процесс реального времени.
— concurrent process так я обозначил "обычный" параллельный процесс, который по Госту 19.701—90 и по ISO 5807-1985.

Отличие от Госта (и ISO) есть, но небольшое.

Есть вопросы и замечания - не поперек, а попутная информация к размышлению.

1. По терминологии - в порядке полезного концептуального занудства.
Термин concurrent process иногда переводится буквально (в транслитерации) как конкурентные процессы:
в смысле конкурирующие параллельные процессы - с конкуренцией за ресурсы и со средствами взаимоисключения
(с понижением степени параллелизма на соответствующих участках общего процесса).
Но в словарном переводе с английского дается однозначное толкование:
Цитата:
concurrent - параллельные;
concurrent [kənˈkʌrənt]
прил.
одновременный, параллельный
(simultaneous, parallel)
concurrent connection – одновременное подключение
concurrent connections – параллельные соединения
А в обратном переводе с русского термин "конкурентный" имеет другой перевод:
Цитата:
конкурентный - competitive:
конкурентный
прил.
1 competitive
(конкурентоспособный)
конкурентное преимущество – competitive advantage
2 competition, competitiveness, competitor
Очевидная нестыковка терминологии (в указанной ранее интерпретации).
Возможно здесь имеет место дрейф этимологии (смыслов исходного происхождения терминов).

Появляются вопросы:
1) Есть ли у кого-то на форуме свои представления
по этой смысловой англо-русской терминологической развилке
в отношении конкурирования и взаимоисключения процессов?
2) Если ли (или предполагается ли) в Драконе средства отображения таких задач?

Вернемся к нашим concurrent process - параллельным процессам:
кому это интересно - копаться в изначальных смыслах терминологии.

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

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

-------------------------------------------------
1. Вопрос на засыпку №1:
что значит геометрическая метафора (аналогия) "параллельные" для процессов (???-01).

В геометрии "параллельные" для линий в пространстве:
это означает "рядом идущие" линии - без пересечения.
Это исходный визуальный образ.

В схемотехнике "параллельное соединение" элементов (резисторов, емкостей и т.п.):
явно отображается на принципиальных схемах параллельными линиями - со вставками УГО (и с поперечными соединениями).
Аналогия принципиальных схем понятна, хотя на монтажных схемах (и в натуре) явного визуального параллелизма может не быть.

В алгоритмике и программировании параллельные процессы отображаются
параллельными отрезками прямых линий на временных диаграммах разных типов.
Например:
Вложение:
хвосты04.PNG
хвосты04.PNG [ 69.66 КБ | Просмотров: 16054 ]

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

Итак - все это очень хорошо и наглядно.
Но это только смысловая метафора - аналогия.
Но аналогичный по смыслу - это еще не значит тождественный по смыслу.

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

--------------------------------------------------
Вопрос на засыпку № 2:
что значит английский термин "concurrent" для процессов (???-02).

Термин "current" означает: текущий - протекающий в пространстве или происходящий в настоящее время (это прилагательное),
а также - поток, струя и т.п. (существительное).

Термин "concurrent" означает одновременный, параллельный (во времени).
То есть - это, примерно как, процесс , совместно (con...) протекающий (...current) во времени, одновременно выполняемый:
процесс, выполняемый одновременно с некоторым другими процессами.

Термин "concurrent" для процессов - это первичный и более точный по смыслу, чем термин "parallel".

Основной смысл параллелизма процессов - это их совмещение во времени.
Точнее:
это совмещение интервалов времени их выполнения:
визуально представляется пересечением (проекций) интервалов некоторых отрезков на временных диаграммах (рис. 3.5).

То есть основной смысл параллелизма процессов - это их одновременность .
А точнее - это их совмещение во времени.
А еще точнее - это пресечение интервалов времени их выполнения.

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

---------------------------------------
Параллельные процессы могут быть:

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

2) Взаимодействующие (interactive, cooperative) на интервалах времени их выполнения:
-- здесь (бесконечно?) много разных видов взаимодействия:
обмен внутренними событиями, конкуренция за доступ к общим (разделяемым) ресурсам и т.п.;
-- здесь (бесконечно?) много разных вопросов на засыпку:
в частности, непонятки с русским термином "конкурентный" в смысле состязаний за что-то,
которому соответствует английский термин "competitive".
Все это, наверное, будет актуально уже для последующих изданий дракон-технологий.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 09 Апрель, 2015 10:21 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
Ильченко Эдуард писал(а):
2 Владимир Паронджанов

Икона "Формальные параметры" раньше вроде бы имела прямые углы, а теперь скруглённые.

С чем связаны изменения?


Вы правы. Прямые углы заменены на скругленные.

Почему? Причин несколько

1. Чтобы показать "Исполнителя" или его аналоги.
download/file.php?id=2757&mode=view
См пример здесь

2. Ввести правило: "Икона, присоединяемая справа, имеет особую форму, отличную от иконы "действие" — прямоугольник с закругленными углами.

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

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

Я исхожу из того, что слово "исполнитель" надо переводить на английский как actor.

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

Проблему исполнителя — actor я считаю открытой в том смысле, что исполнителя можно показывать двумя разными графическими средствами:

— прямоугольник со скругленными краями, присоединяемый справа;

— на верхнем этаже иконы "полка".


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

Зарегистрирован: Четверг, 10 Январь, 2013 16:59
Сообщения: 70
Владимир Паронджанов писал(а):
__1__ писал(а):
1) Не понятно, чем отличаются параллельные действия от параллельных процессов?

Читать надо здесь: см. глава 13 и 14
http://drakon.su/_media/biblioteka_1/01 ... linnik.pdf

Просмотрел. Не понравилось!
— Треугольником обозначать слияние параллельных потоков – это тройная ошибка:
    1) нет возможности обозначить логику такого слияния
    2) отсутствует инверсный выход (на случай, если нужно обработать отрицательный результат (от противного).
    3) появился новый элемент: треугольник. А ведь достаточно было всё той же иконки: Проверка условия (развилка).
Вот, здесь Вы почти правильно нарисовали. На том рисунке метками можно было бы обозначить дополнительные потоки, входящие в логический элемент. Но меток в ДРАКОНе пока нет…. ;)

--

Теперь понял различие между параллельными действиями и параллельными процессами.
    • Параллельный процесс это: «А чёрт его знает, кто его запустил! Может быть, я? Не помню!»
    • Параллельные действия – это начало параллельных процессов (синхронно активируются из одного потока)
Управление параллельным процессом осуществляется при помощи меток, активируемых извне (из других алгоритмов или из родительских программ). Метки активируют параллельные потоки, которые сходятся в логических элементах (или в логических силуэтах).
Это управление осуществляется из стороннего алгоритма, при помощи параллельных действий (и при помощи ссылок на метку).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2015 08:35 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
В продолжение начатого разговора по Cocurret prosess (параллельные процессы).
Есть персональный интерес - в разных отношениях.
В частности - с позиции потенциального заказчика графической алгоритмической системы:
в приложении к Образовательной робототехнике (ОРТ), в частности.

Ильченко Эдуард писал(а):
andr писал(а):
1) Почему начало параллельного участка (п. 27) отображается двойной поперечной линией,
а конец параллельного участка (п. 28) отображается одинарной поперечной линией?.
Здесь есть какая-то осмысленная аргументация?
Она где-то обсуждалась и отфиксировалась?
А так красивше : )
Вложение:
pp.png

------------------------------------------
На схеме надо поменять местами аббревиатуры блоков:
ВСн (Вычислить синус) и ВКс (Вычислить косинус).
Это и у меня на моих блок-схемах - надо будет исправить в своем файле оригинала.
Но суть не в этом.

--------------------------------------------
Вспоминаются прежние труды за кульманами в разных КБ
(это было давно - в пролом веке, еще до персональных компьютеров).
Смотришь на свои чертежи - ужасно нравятся.
А смотришь у соседа - так себе.

1) Отчасти, как я понимал - это какая-то эгоцентрическая психология - субъективизм.
2) Но отчасти - я использовал элементы дизайна и эргономики
(еще преподаватели в чем-то воспитывали, что-то читал на дипломе и т.п.):
специально старался, чтобы красивше.
3) Отчасти - хорошо проектировал, решал реальные проектные задачи на хорошем теоретическом уровне
(а мои соседи часто были практики или заочники:
делали все быстро, но на глаз, местами гляделось довольно коряво (с моей точки зрения),
и у них бывали рекламации из цехов, а у меня не было).

Это все к чему?
А как понимать в отношении, чтобы было красивше в редакторе Дракон:
1-е), 2-е) или 3-е) или еще что-то?

Ильченко Эдуард писал(а):
Что-то было здесь.

Полезно обсудить визуализацию элементов типа:
==== писал(а):
Владимир Паронджанов писал(а):
По моему мнению, следует различать три точки fork, join, merge.

Эти три точки должны иметь разные графические обозначения:

1. fork — означает начало параллельных процессов. Изображается как двойная горизонтальная линия.
...

Непонятные объекты, это точки или линии?

fork, join, merge - использованы иностранные слова и не русский алфавит, это противоречит по определению аббревиатуре ДРАКОН и ее расшифровке (. Русский . язык ...) и стране происхождения.

Продолжение следует


Последний раз редактировалось andr Пятница, 10 Апрель, 2015 09:00, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2015 08:45 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
andr писал(а):
В продолжение начатого разговора по Cocurret prosess (параллельные процессы).
Есть персональный интерес - в разных отношениях.
В частности - с позиции потенциального заказчика графической алгоритмической системы:
в приложении к Образовательной робототехнике (ОРТ), в частности.

...................

Полезно обсудить визуализацию элементов типа:
==== писал(а):
Владимир Паронджанов писал(а):
По моему мнению, следует различать три точки fork, join, merge.

Эти три точки должны иметь разные графические обозначения:

1. fork — означает начало параллельных процессов. Изображается как двойная горизонтальная линия.
...

Непонятные объекты, это точки или линии?

fork, join, merge - использованы иностранные слова и не русский алфавит, это противоречит по определению аббревиатуре ДРАКОН и ее расшифровке (. Русский . язык ...) и стране происхождения.

Продолжение следует

Общая ситуация с параллельными (и последовательными) алгоритмами такая:
Вложение:
ЛВИ 01.PNG
ЛВИ 01.PNG [ 57.5 КБ | Просмотров: 15989 ]

Выделяются 3 уровня отражения (и понимания)
логики механизмов управления параллельными (и последовательными) процессами во времени:
или логико-временная интерпретация параллельных (и последовательных) алгоритмов
Цитата:
1) Уровни логико-временной интерпретации – уровни понимания, объяснения и отражения логико-временной сущности параллельной алгоритмики:
1.1) Практическая логика здравого (интуитивного) смысла.
1.2) Явная структурная логика параллельных алгоритмов.
1.3) Явная структурно-функциональная логика.

Далее эти три уровни будут кратко изложения по отдельности (чтобы не перегружать сообщения)

Продолжения следует 2


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2015 10:47 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
andr писал(а):
Продолжения следует 2

3.2.1 Практическая логика здравого (интуитивного) смысла

Вложение:
ЛВИ 02.PNG

И далее по п. 3.2.1
Цитата:
Характерная особенность: имеют место
"немые" (не обозначенные аналитически) узловые структурные элементы и
"немые" связи рабочих операторов без указания обозначений для (сигналов) передачи управления между ними.

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

На этом уровне структура параллельных алгоритмов обсуждается на уровне терминов типа:
-- fork (вилка) - узел разделения (дивергенции) потоков управления;
-- join (сборка) - узел соединения (конвергенции) потоков управления.

Особое место занимает узел типа merge - тоже сборка или слияние потоков.
На данном исходном уровне логики понимания и объяснения она оправдана,
но в последующем она будет излишняя (лишняя путаница смыслов).

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

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

Можно пытаться навязывать всем какую-то одну "самую правильную" систему начертаний.
Но тогда заведомо будет сужаться круг потенциальных пользователей - по разным причинам, начиная с мелочевки.

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

1) Графическая система должна вписываться в идеологию полиморфной системы алгоритмических языков, включая:

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

-- структурные и функциональные (структурно-функциональные) схемы алгоритмов:
блок-схемы, штрих-схемы, граф-схемы и т.п.;
вертикального и горизонтального исполнения;
прямая и обратная запись схем (вспомогательная форма) и т.д. - по разным нюансам;

-- псевдокоды алгоритмов - промежуточная форма связи с языками программирования:
алгол-подобные, паскаль-подобные, си-подобные формы и т.д.;

-- табличные и матричные формы представления алгоритмов.

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

------------------------------------------------------
Кажется все это слишком сложно.
Но реально - если долго мучиться.
И кое-какие аванпроектные наработки (прикидки) есть - по линии учебного процесса
(это не законченные разработки на распространение).
Но это все, в принципе, вполне реально.

Это отголоски планов разработки подсистемы алгоритмического обеспечения для САПР робототехнологических систем.
К сожалению реальные робототехнические работы "грохнулись" где-то в 1987 г. - по понятным причинам.
Но теперь все снова вокруг оживает - и в новых формах и перспективах.
И лидирует у нас по массовости что?:
детская образовательная робототехника.

------------------------------------------------------------

Продолжение следует 3


Последний раз редактировалось andr Пятница, 10 Апрель, 2015 12:40, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 10 Апрель, 2015 12:18 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Ошибочка вышла.
andr писал(а):
andr писал(а):
В продолжение начатого разговора по Cocurret prosess (параллельные процессы).

Нужно, козе понятно, Concurrent processes - молотил вслепую в тексте мелким шрифтом.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 12 Апрель, 2015 10:27 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5846
Откуда: Москва
andr писал(а):
Полезно обсудить визуализацию элементов типа:
Владимир Паронджанов писал(а):
По моему мнению, следует различать три точки fork, join, merge.


Эта терминология взята из UML. Заимствованы термины, но не графические обозначения.
См. здесь


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 13 Апрель, 2015 08:24 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
andr писал(а):
Продолжение следует 3


Владимир Паронджанов писал(а):
andr писал(а):
Полезно обсудить визуализацию элементов типа:
Владимир Паронджанов писал(а):
По моему мнению, следует различать три точки fork, join, merge.

Эта терминология взята из UML. Заимствованы термины, но не графические обозначения.
См. здесь


Большое спасибо - хорошая сводная схема:
Вложение:
Узлы 01.PNG
Узлы 01.PNG [ 102.31 КБ | Просмотров: 15876 ]

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

Здесь кроме узлов fork (вилка), join (сборка) - для двухстороннего параллельного объединения,
и узла merge (слияние) есть парный ему узел desision (решатель) - для простого (бинарного) ветвления:
замкнутого альтернативного ветвления - ветвления на узле desision с замыканием на узле merge .

-------------------------------
Истолкование работы таких схем соответствует предложенному выше
1-му уровню логико-временной интерпретации:
andr писал(а):
andr писал(а):
Продолжения следует 2

3.2.1 Практическая логика здравого (интуитивного) смысла


На следующем 2-м уровне (1.2):
1.2) Явная структурная логика параллельных алгоритмов
общей системы уровней:
Цитата:
1) Уровни логико-временной интерпретации – уровни понимания, объяснения и отражения логико-временной сущности параллельной алгоритмики:
1.1) Практическая логика здравого (интуитивного) смысла.
1.2) Явная структурная логика параллельных алгоритмов.
1.3) Явная структурно-функциональная логика.

начнет выясняться более глубокая логическая природа этих узлов.

Вкратце, получается такая общая система представлений:

1) Параллельная сборка join - это сборка по конъюнкции (логической операции And, И), то есть:
join_and, join_& или просто and = & (но это нужно обосновать);
сборка_и, сборка_& или просто и = &.

2) Если есть параллельная сборка join_and, сборка_и по конъюнкции,
то должна быть и параллельная сборка join по дизъюнкции (логической операции Or, Или), то есть:
join_or, join_V или просто or = V (но это тоже нужно обосновать);
сборка_или, сборка_V или просто или = V.

3) Параллельная вилка fork - это множественный повторитель # = R.
В паре со сборкой он дает парную структурную операцию параллели (операторов) || = #o.
Традиционно это параллельная конъюнкция || = #& (типа ||_&)
Ей противопоставляет параллельная дизъюнкция || = #V (типа ||_V) .

4) Внутри узла решателя desision выявляется узел вилки fork (# = R).

5) Узел слияния merge - это не что иное как узел дизъюнкции V потоков управления:
узел сборки по дизъюнкции (Or. Или).

--------------------------------------
Таким образом, картина усложняется
и желательно заранее - еще на первом уровне интерпретации
согласовать терминологию (с будущим) вторым уровнем интерпретации.

-----------------------------------------
Продолжение следует 4
(Явная структурная логика параллельных алгоритмов).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 15 Апрель, 2015 08:03 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
andr писал(а):
Продолжение следует 4
(Явная структурная логика параллельных алгоритмов).

Второй уровень логико-временной алгоритмов интерпретации алгоритмов в общей системе:
Цитата:
1) Уровни логико-временной интерпретации – уровни понимания, объяснения и отражения логико-временной сущности параллельной алгоритмики:
1.1) Практическая логика здравого (интуитивного) смысла.
1.2) Явная структурная логика параллельных алгоритмов.
1.3) Явная структурно-функциональная логика.


------------------------------------------------------------------
Для параллельных структур алгоритмов
(базового структурного типа - последовательно-параллельные связи двухполюсников)
Вложение:
ЛВИ 03.PNG
ЛВИ 03.PNG [ 94.51 КБ | Просмотров: 15832 ]

И далее:
Вложение:
ЛВИ 04.PNG
ЛВИ 04.PNG [ 65.26 КБ | Просмотров: 15832 ]

И далее:
Цитата:
Текущие условия
На данном уровне интерпретации логики параллелизма ситуация принципиально улучшается. Это включает следующие обстоятельства:
1) Проясняется, в принципе, характер структурной операции параллели как парной операции. Более понятной, в принципе, становится логика составляющих ее операций (при соответствующих практических пояснениях). Далее такие структуры именуются как параллельная конъюнкция алгоритмов || = #&.
2) Обнаружение параллельной конъюнкции ставит вопрос о возможности или невозможности параллельной дизъюнкции алгоритмов || = #V. Это относительно новая и мало разработанная сущность в параллельной алгоритмике и пока является проблемной. В статье [4] для представленного выше примера показана специфика, принципиальная возможность и полезность ее использования для вариантов частичной реализации (потенциального) параллелизма.
3) Пока не ясно следующее обстоятельство. Конъюнктивная и дизъюнктивная логика параллельного соединения алгоритмов – это действительно логические операции конъюнкции и дизъюнкции? Или это не очень понятные алгоритмические метафоры (аналогии)? Тем не менее, на интуитивном уровне можно дать подтверждение наличия таких функций. Намечается возможность привлечения булевой алгебры для базовых параллельных структур. При этом:
• с одной стороны, пока это усеченная без-инверсная булева алгебра – пока не выявляется структурная операция инверсии, то есть отрицания Не (Not):
это упрощает проблему на текущем уровне интерпретации;
• с другой стороны, есть структурная операция секвенции (последовательной связи операторов), которая не включается (в традиционную) булеву алгебру:
это осложняет проблему, поскольку бесконтрольное (по смыслу) формальное применение булевой алгебры может приводить здесь к ошибкам и нелепостям.
4) Таким образом, в этой области точно выявляется фактор неопределенности (неясности) по существу вопроса логико-временной интерпретации. Причем любые даже самые строгие аксиоматизированные теории параллельной алгоритмики на данном (2-м) уровне логико-временной интерпретации параллельных алгоритмов (без выхода на следующий 3-й уровень) фактически содержат это внутренний фактор неопределенности. Подобные ситуации неопре-деленности (индефинитики [5]) вообще характерны для научных теорий.
5) Однако, это обстоятельство не является непреодолимым препятствием для применения достаточно приемлемых практических и формализованных подходов (с корректным учетом областей и условий их применимости). Здесь есть аналогия с физикой – многие физические сущности можно измерять и строить на этом их теории, хотя не понятно, что это такое (например, энергия).
6) Кратко изложенные выше постановочные вопросы 2-го уровня существенно продвигают структурную параллельную алгоритмику опорных базовых структур. В частности:
существенно повышают точность, логичность и степень понимания структурного описания параллельных алгоритмов посредством одномерных и, особенно, двухмерных структурных формул.

И далее:
Цитата:
Двухмерные структурные формулы алгоритмов
Двухмерные структурные формулы (СФА/ДМ) базовых структур параллельных алгоритмов приведенного выше типа (Табл. 3.1) строго выводятся из исходных одномерных структурных формул. При этом, в частности:
1) ДМ СФА могут быть преобразованы в псевдографику структурных схем (ССА/ПГ), и сами они могут интерпретироваться как особая компактная схемная псевдографика. Такая псевдографика (для достаточно простых схем) может использоваться для схемных построений в текстовых редакторах. В частности – в листингах исходных кодов программ (в комментариях):
это применяется автором в лабораторных работах по многопоточной программной реализации моделей параллельных систем.
2) Все это является основой автоматизации схемных построений базовых параллельных структур (Рис. 3.4) и временных диаграмм (Рис. 3.5).
3) На этом уровне закладывается связная аналитическая (посредством СФА) и визуальная (посредством ССА) простая первичная базовая грамматика алгоритмических языков:
в принципе она понятна (в общих чертах) на приведенных примерах структурных формул и их описания (на лабораторных занятиях изучается ее синтаксис).


---------------------------------------
Для последовательных структур алгоритмов.
Этот вопрос до конца не разработан.
Далее приводится следующие сведения:
Вложение:
ЛВИ 05.PNG
ЛВИ 05.PNG [ 74.86 КБ | Просмотров: 15832 ]

И далее:
Вложение:
ЛВИ 06.PNG
ЛВИ 06.PNG [ 58.71 КБ | Просмотров: 15832 ]

Крестиком обозначаются узлы альтернативного ветвления - решатели (decision),
соответствующие поперечным ромбам на блок-схемах.

Маленьким кружком обозначен дизъюнктивный узел узел сборки потоков управkения
(по логической функции Или, Or) - фактически join_or:
соответствует термину merge - слияние в некоторых графических языках.

=============================
Здесь используются структурные схемы алгоритмов (ССА) типа штрих-схем (ССА = ШСА)
в данном случае - это литерная псевдографика:

-- операторы обозначаются короткими поперечными отрезками - штрихами:
соответствуют прямоугольным блокам на блок-схемах алгоритмов (ССА = БСА);

-- узлы (бинарного) альтернативного ветвления обозначаются крестиком (повернутым на 45 град.).

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

Нет ли у кого-нибудь сведений по этой книге?
Есть подозрения, что такие схемы были в каких-то немецких стандартах по схемам алгоритмов и программ.
Пока не нашел, хотя активно не искал.


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

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


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

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


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

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