DRAKON.SU

Текущее время: Четверг, 24 Июнь, 2021 14:30

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




Начать новую тему Ответить на тему  [ Сообщений: 49 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
СообщениеДобавлено: Четверг, 01 Октябрь, 2015 06:50 

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

Построение такого редактора запланировано в проекте по технологии автоматного программирования. Обсуждается также возможность разработки подобного редактора для языка Модула-2. В обоих случаях для графического представления предполагается использовать язык Дракон.

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

Есть такие вопросы:
1) Предусматривается ли схемная и текстовая реализация параллельных алгоритмов?
2) Если да, то:

2.1) Какие автоматные модели предполагаются?:
2.1.1) Насколько я себе представляю:
а) в автоматном программировании используются обычные (последовательные) конечные автоматы?
б) можно ли их использовать для программной реализации параллельных алгоритмов?
2.1.2) Кажется естественным использование параллельных конечных автоматов
(коллективы автоматов и т.п.):
-- однако там появляются навороты - вложенные комбинаций состояний и т.п.:
я кроме учебных описаний идеи параллельных конечных автоматов не встречал их практического применения
(хотя особенно и не искал, но за большое время должен был бы, наверное, "наткнуться");
-- есть ли у Вас какая-то информация по практическому использованию
параллельных конечных автоматов
(в автоматном программировании или в других парадигмах)?

2.2) Достаточны ли для этого параллельные средства языка Модула-2.

2.3) Хотя, в принципе, для этого не обязательными являются специальные параллельные программные средства:
при циклических прогонах автоматных моделей
можно условно параллельно гонять (на одном процессоре, на одном ядре) несколько независимых и взаимодействующих последовательных автоматов (какая-то форма псевдопараллелизма)?

2.4) Какого типа прикладные задачи предполагается решать (программировать)?




===============================================
Кстати, поискал и инете - сподобился, наконец:
В Яндексе:
Вложение:
ПарКА-01.PNG
ПарКА-01.PNG [ 58.47 КБ | Просмотров: 14039 ]

В Гугле:
Вложение:
ПарКА-02.PNG
ПарКА-02.PNG [ 59.16 КБ | Просмотров: 14039 ]

В Бинге:
Вложение:
ПарКА-03.PNG
ПарКА-03.PNG [ 40.98 КБ | Просмотров: 14039 ]

Не густо.
Тем лучше для начала.

===============================================
В мэйле.ру
Вложение:
ПарКА-04.PNG
ПарКА-04.PNG [ 65.13 КБ | Просмотров: 14039 ]

Но надо разбираться.
Странное несопоставимое соотношение списков в разных поисковиках.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Октябрь, 2015 09:44 

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1176
http://forum.oberoncore.ru/viewtopic.php?p=93164#p93164
Владимир Шелехов писал(а):
Технология автоматного программирования: http://persons.iis.nsk.su/files/persons/pages/req_tech.pdf
базируется на использовании языка спецификации требований.
Спецификация на этом языке легко транслируется в автоматную программу.
Где и как можно получить среду разработки, компиляции в этом языке?
Какое название имеет язык?
Где описание языка?


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Октябрь, 2015 15:29 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
andr писал(а):
Есть такие вопросы:
1) Предусматривается ли схемная и текстовая реализация параллельных алгоритмов?
2) Если да, то:
2.1) Какие автоматные модели предполагаются?:
2.1.1) Насколько я себе представляю:
а) в автоматном программировании используются обычные (последовательные) конечные автоматы?
б) можно ли их использовать для программной реализации параллельных алгоритмов?


В автоматном программировании параллельная композиция двух программ U и S
записывается в виде U || S.
Каждая программа представлена своим автоматом, имеет свое локальное состояние
и является независимой дракон-программой.
Параллельная композиция может иметь свое состояние --
его переменные являются разделяемыми для двух программ U и S.
Взаимодействие между U и S реализуется также через прием/передачу сообщений.

Каждая из программ U и S является последовательной.
При этом возможен недетерминированный и даже вероятностный выбор.
Параллелизм вида образование параллельных ветвей и затем их слияние,
как например в программе "Последний этап в строительстве дома" в книге В.Д. Паронджанова,
в принципе возможен, но встречается крайне редко.

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

Цитата:
-- есть ли у Вас какая-то информация по практическому использованию
параллельных конечных автоматов
(в автоматном программировании или в других парадигмах)?

Параллельная композиция автоматных программ используется в протоколах.
См. раздел 9, стр.21 в мое статье
http://persons.iis.nsk.su/files/persons ... q_tech.pdf

Есть американский стандарт TCAS III по противодействию столкновениям самолетов в авионике.
См. например, http://www.faa.gov/documentLibrary/medi ... ooklet.pdf,
http://sunnyday.mit.edu/papers/tcas-tse.pdf
или сам стандарт.
Там параллелизма выше крыши.

Цитата:
Кстати, поискал и инете - сподобился, наконец:
В Яндексе:
В Гугле:
В Бинге:
Не густо.
В мэйле.ру
Но надо разбираться.
Странное несопоставимое соотношение списков в разных поисковиках.


Тут ничего интересного. Все мимо.
Не то ищете. Термина "параллельный конечный автомат" нет в природе.
Во первых, искать надо на английском: concurrent state machine.
Там невод уже не пустой.
Но сплошная глупость.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 02 Октябрь, 2015 16:01 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
LKom писал(а):
http://forum.oberoncore.ru/viewtopic.php?p=93164#p93164
Владимир Шелехов писал(а):
Технология автоматного программирования: http://persons.iis.nsk.su/files/persons/pages/req_tech.pdf
базируется на использовании языка спецификации требований.
Спецификация на этом языке легко транслируется в автоматную программу.
Где и как можно получить среду разработки, компиляции в этом языке?


Среда в процессе разработке,
для производственной эксплуатации появится не скоро.

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

Далее вручную транслируете формальные требования в автоматную программу.
Наконец, кодируете автоматную программу на целевом языке программирования.

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

Цитата:
Какое название имеет язык?
Где описание языка?


Язык предикатного программирования P.
Есть экспериментальная система предикатного программирования.
Используется как полигон для студенческих работ.
Сейчас в разобранном состоянии.
Описание языка: http://persons.iis.nsk.su/files/persons ... lang12.pdf
Раздел 10.Процессы
Однако там не отражены последние изменения в языке, представленные в статье


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

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1176
Цитата:
[1] Шелехов В.И. Введение в предикатное программирование. - Новосибирск, 2002. - 82с. - (Препр. / ИСИ СО РАН; N 100).

Разработка языка P и его реализация является вялотекущим процессом.
Получается некая песочница для студентов - "Пойдите поиграйтесь.", выпустили из вуза, а в жизни отсутствует.
Это же сколько выпусков студентов поигрались в песочнице, потратили время и не получили реальный инструмент?

Подобная песочница организовалась и у TAU в 2-х вузах Самары, предлагается поиграть Драконом в Drakon Editor, ИС Дракон и Фабула, а выбор инструмента для работы и его освоение отсутствует.

Язык без реализации остается мертвым языком. Так у В. Паронджанова, более 10 лет до появления ИС Дракон в 2008 г., Дракон был мертвым языком.

---

Смотрите - http://forum.oberoncore.ru/viewtopic.php?p=85139#p85139 .


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

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Шелехов писал(а):
andr писал(а):
Есть такие вопросы:
1) Предусматривается ли схемная и текстовая реализация параллельных алгоритмов?
2) Если да, то:
2.1) Какие автоматные модели предполагаются?:
2.1.1) Насколько я себе представляю:
а) в автоматном программировании используются обычные (последовательные) конечные автоматы?
б) можно ли их использовать для программной реализации параллельных алгоритмов?

В автоматном программировании параллельная композиция двух программ U и S
записывается в виде U || S.
Каждая программа представлена своим автоматом, имеет свое локальное состояние
и является независимой дракон-программой.
Параллельная композиция может иметь свое состояние --
его переменные являются разделяемыми для двух программ U и S.
Взаимодействие между U и S реализуется также через прием/передачу сообщений.

Каждая из программ U и S является последовательной.
При этом возможен недетерминированный и даже вероятностный выбор.
Параллелизм вида образование параллельных ветвей и затем их слияние,
как например в программе "Последний этап в строительстве дома" в книге В.Д. Паронджанова,
в принципе возможен, но встречается крайне редко.

Выражение типа U || S для конечных автоматов - это очень интересно.
Обычно, когда рассматриваются соединения автоматов - последовательное, параллельное, с обратной связью, сети автоматов и т.п. эти образования представляются:
1) некоторой общей схемой системы автоматов, вполне ясной и понятной ;
2) множеством формул типа:
КА - это комплект (пятерка, шестерка и т.п.) компонент S = (A, B, C, D, E) - списком через запятую;
2) Множеством таблиц состояний и переходов.
Причем появляются вложенные формулы компонент и т.п. - достаточно громоздкие головоломки:
информация к размышлению на каждом шагу.
Связных аналитических выражений для соединений автоматов я никогда не видел,
но допускаю, что не очень ориентируюсь в этом.

Тем не менее до сих пор не "натыкался".
А здесь вдруг "наткнулся", наконец-то: U || S.
Это конечно само по по себе еще элементарная "мелочевка", но как говорится с большими последствиями малых причин.

Появляются такие вопросы:
1) Это просто пример условных обозначений для разных способов соединений автоматов?
2) Или существуют способы связного аналитического описания разных составных комбинаций автоматов:
типа какая-то общая формула системы автоматов?
3) Где можно посмотреть такие аналитические описания автоматов?

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

Владимир Шелехов писал(а):
Цитата:
-- есть ли у Вас какая-то информация по практическому использованию
параллельных конечных автоматов
(в автоматном программировании или в других парадигмах)?

Параллельная композиция автоматных программ используется в протоколах.
См. раздел 9, стр.21 в мое статье
http://persons.iis.nsk.su/files/persons ... q_tech.pdf

Есть американский стандарт TCAS III по противодействию столкновениям самолетов в авионике.
См. например, http://www.faa.gov/documentLibrary/medi ... ooklet.pdf,
http://sunnyday.mit.edu/papers/tcas-tse.pdf
или сам стандарт.
Там параллелизма выше крыши.
Большое спасибо за такую наводку.
С интересом покопаюсь при возможности.

Владимир Шелехов писал(а):
Цитата:
Кстати, поискал и инете - сподобился, наконец:
В Яндексе:
В Гугле:
В Бинге:
Не густо.
В мэйле.ру
Но надо разбираться.
Странное несопоставимое соотношение списков в разных поисковиках.

Тут ничего интересного. Все мимо.
Не то ищете. Термина "параллельный конечный автомат" нет в природе.
Во первых, искать надо на английском: concurrent state machine.
Там невод уже не пустой.
Но сплошная глупость.

Но "параллельный конечный автомат" и "concurrent state machine" - это взаимная (почти) калька терминов.
Вложение:
ПарКА-01.PNG
ПарКА-01.PNG [ 49.98 КБ | Просмотров: 13961 ]

Переводчик автоматно неграмотный, конечно, но суть дела понятна.

"Параллельный конечный автомат" - термин, мне кажется, не я придумал, он у меня давно значится в наличии.
Просто он довольно редкий.
И в приведенных выше выборках поисковиков он существует - мало, но тем не менее есть.
Цитата:
Но сплошная глупость
Это хороший ориентир в проблематике. Еще раз большое спасибо.


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

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
andr писал(а):
Тем не менее до сих пор не "натыкался".
А здесь вдруг "наткнулся", наконец-то: U || S.
Это конечно само по по себе еще элементарная "мелочевка", но как говорится с большими последствиями малых причин.

Появляются такие вопросы:
1) Это просто пример условных обозначений для разных способов соединений автоматов?
2) Или существуют способы связного аналитического описания разных составных комбинаций автоматов:
типа какая-то общая формула системы автоматов?
3) Где можно посмотреть такие аналитические описания автоматов?


Есть такая проблематика в Computer Science -- алгебры процессов:

CCS - Милнера,
CSP - Хоара,
ATP,
пи-исчисление, .....
и очень много высокой науки.


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

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Шелехов писал(а):
andr писал(а):
Тем не менее до сих пор не "натыкался".
А здесь вдруг "наткнулся", наконец-то: U || S.
Это конечно само по по себе еще элементарная "мелочевка", но как говорится с большими последствиями малых причин.

Появляются такие вопросы:
1) Это просто пример условных обозначений для разных способов соединений автоматов?
2) Или существуют способы связного аналитического описания разных составных комбинаций автоматов:
типа какая-то общая формула системы автоматов?
3) Где можно посмотреть такие аналитические описания автоматов?


Есть такая проблематика в Computer Science -- алгебры процессов:

CCS - Милнера,
CSP - Хоара,
ATP,
пи-исчисление, .....
и очень много высокой науки.

Большое спасибо за эту подборку.
Есть повод прочесать это - по современному состоянию вопроса.

-------------------------------
Но я немного, может быть, неточно выразился.
Я имел в виду компактную символьную алгебру параллельных конечных автоматов (concurrent finit state machines):
компактную, по крайней мере, для простых первичных параллельных конфигураций
(без громоздких наворотов).

Как, например простой параллельный алгоритм - поток управления:

A100 = (Z0->(Z1 || Z2)->Z3) = Z0-(Z1 || Z2)-Z3 = Z0(Z1 || Z2)Z3

Это имеет признак ДП: ДитЯм Понятно.

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

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

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

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

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

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

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

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

Но, в целом, по этому направлению, мы многое заимствовали и адаптировали,
в частности, и у Хоара - с полной нашей почтительной благодарностью.
А теперь потянуло прочесать этот список - по современному состоянию.
Большое Вам спасибо за творческий пинок.

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

Реальная робототехника начинает проклевывать у нас (причем в новом качестве).
Особенно военная (они готовы финансировать, но требуют сначала показывать готовые экспериментальные образцы).
А вот более доступная у нас сейчас - массовая детская, но реально функционирующая робототехника.
Впадаем в детство - и вперед.
И здесь есть перспективы (и, главное, объективная необходимость)
подвести под нее полноценные и практически полезные
основы прикладной (структурной) теории параллельных алгоритмов.

----------------------
В этом отношении меня несколько резанула фраза:
очень много высокой науки.
Есть информация к трезвому размышлению:
в смысле массового конечного практического применения.
Ключевой фактор массовости:
как например, булева алгебра и комбинационные логические схемы.
Сейчас - это ДП, а раньше это было немыслимо.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Октябрь, 2015 20:42 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5179
Откуда: Москва
В сообщении viewtopic.php?p=93164#p93164 Владимир Иванович Шелехов из Института систем информатики имени А. П. Ершова Сибирского отделения РАН писал(а):
Я же из другого мира -- мира программистов, работающих в текстовых языках программирования.
Мои проблемы в указанной выше архитектуре не решаются.
....................................................
Учитывая это, было решено разработать инструмент,
визуализирующий автоматную программу в виде дракон-схемы.
Графическая визуализация автоматной программы безусловно будет полезной.

Почему выбор пал на язык Дракон?
Автоматная программа является машиной конечных состояний в виде гиперграфа.
Оказалось, что среди всех доступных графических языков программирования Дракон является единственным,
в котором адекватно решается проблема отрисовки дуг гиперграфа. Это структура "силуэт".

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

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

Владимир Иванович, я полностью с Вами согласен. Биполярность очень нужна.
Степан Митькин с Вами уже согласился.

Участник adva тоже Вас поддерживает в косвенной форме. Цитирую
В сообщении viewtopic.php?p=93519#p93519 участник adva писал(а):
нужна...методология, как и в каких случаях использовать дракон в разработке, чтобы получить преимущества.

Я, например, использую его очень и очень мало, хотя и хотелось бы поболее.

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

Вручную перегонять существующие уже текстовые исходники в дракон сложно

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


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

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
andr писал(а):
Но я немного, может быть, неточно выразился.
Я имел в виду компактную символьную алгебру параллельных конечных автоматов (concurrent finit state machines):
компактную, по крайней мере, для простых первичных параллельных конфигураций
(без громоздких наворотов).

Как, например простой параллельный алгоритм - поток управления:

A100 = (Z0->(Z1 || Z2)->Z3) = Z0-(Z1 || Z2)-Z3 = Z0(Z1 || Z2)Z3

Это имеет признак ДП: ДитЯм Понятно.


Языков много, но думаю, Вы ожидаете увидеть язык FSP:
http://www.doc.ic.ac.uk/ltsa/eclipse/help/index.html?appendix_b___fsp_language_spec.htm

Его изучают студенты Империал-колледжа в Лондоне.
Но разве наши дети хуже?


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


Здесь нужен аппарат математической алгебры.
А школьная алгебра -- это детский лепет.

andr писал(а):
Реальная робототехника начинает проклевывать у нас (причем в новом качестве).
Особенно военная.
А вот более доступная у нас сейчас - массовая детская, но реально функционирующая робототехника.
Впадаем в детство - и вперед.


Потрясающе.
Собрать робота также просто, как построить дом из кубиков.
Тем более, что умные дяди наделали конструкторы для построения роботов.

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

Лучше посмотрите, что делают взрослые дяди:

http://opkrt.ru/index.php/news/338-opk-intellekt-dlya-otryadov-robototekhniki-peredan-zakazchiku-i-gotov-k-vnedreniyu


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 23 Октябрь, 2015 17:14 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Шелехов писал(а):
andr писал(а):
Но я немного, может быть, неточно выразился.
Я имел в виду компактную символьную алгебру параллельных конечных автоматов (concurrent finit state machines):
компактную, по крайней мере, для простых первичных параллельных конфигураций
(без громоздких наворотов).

Как, например простой параллельный алгоритм - поток управления:

A100 = (Z0->(Z1 || Z2)->Z3) = Z0-(Z1 || Z2)-Z3 = Z0(Z1 || Z2)Z3

Это имеет признак ДП: ДитЯм Понятно.


Языков много, но думаю, Вы ожидаете увидеть язык FSP:
http://www.doc.ic.ac.uk/ltsa/eclipse/help/index.html?appendix_b___fsp_language_spec.htm
Никак нет.

Владимир Шелехов писал(а):
Его изучают студенты Империал-колледжа в Лондоне.
Но разве наши дети хуже?
Мало ли в каких спец.колледжах за какие большие деньги и что изучают ихние и наши вундера.
А наши вундра занимают призовые места на мировых олимпиадах по информатике:
точнее по математике и программированию.
Ну и что из этого.

Вопрос идет о массовой общеобразовательной и общедоступной робототехнике.
А это ставит вопрос о массовой общеобразовательной и общедоступной параллельной алгоритмике.
Что, всю школьную массу будет загонять в вундера.
А кто не потянет - тех сдавать в ПТУ?
(это раньше были такие пугалки).

А что мы можем предложить по параллельным алгоритмам
из общедоступного - на первое самое трудное время?:
въехать в параллельное алгоритмическое мышление.
Обычные последовательные алгоритмы худо-бедно осваиваются в массовом порядке.
(Правда есть маленький пустячок - мировой кризис массового образования).
А здесь нужен решительный перелом последовательного алгоритмического мышления.
У Вас есть какие-то конкретные приемлемые для этого предложения?

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

А если мы навалимся взаправду на массовую школу всей мощью науки?
Уже была такая попытка - засандалить классическую теорию алгоритмов в начальную школу в 60-х годах.
И ничего не получилось - это не потому, что учителя были дураки.
Это не повод для куража.
Надо бы изучить этот опыт, но нет никакой доступной информации.
Только одни (непроверенные) отрицательные слухи.

Владимир Шелехов писал(а):
andr писал(а):
Реальная робототехника начинает проклевывать у нас (причем в новом качестве).
Особенно военная.
А вот более доступная у нас сейчас - массовая детская, но реально функционирующая робототехника.
Впадаем в детство - и вперед.
Потрясающе.
Собрать робота также просто, как построить дом из кубиков.
Тем более, что умные дяди наделали конструкторы для построения роботов.

А Вы пробовали собрать что-нибудь стоящее из таких кубиков?
Тележки собираются легко.
Большие дяди строят из этого даже действующие модели автоматических станочных линий.
Весьма условно конечно.
Только не очень пока ясно зачем и за какие деньги.
Но направление перспективное - еще неизвестно, что скоро станет возможно собирать за доступные деньги.

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

Владимир Шелехов писал(а):
Лучше посмотрите, что делают взрослые дяди:

http://opkrt.ru/index.php/news/338-opk-intellekt-dlya-otryadov-robototekhniki-peredan-zakazchiku-i-gotov-k-vnedreniyu
И слава богу, бальзам на душу.
За хорошие денюшки, надо понимать.
Перестали пилить бюджет (местами), взялись за ум и стали финансировать науку.
И мы показали им кузькину мать.
Спасибо Вам за такую информацию.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 01 Ноябрь, 2015 13:39 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
Владимир Паронджанов писал(а):
... согласен. Биполярность нужна. Степан Митькин с Вами уже согласился.
Участник adva тоже Вас поддерживает в косвенной форме. Цитирую
В сообщении viewtopic.php?p=93519#p93519 участник adva писал(а):
Думаю сдвиг может пройти только после того, как будет реализована перегонка текста в дракон и наоборот...
Вручную перегонять существующие текстовые исходники в дракон уже сложно

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

Недавно обнаружил, что идея дуальности реализована в NASA в рамках системы PVSio-web:
http://www.pvsioweb.org/
http://www.chi-med.ac.uk/publicdocs/WP310.pdf

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

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

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

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

Formal methods - направление в Computer Science, развиваемое более 40 лет. Имеется более десяти разных международных конференций по формальным методам. Международные конференции NASA Formal Methods проводятся с 1990г.

В нашей стране исследования по формальным методам проводятся в Москве в Институте Системного Программирования, в Питере, в Новосибирске в Институте Систем Информатике и других местах. Большинство специалистов нашего профиля в лучшем случае лишь слышали, что где-то применяются формальные методы. В этом году я создал в Новосибирском Государственном Университете новый курс "Формальные методы в программной инженерии"
http://programming.nsu.ru/sites/default/files/fm_pred.doc
с намерением внедрять его со следующего года в университетах аэрокосмического профиля.


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

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Степан Митькин писал(а):
Владимир Шелехов писал(а):
Бесполезно аргументировать в пользу того или иного стиля. Люди разные.
Биполярный мир программистов -- это реальность.

Похоже, Владимир Иванович уже принял решение и отговаривать его не имеет смысла.
В таком случае хочу пожелать ему удачи.

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

Поддерживаю Владимира Ивановича Шелехова и Степана Борисовича Митькина!

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

Авторам интегрированных сред нужно ориентироваться в будущем на поддержку режима обратного проектирования.


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

Зарегистрирован: Воскресенье, 09 Март, 2008 22:38
Сообщения: 341
Владимир Паронджанов писал(а):
Теперь по поводу частного вопроса о побочных (дополнительных) входах в процедуру. В ДРАКОН-НПЦАП это не реализовано

Бортовые программы с множеством "входов" - в том числе включаемых в различные моменты времени - практика, много лет успешно использовавшаяся в ЦСКБ.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 02 Ноябрь, 2015 10:28 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5179
Откуда: Москва
TAU писал(а):
Бортовые программы с множеством "входов" - в том числе включаемых в различные моменты времени - практика, много лет успешно использовавшаяся в ЦСКБ.

Все это у нас есть. Думаю, что дело просто в различиях в системе понятий и в терминологии.

Множество "входов" можно понимать по-разному.

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

Как это происходит?

Важную роль играет канал ввода-вывода (input-output processor (IOP)), который размещает информацию в оперативной памяти компьютера.

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

Благодаря этим идентификаторам инженеры имеют СМЫСЛОВОЙ доступ к информации, находящейся в оперативной памяти.

Инженеры пишут алгоритмы (исходные тексты программ).

Программы канала ввода-вывода пишут не инженеры, а программисты.

Таким образом, разница в терминологии состоит в том, что алгоритмы имеют только ОДИН вход и ОДИН выход. Но внутри алгоритмов используются ИДЕНТИФИКАТОРЫ, точно указывающие на ВХОДНУЮ информацию компьютера.

Вы имеете полное право считать их "множеством входов".

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

Таким образом, внутри дракон-схемы имеется много входов в программу и много выходов из программы.

Принципиальные особенности языка ДРАКОН-НПЦАП

1. Дракон-схема как программа имеет один вход и один выход в соответствии с правилами структурного программирования (одна икона Заголовок и одна икона Конец).

2. Дракон-схема строится по правилам двумерного (визуального) структурного программирования, которое является развитием одномерного структурного программирования.

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




ЗАЧЕМ ВСЕ ЭТО НАДО?

Так мыслит инженер. Так удобно мыслить инженеру.

В НПЦАП все сделано для того, чтобы обеспечить наибольшие удобства для инженеров, которые разрабатыват бортовые и наземные программы по принципу "Программирование без программистов".

Повторю еще раз. Инженеры должны создать только ИСХОДНЫЙ КОД и только. Инженеры создают исходный код программ на языке ДРАКОН (т.е. в системе ГРАФИТ-ФЛОКС). Все остальное делают программисты.

=======================
Не будем отвлекаться от темы. Мы находимся в теме Текстовый и графический редактор

Просьба комментарии и вопросы по теме "Технология ГРАФИТ-ФЛОКС" задавать в другой теме:
viewtopic.php?f=100&t=1091


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

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Шелехов писал(а):
PVSio-web используется для построения программной части интерактивных систем, например, медицинских приборов с пользовательским и программным управлением. Есть приложения в авионике.

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

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

Владимир Шелехов писал(а):
Formal methods - направление в Computer Science, развиваемое более 40 лет. Имеется более десяти разных международных конференций по формальным методам. Международные конференции NASA Formal Methods проводятся с 1990г.
Владимир Шелехов писал(а):
В нашей стране исследования по формальным методам проводятся в Москве в Институте Системного Программирования, в Питере, в Новосибирске в Институте Систем Информатике и других местах.
Это информация к тому же, но уже более позитивная.

Владимир Шелехов писал(а):
Большинство специалистов нашего профиля в лучшем случае лишь слышали, что где-то применяются формальные методы.

В этом году я создал в Новосибирском Государственном Университете новый курс "Формальные методы в программной инженерии"
http://programming.nsu.ru/sites/default/files/fm_pred.doc
с намерением внедрять его со следующего года в университетах аэрокосмического профиля.
Но это актуально не только для авионики, но и для любых технических специальностей с развитой автоматизацией,
и тем более, в ответственных робототехнических системах.

Представляет интерес вся программа - для первичной персональной ориентировки, в частности:
http://programming.nsu.ru/sites/default/files/fm_pred.doc
Но особый (персональный) интерес вызывает
Раздел 3. Верификация программных систем методом проверки моделей
Вложение:
ModChe-05.PNG
ModChe-05.PNG [ 38.7 КБ | Просмотров: 13730 ]

Вложение:
ModChe-06.PNG
ModChe-06.PNG [ 26.17 КБ | Просмотров: 13731 ]

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

1
Для Дракона есть перспективный крепкий орешек:
внедрение в эту проблему Model Checking - Проверка Моделей.

2
Прежде всего - подраздел 3.3
Цитата:
3.3. Алгоритмы проверки моделей: классические и оптимизированные
Алгоритмы проверки на модели свойств систем, выраженных формулами временных логик CTL и LTL.
Символьные представления данных для алгоритмов проверки моделей. Булевские модели. Целочисленные модели.
Символьный алгоритм проверки на модели свойств систем, выраженных формулами временной логики CTL. Справедливость. Контрпримеры и свидетельства.
Символьный алгоритм проверки на модели свойств систем, выраженных формулами временной логики LTL.
Использование особенностей проверяемых моделей: редукция, абстракция, композиция, симметрия.

3
Правда здесь есть некоторая неудобственность:
не очень ясно (сходу, со стороны) в каким смысле надо трактовать термин "алгоритмы".

Например, в книге Model Checking:
Верификация моделей параллельных и распределенных программных систем
viewtopic.php?p=93700#p93700
В Главе 3 и Главе 4 - алгоритмы проверки для двух моделей темпоральной логики (логики времени)
алгоритмы в явной графической форме не видны.
Там представлены разные автоматные модели.
Но это не совсем алгоритмы.

А затем в Главе 8. Применение алгоритма model checking
кратко излагается, в частности, анализ бизнес-процессов.
Приводится пример специального графического языка процессов для менеджеров.
(по какой-то аналогии с Сетями Петри, UML и т.п.)
Решается задача спецификации взаимодействующих процессов,
на некотором специальном графическом языке, доступном для массового менеджера.
Это очень актуально, но это все же не совсем блок-схемы параллельных алгоритмов.

4
Объективно перед драконом появляется актуальная задача:
дать исчерпывающую визуальную (схемную) алгоритмическую интерпретацию методов Проверки Моделей,
приемлемую и доступную для массового практического пользователя.

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


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

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
Пожелание участнику Форума andr: поменьше мусорить.
andr писал(а):
Владимир Шелехов писал(а):
В этом году я создал в Новосибирском Государственном Университете новый курс "Формальные методы в программной инженерии"
http://programming.nsu.ru/sites/default/files/fm_pred.doc
с намерением внедрять его со следующего года в университетах аэрокосмического профиля.
Но это актуально не только для авионики, но и для любых технических специальностей с развитой автоматизацией, и тем более, в ответственных робототехнических системах.

Объективно перед драконом появляется актуальная задача:
дать исчерпывающую визуальную (схемную) алгоритмическую интерпретацию методов Проверки Моделей, приемлемую и доступную для массового практического пользователя.
Формальные методы (и в частности, Проверка Моделей) не для массового пользователя, и Дракон здесь ничем не поможет. Это сложно, дорого и требует высокой квалификации. В нашей стране формальными методами владеют менее 50 человек, причем большая их часть - в Институте Системного Программирования, выпускники МГУ. Число наших соотечественников за рубежом, владеющих формальными методами, на порядок больше.

Магистранты Новосибирского Государственного Университета сдают мне задание по формальным методам с 4-7 раза. НГУ -- третий вуз в стране после МГУ и СПбГУ. Чтобы учить формальным методам студентов других вузов нам придется: 1) выбирать небольшие группы из самых сильных студентов; 2) ослабить требования. Большого числа студентов мы не потянем. Лектор должен сам хорошо владеть формальными методами, а проверка индивидуальных заданий -- трудоемкое дело.

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

Если вы предложите руководству Роскосмоса внедрять формальные методы в космическое программирование, то они вас не поймут. Посмотрите на образование высшего руководства Роскосмоса: http://www.federalspace.ru/120/. Маловероятно, что кто-то из них имеет представление хотя бы о системном программировании.

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

У меня предложение к участникам и администрации Форума OberonCore: создать на Форуме новую рубрику "Космическое программирование" и продолжить дискуссию в новой теме и новой рубрике. Первоначально я хотел создать такую тему на Форуме http://novosti-kosmonavtiki.ru/forum/. Там жуткая толчея. По программированию я нашел всего одну тему "О тупых программистах": http://novosti-kosmonavtiki.ru/forum/messages/forum16/topic13977/message1152959/#message1152959 -- дискуссия низкого уровня с редкими проблесками. Да и дискуссией это трудно назвать, скорее, бормотание. Посмотрел другие форумы и понял, что лучшей площадки для обсуждения, чем наш Форум, нет.

Прошу высказываться по поводу новой рубрики.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 05 Ноябрь, 2015 17:08 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5179
Откуда: Москва
Владимир Шелехов писал(а):
Прошу высказываться по поводу новой рубрики.
Сделано (заявка подана)
viewtopic.php?p=93733#p93733


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 06 Ноябрь, 2015 08:13 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Шелехов писал(а):
Пожелание участнику Форума andr: поменьше мусорить.
viewtopic.php?p=93732#p93732

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

Построение такого редактора запланировано в проекте по технологии автоматного программирования. Обсуждается также возможность разработки подобного редактора для языка Модула-2. В обоих случаях для графического представления предполагается использовать язык Дракон.

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

Есть такие вопросы:
1) Предусматривается ли схемная и текстовая реализация параллельных алгоритмов?
2) Если да, то:

2.1) Какие автоматные модели предполагаются?:
......
......
Прямого ответа не было - и этим все сказано:
нет, не предусматривается (видимо так).
Но сопутствующая информация была очень полезная.

А параллельная проблематика - это не мусор,
в том числе и в связи с автоматными методами в программировании.
Приглашаю Вас поработать на этому вопросу на теме:
viewtopic.php?p=93738#p93738
(если, конечно такой параллельный "мусор" Вас интересует, например, в той самой формальной Model Checking).

2
Что касается формальных систем:
Владимир Шелехов писал(а):
andr писал(а):
Владимир Шелехов писал(а):
В этом году я создал в Новосибирском Государственном Университете новый курс "Формальные методы в программной инженерии"
http://programming.nsu.ru/sites/default/files/fm_pred.doc
с намерением внедрять его со следующего года в университетах аэрокосмического профиля.
Но это актуально не только для авионики, но и для любых технических специальностей с развитой автоматизацией, и тем более, в ответственных робототехнических системах.

Объективно перед драконом появляется актуальная задача:
дать исчерпывающую визуальную (схемную) алгоритмическую интерпретацию методов Проверки Моделей, приемлемую и доступную для массового практического пользователя.
Формальные методы (и в частности, Проверка Моделей) не для массового пользователя, и Дракон здесь ничем не поможет. Это сложно, дорого и требует высокой квалификации.
1)Формальные методы (и в частности, Проверка Моделей) не для массового пользователя,
и
2) Дракон здесь ничем не поможет.
Это
3) сложно, дорого
и
4) требует высокой квалификации
(в смысле мы с Вами "не понянем" по квалификации?).
----------------------
Ответ не верный по всем пунктам.
Также приглашаю Вас поработать по этому вопросу - там же
(не так уж страшен черт).
Тем более, что в Вашей программе по формальным системам есть два больших принципиальных недостатка.
Но они вполне преодолимы.

3
В отношении новой рубрики
Владимир Шелехов писал(а):
У меня предложение к участникам и администрации Форума OberonCore: создать на Форуме новую рубрику "Космическое программирование" и продолжить дискуссию в новой теме и новой рубрике.

Идею горячо поддерживают.
Обещаю не "мусорить" там каверзными вопросами на засыпку
(но буду сопровождать ее в по другим темам, пока меня терпит на форуме уважаемый автор Дракона).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 06 Ноябрь, 2015 13:42 

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
andr писал(а):
Владимир Шелехов писал(а):
Пожелание участнику Форума andr: поменьше мусорить.
... А параллельная проблематика - это не мусор, в том числе и в связи с автоматными методами в программировании.
Я благодарен Вам за активное участие в обсуждении.
Но не обижайтесь на меня.
Сообщение Форума это не художественный роман и не научная статья.
Оно должно быть коротким, простым, не уходить от обсуждаемой темы.
Писать надо самое главное, деталями приходится жертвовать.
Не надо злоупотреблять цитатами -- их лучше поджать.
Все это написано в общих правилах Форума.

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

По мере возможности я пытался отвечать на Ваши вопросы, не только по теме.
Да, языка параллельного программирования для детей не нашел.


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

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


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

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


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

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