DRAKON.SU

Текущее время: Воскресенье, 07 Март, 2021 02:05

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




Начать новую тему Ответить на тему  [ Сообщений: 95 ]  На страницу Пред.  1, 2, 3, 4, 5  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 30 Октябрь, 2015 10:01 

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
anpspb писал(а):
Дракон, ревизионизм и эмпириокритицизм
Хороший зачин - в духе незабвенного Ильича.

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

anpspb писал(а):
"ЭМПИРИОКРИТИЦИ́ЗМ (муж. род) - философское направление, отрицающее объективное существование материального мира и рассматривающее его как явление сознания и сочетания ощущений."
Кто там отрицает и рассматривает? Ату его в болото.

anpspb писал(а):
andr писал(а):
Владимир Паронджанов писал(а):
Каждая мелочь в отдельности не имеет большого значения.
Эти мелочи называются "интеллектуальные затруднения". Для кого? Для читателей, для студентов, для ученых, для юзеров, для всех у кого есть глаза и мозг.
Согласен, бывают большие последствия малых причин - и в позитив и в негатив.
Особенно если их много.
Короче говоря, надо начинать читать (очень вдумчиво) дракон-концепцию - от начала и до конца.

Цитата:
Еще от andr:

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

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

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

От В.Д. Паронджанова:
4) Моя цель — создать интеллектуальные средства и инструменты, которые позволяют устранить или уменьшить интеллектуальные трудности. Язык ДРАКОН — одно из таких средств.

В отношении интеллектуальных трудностей.
Есть вот такая реальная ситуация - в порядке обследования конкретного объекта приложения
(на предмет обоснования предполагаемого внедрения системы Дракон+Фабула)

1
Первый курс студентов - в большом потоке несколько специальностей (по старой номенклатуре):
-- вычислительные машины, комплексы, системы и сети;
-- системотехники АСУ;
-- системы автоматизированного проектирования;
-- программное обеспечение АСУ и САПР
(здесь были даже спец.группы после техникума механизации учета).

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

В кратком вводном курсе прикладной (структурной) теории параллельных (и последовательных) алгоритмов
(наряду с постоянными демонстрация разных технических параллельных моделей):
-- короткие индуктивные определения типа:
(Zi) =. Ak, (Ai1->Ai2) =. Ai, (Ai1 || Ai2) =. Ai и т.п. и к ним простые блок-схемы;
-- простые абстрактные примеры и
интерпретированные примеры вычислительных и технических алгоритмов - с блок схемами,
типа:
http://forum.oberoncore.ru/viewtopic.php?p=93650#p93650
Вложение:
ТА-20.PNG
ТА-20.PNG [ 10.13 КБ | Просмотров: 11974 ]
(и посложнее, конечно).

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

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

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

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

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

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

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

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

Итого:
пока стоят совсем другие проблемы.
Правда автору этого поста еще нужно прокачать эргономику Дракон-концепции.
Но об этом будет далее.

anpspb писал(а):
Ряд тезисов для обсуждения.
1) Складывается впечатление, что описания типа "понятный", "сверхпонятный", "легко для понимания", "взглянул и сразу понял" - близки к "явлениям сознания и сочетаниям ощущений" - всяк понимает по-своему.

2) ИМХО, подобный субъективизм - слабое место Дракон-подхода и по этому поводу можно спорить бесконечно.

3) С чем можно сравнить степень "понимаемости"? от чего она зависит? Как ее оценить "в числах"?

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

-------------------------------------
anpspb писал(а):
Давайте сравним с субъективизмом в другой "визуальной области" - в фотографии. Являясь членом СПб фотообщества, знаю, что наш Председатель Д.В.Кораблев в свое время проводил специальные исследования в содружестве с учеными-физиологами с целью определить - что такое "хорошая" и что такое "плохая" композиция кадра (см. открытый форум-школу "Фотокомпозиция и визуальное восприятие (1)". http://spbfo.ru/index.php?topic=1618.0 ):

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

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

После долгих многолетних поисков и перебора различных вариантов, за основу была взята природа человека, а именно механизмы физиологии зрения и психологии восприятия. В основу легли разработки Лаборатории физиологии зрения Института физиологии им. И. П. Павлова РАН.

--- конец цитаты---

Наконец, было выяснено (в т.ч. с использованием социологических опросов и стат. обработки), что подчас основополагающим является т. наз. "смысловой центр" (Фотокомпозиция и визуальное восприятие (2): http://spbfo.ru/index.php?topic=1659.0 ): "... то, что изображено на снимке, гораздо важнее для зрителя, чем как все это изображено. Причем, для разных людей приоритеты могут самыми разными, вплоть до противоположных. У всех неодинаковое воспитание, образование, круг общения и интересов."

В т.ч. было выяснено, что повернутое изображение мозг "возвращает" его в нормальное (вертикальное) состояние (с целью более четкого опознания) со скоростью примерно 60 градусов в секунду. С другими "числовыми" характеристиками работы мозга, исследованными Кораблевым, пока не знаком.
Тем не менее, уверен, что и при оценке "понятности" схем (блок-, Дракон-, UML-... и т.п.) следует опираться на четкие критерии, которые следует знать (или исследовать и сформулировать, если их еще нет).

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

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

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

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

Если оценивать с этоих позиций отношение к "goto", то становится понятным, что его ликвидация (и появление ряда "замен" типа "break", "continue") является стремлением облегчить именно временнОе позиционирование (которое моделируется посредством двумерного пространственного).

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

5) Если просмотреть ветку, то бросается в глаза, что описание ДЕЙСТВИЙ, появившихся в блок-схемах в давние времена, пытаются применить НА ПРАКТИКЕ к событийному программированию, появившемуся позже. Так что должна, по мнению "ревизионистов", описывать Дракон-схема: действия, состояния, события, данные? Или всю эту мешанину в "одном флаконе"? И причем внутри программной системы, которая еще и вырабатывает программыный код?

6) Если отделить способность ясно видеть (глазами) и опознавать графические обозначения Дракона (как бы "синтаксис" языка) от их функции ("семантики"), следует признать, что эта семантика ориентирована на человека "с улицы", знакомого с ограниченным множеством понятий, пришедших из окружающей жизни (быта). и ориентированная на _действия_ (сесть в автобус, купить билет, повторить предыдущее действие и т.п.). И потому Дракон-схемы понятны большинству людей - не надо учиться чему-то заново, элементарные действия описаны на естественном языке, не перегружены семантикой, следуют в естественном порядке (заданном Правилами Дракона). Как здесь не вспомнить подход ТРИЗа при решении подчас сложных технических (изобретательских) задач: опиши задачу, не употребляя специальных терминов, напр. "дырка" вместо "отверстие".

7) Если говорить о продолжении ТРИЗовского подхода применительно к Дракону, то стоит, видимо, говорить о выращивании "куста" надстроек в виде специализированных языков (над некоторой общезначимой "базой"). Тогда - "каждой сестре по серьге": школьникам, которых надо научить алгоритмически мыслить - бязовый Дракон, специалистам - свой надязык, обогащенный, в зависимости от предметной области, новыми конструкциями. Одним словом - "разделяй и властвуй"!
Все это интересно конкретно обсудить по пунктам - в привязке к Дракон-системе.
Предлагаю все это включить в такую общую конфигурацию, типа:
сопоставление и взаимосвязь логики и психологии понятийного (или вербального) и образного мышления.

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

anpspb писал(а):
Но представляется, что более конструктивным было бы не спорить о том, как бы сделать универсальный язык-оболочку (по типу PL/1), вмещающий всё-всё-всё, а сосредоточится, как давным-давно опробовали на примере Алгол-68, на базовом языке-ядре и возможностях его предметно-специфических расширений.

1
Алгол-68 - очень хорошо, тем более, что это классика, которая заложена (по минимум) в школьный (учебный) алгоритмический язык:
для последовательных алгоритмов
(и просто расширяется на простые параллельные алгоритмы).
2
"на базовом языке-ядре" - хорошая идея - явно определить ядро Дракон-системы:
-- оно уже есть?
-- его надо выделить из наличного общего состава?
-- его нужно дополнить?
3
"возможностях его предметно-специфических расширений".
Тоже не худо.
Есть над чем подумать.

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


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

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Формальные системы, теория параллельных алгоритмов и Дракон-концепция

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


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

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Формальные системы, теория параллельных алгоритмов и Дракон-концепция

Данное сообщение переносится с поста:
viewtopic.php?p=93739#p93739
Поскольку это прямо касается данной темы Теория алгоритмов и Дракон-концепция,
сам указанный пост полностью переносится сюда по п.п. 1, 2:

Владимир Шелехов писал(а):
Пожелание участнику Форума 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) требует высокой квалификации
(в смысле мы с Вами "не потянем" по квалификации?).

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

====================
Здесь, правда, есть небольшое расхождение в терминологии:
формальные методы и формальные системы.
Но это две стороны одной монеты (как будет видно далее).

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

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


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

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

andr писал(а):
в программе по формальным системам (по формальным методам) есть два больших принципиальных недостатка.
Но они вполне преодолимы.

1
В программе учебного курса по формальным методам в программной инженерии
перечисляются ("проходятся") 3 разные отдельно взятые формальные системы, однако:
отсутствует общая системная связка, включая:
1.1
Общие представления о формальных методах (формальных системах) в программной инженерии.
1.2
Некоторый краткий классификационный обзор таких систем - для общей ориентировки в проблематике в целом.
Вложение:
ModChe-10.PNG
ModChe-10.PNG [ 45.88 КБ | Просмотров: 11894 ]

В детализации содержания разделов этого тоже нет - по формальным методам в целом:
Вложение:
ModChe-11.PNG
ModChe-11.PNG [ 36.98 КБ | Просмотров: 11894 ]

И в списках литературы по разделам этого тоже нет.

-----------------------
Что делать?
Для начала можно обратиться к Википедии (это не гарантия истины, но, тем не менее, ориентир):
Вложение:
ModChe-12.PNG
ModChe-12.PNG [ 51.8 КБ | Просмотров: 11894 ]

Первыми в списке идут "разные исчисления логики".
В этом направлении существуют формальные системы ~ формальные логические системы ~ формальные аксиоматические системы и т.п.
Это относится к математической логике.
В п.1.1 программы курса указано:
Необходимые основы математической логики.
Его необходимо расшифровать конкретно (и в некотором в общем разделе).
В общих курсах математической логики и (классической) теории алгоритмов
для технических специальностей это не дается.
И в книге по математической логике (в списке литературы раздела 1) этого нет:
Ершов Ю.Л., Палютин Е.А. Математическая логика. : Наука, 1987. – 336 с.
Вложение:
Ершов_Палютин-МатЛогика-1987.djvu [5.22 МБ]
Скачиваний: 201

Вложение:
ModChe-13.PNG
ModChe-13.PNG [ 129.91 КБ | Просмотров: 11894 ]

Формальные (логические) системы так или иначе лежат в основе всех формальных методов.
Снова смотрим в Википедию:
Вложение:
ModChe-14.PNG
ModChe-14.PNG [ 43.01 КБ | Просмотров: 11894 ]

Кроме того, необходима небольшая отрезвляющая добавка - по интерпретации формальных систем:
http://lib.alnam.ru/book_sii.php?id=29
Вложение:
ModChe-15.PNG
ModChe-15.PNG [ 28.8 КБ | Просмотров: 11894 ]


----------------------
С этим более или менее ясно. :D
Теперь появляется вопрос, как это преподать технарям,
чтобы потом не было по 7 заходов на защитах тем РГР, лаб.работ и на зачетах.
Нужна системная раскрутка по спирали - сквозными циклами и т.п.

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


Последний раз редактировалось andr Пятница, 06 Ноябрь, 2015 16:18, всего редактировалось 1 раз.

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

Зарегистрирован: Вторник, 22 Сентябрь, 2015 20:43
Сообщения: 76
andr писал(а):
Формальные системы, теория параллельных алгоритмов и Дракон-концепция

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


Сначала по поводу темы "Теория алгоритмов и Дракон-концепция".

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

Алгоритм еще рассматривается как синоним программы. Точнее, программа является реализацией алгоритма.
Понятие программы более уместно по отношению к языку Дракон.

Далее, а причем тут Дракон.
В Драконе нет типов, переменных, выражений, нет даже оператора присваивания. Нет данных
Как ни парадоксально, но это достоинство.

А что есть в Драконе.
Только структуры управления (иерархическая композиция операторов программы),
причем в графическом варианте.
Наполнение икон произвольно, и это не обязательно текст.
Главное достоинство -- эргономика.
Еще одно достоинство -- Дракон удобен для формализации управления при описании бытовых алгоритмов,
что повышает их наглядность.

А какова же связь Теория алгоритмов и Дракон-концепции. А нет никакой связи.

Теперь о параллельных алгоритмах.
Параллелизм в Драконе ограничен управлением.
Но параллелизма без данных не бывает.
Здесь мы исключаем из рассмотрения бытовые параллельные алгоритмы.
Именно взаимодействие по данным, способы их организации и передачи
составляют основные проблемы реализации параллельных программ.
Гонки по данным. Сложнейшие проблемы верификации, где, кстати, часто используется Model Checking.


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

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Шелехов писал(а):
andr писал(а):
Формальные системы, теория параллельных алгоритмов и Дракон-концепция

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

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


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

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Шелехов писал(а):
andr писал(а):
Формальные системы, теория параллельных алгоритмов и Дракон-концепция

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


Сначала по поводу темы "Теория алгоритмов и Дракон-концепция".

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

.........
С тех пор, как стал систематически интересоваться теорией алгоритмов
(это где-то аж в начале 70-х прошлого столетия),
всегда знал, что есть классическая или фундаментальная и неклассическая или прикладная теория алгоритмов:
Вложение:
ТА-00.PNG
ТА-00.PNG [ 6.55 КБ | Просмотров: 11873 ]

Подтверждение этому приводится в конце поста:
http://forum.oberoncore.ru/viewtopic.php?p=93531#p93531
Это выборки из 2-х статей Словаря по кибернетике (1989 и 1979 гг. издания).

Можно привести и другие подтверждения.
Например, в книге:
Вложение:
ТА-30.PNG
ТА-30.PNG [ 174.7 КБ | Просмотров: 11873 ]
Вторая глава - это изложение прикладной теории (последовательных) алгоритмов.


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

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

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

Исходный объект анализа:
датская Scratch- программа "Качели" (она уже была на форуме)
Вложение:
test13-01.png
test13-01.png [ 49.83 КБ | Просмотров: 11801 ]

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

Условно это два независимых механизма периодического действия - без явного отражения приводов.
При необходимости можно показать привода качелей. :D
Вложение:
Инстр01-00.PNG
Инстр01-00.PNG [ 265.75 КБ | Просмотров: 11801 ]


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

В частности в учебной среде моделирования роботов и робототехнических систем V-REP
тоже самый первый пример в комплекте примеров (он уже тоже приводился на форуме):
Вложение:
ОбрРТ-01.PNG
ОбрРТ-01.PNG [ 226.74 КБ | Просмотров: 11801 ]

Два стационарных промышленных робота работают независимо,
и при этом непрерывно вычисляется минимальное расстояние d (дистанция)
между подвижными руками роботов.
Если объемы устройств пересекаются, то роботы меняют цвет на красный
(простейший вид взаимодействия).
"Столкновения" обнаруживаются, но еще не предотвращаются.
Вложение:
ОбрРТ-02.PNG
ОбрРТ-02.PNG [ 210.33 КБ | Просмотров: 11801 ]


Для полноты представлений приводится скрэтч-пример с двумя независимыми мобильными объектами:
два дрона - обследуют местность
(это переделанная программа робота-пылесоса):
Вложение:
Дрон 02.PNG
Дрон 02.PNG [ 28.27 КБ | Просмотров: 11801 ]

Предусмотрено предотвращение их столкновений.

---------------------------
Далее приводится рабочий образец для описания алгоритма:
два однотипных независимых стационарных объекта - нефтяные качалки
(пример тоже уже приводится на форуме).
Вложение:
Качок 01.PNG
Качок 01.PNG [ 6.53 КБ | Просмотров: 11801 ]


Далее приводятся 2 независимых алгоритма управления 2-мя объектами:
Вложение:
2_качалки_01_01.PNG
2_качалки_01_01.PNG [ 33.15 КБ | Просмотров: 11801 ]

Алгоритмы представляют 2 скрипта следующего типа:
Вложение:
2_качалки_01_02.PNG
2_качалки_01_02.PNG [ 33.16 КБ | Просмотров: 11801 ]

Эти алгоритмы необходимо объединить в общий алгоритм работы системы
(для нее скрипт не пишется).
В частности может быть предложен такой общий алгоритм:
Вложение:
2_качалки_01_03.PNG
2_качалки_01_03.PNG [ 17.41 КБ | Просмотров: 11801 ]


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

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


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

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

Предельно простая детская параллельная программа Качели (PlayGround) - из серии "детский примитив":
выявляется много неясных проблем.
Вложение:
test13-01.png
test13-01.png [ 49.83 КБ | Просмотров: 11773 ]

Вложение:
Scr-01.PNG
Scr-01.PNG [ 88.96 КБ | Просмотров: 11773 ]

Вложение:
test13-01-02.png
test13-01-02.png [ 83.79 КБ | Просмотров: 11773 ]

Вложение:
Scr-05.PNG
Scr-05.PNG [ 17.03 КБ | Просмотров: 11773 ]

Вложение:
Scr-06.PNG
Scr-06.PNG [ 14.84 КБ | Просмотров: 11773 ]

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

ПВ-01: Проблемный вопрос № 1: Алгоритмы без выходов
(несколько составляющих вопросов):
1
Оба алгоритма представляют собой бесконечные циклы - со входом, но без выхода (выхода нет :( )
Как это следует отображать (структурными схемами и структурными формулами)?
Фактически - это однополюсники по потоку управления:
есть вход - входной полюс, нет выхода - выходного полюса
(полюсы - это концы отрезков связей, как правило с некоторым их оснащением
для сопряжения концов разных связей и образования узлов связей).
2
Во всех книгах по Дракону бесконечные циклы упоминаются,
и приводятся два примера с силуэтами - там нет выхода типа Конец.
Но как это будет выглядеть в обычных (добропорядочных) схемах алгоритмов,
непочтительно именуемых в дракон-концепции как примитивы?
3
В текущей версии Фабулы в составе конструктора есть только двухполюсная начальная конструкция (с одним входом и одним выходом):
Вложение:
Фабула-01.PNG
Фабула-01.PNG [ 46.78 КБ | Просмотров: 11773 ]
Что делать?
4
В приведенной схеме комплекта алгоритмов (рис. 1.3) используются двухполюсники алгоритмов:
с выходами типа Конец (без подписей).
В предыдущей схеме с использованием Фабулы также используется двухполюсная начальная конструкция:
viewtopic.php?p=94211#p94211
Допустимо ли это?
5
Этот простой вопрос (типа с какого конца развивать яйцо) у меня давно зудил.
Практически всегда показываю двухполюсники, но поясняю, что:
на самом деле здесь бесконечный цикл, и выхода из него нет.
Иногда такой выход изображаю пунктиром (с пунктирным овальным терминатором).
Интуитивно это кажется вполне допустимо.
Но хотелось бы иметь теоретическое обоснование - поскольку речь идет
о теоретико-алгоритмическом анализе детских параллельных программ (и вообще).
Такое обоснование наконец-то появилось (само собой), когда рисовал фабула-схемы в предыдущем посте.
Об это будет позднее (в продолжении данного поста).

ПВ-02: Проблемный вопрос № 2: Как прекратить работу алгоритма?
(прекратить бесконечный цикл).
Об этом также будет позднее.

ПВ-03: Проблемный вопрос № 3: Как отобразить эти алгоритмы в составе сценария?
(фактически необходим надалгоритм управления комплектом 2-х алгоритмов).
Об этом также будет позднее.

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


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

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
andr писал(а):
ПВ-01: Проблемный вопрос № 1: Алгоритмы без выходов

В Фабуле алгоритм без выхода можно сделать только в силуэте.
Вложение:
e1.png
e1.png [ 4.18 КБ | Просмотров: 11749 ]


andr писал(а):
ПВ-02: Проблемный вопрос № 2: Как прекратить работу алгоритма?
(прекратить бесконечный цикл).

Бесконечный цикл, по определению, не прекращаем : )
В противном случае это конечный цикл.

andr писал(а):
ПВ-03: Проблемный вопрос № 3: Как отобразить эти алгоритмы в составе сценария?
(фактически необходим надалгоритм управления комплектом 2-х алгоритмов).


Про качалки.

Примем, что качалки это модели реальных качалок.
Тогда имеем для каждой качалки два типа алгоритмов: АПК - алгоритм поведения качалки во внешнем мире и АУ - алгоритм управления качалкой.

АУ
С алгоритмом управления качалкой всё просто. Он один для каждой из качалок.
Вложение:
ау.png
ау.png [ 10.74 КБ | Просмотров: 11749 ]


С алгоритмом поведения качалки всё сложнее. Он просто описывается словами, но не очень красиво выглядит в графике.

АПК
При активации флага качалки активируются.
При нажатии кнопки Пуск качалка работает.
При нажатии кнопки Стоп качалка не работает.

Все события не определены по времени.
Все действия активируются событиями.

В графике.
Вложение:
апк.png
апк.png [ 4.94 КБ | Просмотров: 11749 ]


И сеть качалок.
Вложение:
апк сеть.png
апк сеть.png [ 10.13 КБ | Просмотров: 11749 ]


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

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Ильченко Эдуард писал(а):
andr писал(а):
ПВ-01: Проблемный вопрос № 1: Алгоритмы без выходов

В Фабуле алгоритм без выхода можно сделать только в силуэте.
Вложение:
Вложение e1.png больше недоступно


Вложение:
Бесконечные_циклы-01.PNG
Бесконечные_циклы-01.PNG [ 15.38 КБ | Просмотров: 11731 ]

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

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

В частости, таким явным образом (с явными контурами обратной связи) можно отобразить исходную схемную задачу
"Далее приводятся 2 независимых алгоритма управления 2-мя объектами" - две качалки:
http://forum.oberoncore.ru/viewtopic.php?p=94211#p94211

2
Это можно сделать только в составе силуэта.
Там почти обычная блок-схема бесконечного цикла без выхода.
Обычная, но почти.

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

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

2.3
В излагаемом подходе предполагается изложение материала:

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

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

То есть на первых этапах обучения лучше (будет) использовать все-таки
схемы с применением специальных УГО начала и окончания цикла:
http://forum.oberoncore.ru/viewtopic.php?p=94211#p94211
(с фиктивным выходом - об этом будет отдельный разговор).
А для начала можно нарисовать нужную схему
(в данном случае обычную схему бесконечного цикла без выхода)
простыми графическими редакторами
(для первичных разъяснений).

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

3
На приведенной выше схеме алгоритма используются
особые УГО (иконки) заголовка и адреса ветки с черными "наконечниками" острых углов.
В таблицах списков икон и макроикон Дракона (и Фабулы) таких особых обозначений нет.
И появляются непонятки.
Необходимо "рыскать" по тексту книг в поисках информации.
Есть где-то в середине книг первая картинка с такими особенностями и разъяснение:
Вложение:
Бесконечные_циклы-02.PNG
Бесконечные_циклы-02.PNG [ 8.94 КБ | Просмотров: 11731 ]

Кстати говоря, для левой схемы (наверху) с одной веткой это не актуально - она и так сразу видна.

Если такие особые обозначение для икон используются,
то целесообразно поместить их в общую таблицу икон.
Чтобы обеспечить быстрый справочный поиск.


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

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

Когда-то предлагалась такая схема бесконечного цикла (не помню кем):
Вложение:
c1.png
c1.png [ 1.15 КБ | Просмотров: 11719 ]


Если допустить такую схему, тогда в Параллельных процессах могут появится висячие маршруты и их можно отображать так:
Вложение:
c2.png
c2.png [ 1.77 КБ | Просмотров: 11719 ]
Вложение:
c3.png
c3.png [ 3.47 КБ | Просмотров: 11719 ]


Отсюда следует, что такие маршруты можно завершать иконами Конец. В принципе, это логично, так как Параллельный процесс это фактически отдельный Исполнитель.
Вложение:
c4.png
c4.png [ 3.81 КБ | Просмотров: 11719 ]


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

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1156
Странные рисунки.

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


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5109
Откуда: Москва
andr писал(а):
Если такие особые обозначение для икон используются, то целесообразно поместить их в общую таблицу икон.
Чтобы обеспечить быстрый справочный поиск.

1. Черные треугольники никак не влияют на работу алгоритма. Веточные циклы образуются не из-за черных треугольников, а из-за надписей в иконах Адрес.

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

3. Я предполагаю, что можно ограничиться случаем,
когда N <= 4.

4. Например:
        — черный треугольник,
        — черный треугольник с белым овалом,
        — черный треугольник с вертикальной белой штриховкой,
        — черный треугольник с горизонтальной белой штриховкой,

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

6. Расстановка черных треугольников (всех типов) должна выполняться не вручную, а только автоматически.

7. Черный треугольник с белым овалом показан на рис. 304, 305 в книге "Учись...".


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

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

Откуда это следует?

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

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

Вот и ОС Windows представляет собой бесконечный цикл ... до определённого момента.


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

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

1. Черные треугольники никак не влияют на работу алгоритма. Веточные циклы образуются не из-за черных треугольников, а из-за надписей в иконах Адрес.
Это понятно.
Черный треугольник - это вспомогательная метка для повышения визуальной наглядности выделения конкретных веток
(в дополнение к надписям).
Это вспомогательная модификация 2-х первичных условных графических обозначений или 2-х первичных икон
(без меток - условно, например, "белых"):
на входе ветки (имя ветки) и на выходе ветки (адрес перехода).
Такая вспомогательная модификация не меняет структурные функции этих графических элементов.

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

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

3. Я предполагаю, что можно ограничиться случаем,
когда N <= 4.

4. Например:
        — черный треугольник,
        — черный треугольник с белым овалом,
        — черный треугольник с вертикальной белой штриховкой,
        — черный треугольник с горизонтальной белой штриховкой,

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

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

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

Владимир Паронджанов писал(а):
6. Расстановка черных треугольников (всех типов) должна выполняться не вручную, а только автоматически.
Это уже ТУ в ТЗ на автоматизацию - в некоторой какой-то версии.
Ждем-с.


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

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 189
Откуда: Россия, Санкт-Петербург
Ильченко Эдуард писал(а):
Они одновременно активируются и работают одновременно бесконечно долго, в пределах некоторой модели.
Это нужно как-то отразить.
Просто ваша модель не полна по Дракону. Согласно Дракону, грядёт Конец света, и всякий алгоритм перейдёт на икону Конец. Читайте Откровение Дракона, там всё предсказано. Икона должна быть.

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


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

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 5109
Откуда: Москва
Цитата:
Но поскольку такая модификация допускается, ее целесообразно сразу оговорить
или в самой сводной таблице икон,
или непосредственно после нее
(может быть - в небольшой дополнительной таблице икон).
Согласен. Лучше в дополнительной таблице, которую можно назвать "Таблица маркеров". Потому что это все-таки НЕ иконы.

Разница между иконами и маркерами состоит в следующем.

Все иконы, из которых строится дракон-схема, размещает ЧЕЛОВЕК, автор дракон-схемы.

Маркеры человек не размещает. Они появляются "сами собой".
В том смысле, что все маркеры автоматически формирует дракон-редактор, после того как человек заполняет текстом иконы Адрес.


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

Зарегистрирован: Четверг, 30 Январь, 2014 13:38
Сообщения: 423
Владимир Паронджанов писал(а):
Согласен. Лучше в дополнительной таблице, которую можно назвать "Таблица маркеров". Потому что это все-таки НЕ иконы.

Разница между иконами и маркерами состоит в следующем.

Все иконы, из которых строится дракон-схема, размещает ЧЕЛОВЕК, автор дракон-схемы.

Маркеры человек не размещает. Они появляются "сами собой".
В том смысле, что все маркеры автоматически формирует дракон-редактор, после того как человек заполняет текстом иконы Адрес.

А как сейчас этот вопрос состоит реально в существующих 3-х дракон-редакторах?


Последний раз редактировалось andr Среда, 09 Декабрь, 2015 16:31, всего редактировалось 1 раз.

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

Зарегистрирован: Среда, 07 Январь, 2015 14:53
Сообщения: 1156
andr писал(а):
А как сейчас этот вопрос состоит в существующих 3-х дракон-редакторах?

Для ИС Дракон -
http://drakon.su/programma_is_drakon
Цитата:
Особенности

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

Так же полное соответствие требованиям языка Дракон и эргономичность работы в ИС Дракон.
Программа в одном файле (менее 1 МБт), а не в ворохе заимствованных dll (десятки МБт), из которого что можно потерять. Смотрите - http://forum.oberoncore.ru/viewtopic.php?p=94246#p94246.


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

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


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

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


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

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