DRAKON.SU

(!)

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

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

Понятно, что если из вкладки M открыта вкладка N, то любые структурные изменения на вкладке M придётся запретить (пока N не удалена или не вырезана в отдельный проект). На "замороженной" вкладке можно лишь менять масштаб и фокус обзора.

Множество версий в одном проекте подразумевает необходимость их сравнивать: есть ли структурные различия в схемах, полученных разными способами?. Например, как быстро сравнить примитив и силуэт?

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

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

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

Нет никаких проблем в сравнении схем любым доступным способом.

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



Повторюсь ...

Уважаемый __1__, пожалуйста, не забивайте эту ветку отливкой серебряных пуль из БД.

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


Это алгоритм вычисления (площади трапеции) по расчетной формуле:
s = ((a+b)/2)*h
При заданной группировке переменных возможен
единственный линейный порядок выполнения вычислительных действий:
потенциальный (возможный, естественный, скрытый) параллелизм задачи отсутствует.


Это (функционально) эквивалентное преобразование исходной формулы
s = ((a+b)/2)*h = (a+b)*(h/2).
Появляется потенциальный параллелизм, который
либо реализуется (1-я схема слева),
либо не реализуется (2-я и 3-я схемы).

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

Комплект №2 замечаний и предложений.

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

2) Раздвижка блоков:
-- При вставке операторов Z1, Z2, Z3 над блоками они раздвигаются по вертикали
Это хорошо видно в сопоставлении схем файла test1-1seq.PNG.
-- При вставке надписей на поперечных линиях границ параллельного участка
блоки параллельных ветвей раздвигаются по горизонтали:
видно на схеме test1-2par.PNG.
Понятно, что там есть какие-то контрольные поля вокруг блоков.
Сейчас на простых схемах все это не критично.
Но хотелось бы иметь возможность при необходимости принудительно сдвигать (уплотнять) блоки.
Особенно когда надо будет работать с мылом.

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

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

-----------------------------
Но все равно, все это хорошо работает - по крайней мере в рамках данных тестов.
Завтра приступаю к переоформлению блок-схемных материалов, пока не накопились большие объемы.
Мерси.

Прошу извинить за непонимание.
Рисунок

Переменная V3 куда потом девается и откуда берется переменная V2?
Или V2 это и есть V3?

В следующей версии постараюсь исправить.


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


Да, ограничитель минимальной ширины есть.
Можно попробовать выровнять текст по центру. Ctrl+E.


Сейчас есть возможность сохранять схему в файл формата PNG.
Выделить икону и нажать самую нижнюю левую кнопку в окне Конструктор. Или Alt+Shift+S.

Можно сохранить изображение схемы в буфер.
Выделить икону и нажать самую нижнюю вторую слева кнопку в окне Конструктор. Или Alt+Ctrl+S.
В MS Word из буфера схемы вставляются без проблем. В документы LibreOffice иногда вставляются, иногда - нет. В GIMP 2 вообще не вставляется. Побороть не смог : (

И для файла и для буфера справедливо следующее:

Если в схеме-силуэт есть Соединитель и выделена икона Имя ветки, то сохранится только часть схемы, ограниченная Соединителями.
Изображение сохраняется с разрешением 300 DPI. На этом форуме, такие картинки показываются слишком большими, поэтому я их уменьшаю сторонним редактором (FastStone Image Viewer).

Уважаемый andr, Вы впервые выложили дракон-схему. Я этого давно ждал.

Поздравляю с дебютом. Желаю успехов и надеюсь на продолжение.

Девиз Дракона: "Посмотрел — и сразу понял!"

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

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

В иконе "Заголовок" напишите:
В иконе "Конец" оставьте слово Конец.
В иконе "Комментарий" напишите необходимые для детей пояснения.

Я буду Вам помогать. Методом последовательных приближений путем обмена мнениями мы с Вами доведем схему до успешного завершения.

Здесь у меня ошибочка вышла.
Вместо записи Z5: s = v1*v2
должно быть Z5: s = v1*v3.

Спасибо за Ваше замечание.
Надо будет исправить файл 2-го примера.

Я поначалу так и делал, но потом стал экономить время.

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


Конечно не возражаю.
Большое спасибо, что Вы во время мне об этом напомнили.
Дело здесь в следующем.

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

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


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

В-третьих, фактически сейчас есть две задачи:
-- вписать Фабулу в основные разработки - независимо от образовательной робототехники;
-- адаптировать эти вопросы на образовательную робототехнику.
Надо будет более четко разделить эту работу.
И хорошо, что возник вопрос типа:
Девиз Дракона: "Посмотрел — и сразу понял!"


Хорошо, я этим займусь.
Но если все пошло взаправду, то мне надо будет поработать.

Сейчас предполагается начинать работу на уровне 9-11 классов, точнее начнем, кажется, с 9-го класса.
(кстати говоря, такой первый опыт с параллельными алгоритмами был в системе ПТУ - но очень давно).
Но в перспективе надо присматриваться и к более ранним возрастам,
поскольку образовательная робототехника внедряется на всех уровнях обучения - начиная с 1-го класса.
Но такие головоломки пока не поджимают.

В отношении ограничения вариантов.
Я как раз настроен на эксперименты с разными вариантами оформления Фабула-блок-схем.
И их необходимо вписать в общую систему.

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

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

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

Учебный алгоритмический язык - это подмножество языка Алгол-68 для последовательных программ.
Он просто дополняется служебными словами в английском варианте языка Algol-68.
Это все - для последовательных алгоритмов и поэтапно расширяется на псевдокоды параллельных алгоритмов.

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

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

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

(продолжение следует)

В одной из последующих версий (не в следующей) попробую сделать уплотнение как опцию.

Закрываю различные окна нажатием на крестик.

Как снова открыть необходимое окно?

Щёлкнуть правой кнопкой мыши в области, выделенной красными прямоугольниками.
В появившемся окне отметить окно, которое нужно увидеть.

Логичнее иметь в главном меню общепринятый пункт "Окна".

Какие еще есть "потаенные места" для вызова контекстных меню по правой клавише мыши?

Согласен. В последующих версиях постараюсь предусмотреть.


Специально я контекстные меню ещё не делал. Если что и вылезет, то это поведение Qt или Windows.

Эти " Окна" в Фабуле уже есть: в нижнем левом углу находится «Содержание» проекта (оглавление). Осталось …

1. Сделать его иерархическим (показывать иерархию транзакций).
2. Цветовой маркировкой (Select) отображать узлы-репозитории, открытые во вкладках.
3. Имена узлов оглавления должны соответствовать именам вкладок. В этих именах понятным способом последовательно перечислить путь наверх: имя начальной транзакции, как часть имени, должно быть первым (слева). Впоследствии, начальные репозитории могут быть удалены из проекта, но маркировка оставшихся сохранит "иерархический" вид.
4.
Добавить интерактивность:
i. Пусть клик мышью на узле оглавления открывает соответствующую вкладку. Или осуществляет переход к ней (если уже открыта).
ii. Активную вкладку отображать в оглавлении особым ‘курсорным’ цветом (Focus).
iii. Двойным кликом на имени вкладки кратковременно менять цвет активного узла на обычный цвет других открытых вкладок (мигание курсора лучше заметно, чем его особый цвет).

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

--

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

Продолжение

Смысл овальных терминаторов на схемах алгоритмов и программ

Далее приводится следующая информация:

Синтаксические скобки begin end (нач кон) - это ограничительные оболочки тела текста алгоритма,
представленного, в данном случае, последовательностью 3-х операторов команд
(следующих через знак ";").
В синтаксисе языка Algol-68 (и Алгол-68) эти синтаксические скобки
могут заменяться парой круглых скобок:
alg A10: (v1 := a + b; v2 := v1 / 2; s := v2 * h)
алг A10: (v1 := a + b; v2 := v1 / 2; s := v2 * h)

Пока можно принять за исходную основу формальное соответствие
литерной оболочки begin end (нач кон)
и терминаторов блок-схем с соответствующими надписями.

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

Далее приводится следующая информация к размышлению:


Здесь просматривается другое соответствие:
Синтаксические скобки типа begin end (нач кон)
в исходных кодах программ и псевдокодах алгоритмов
это вербальные (словесные) оболочки тела текста псевдокода алгоритма,
которые соответствуют скобочным оболочкам структурных формул типа А10 = ( ... ),
а вместе они соответствуют схемным оболочкам типа прямоугольных блоков.
Внешние и внутренние вложенные оболочки играют большую роль
в распараллеливании алгоритмов (и программ).

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

Признаком их бессмысленности является то,
что в верхний терминатор вместо надписи типа Начало (Begin)
стали вставлять имена алгоритмов и программ.

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

Вопрос №1.
Какая необходимость изображать овальные терминаторы на схемах алгоритмов и программ.
Можно ли рисовать блок-схемы алгоритмов без таких терминаторов,
оставляя только линии входной и выходной связи?
Что от этого измениться?

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

Вопрос №2.
Если такие овальные терминаторы применяются,
то какой их корректный (физический) смысл может быть?

Например:

1) Входной овальный терминатор означает
входной сигнал пуск (программы) - кликом мыши по иконке программы?
Выходной овальный блок означает
какие-то выходные эффекты при выходе из программы?

2) Входной овальный терминатор означает
вход в подпрограмму с записью адреса возврата (при выходе их подпрограммы)?
Выходной овальный блок означает
выход их подпрограммы по адресу возврата и передачу управления далее?

Две вставки test1-1seq-02.PNG и test1-2par-02.PNG не выводятся
и выдаются сообщения

в то время как третья вставка воспроизводится нормально.

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

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

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

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

2) В качестве троянского коня использовать совместное участие во внедрении
графической среды Фабула (в рамках общей дракон-идеологии)
в (экспериментальные) курсы образовательной робототехники.
Кроме учебного алгоритмического языка (в принципе здесь все ясно)
предусматривается выход на программирование робототехнических лего-комплектов
с микропроцессорным управлением (типа Ардуино) - на языках низкого и высокого уровня.
Но этот вопрос пока в состоянии прожектов (на январь 2016 г.).

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

Изменится вот что. Язык ДРАКОН перестанет существовать. Более подробно см.
http://drakon.su/_media/biblioteka_1/03 ... itmy_1.pdf

1. Язык ДРАКОН предназначен для замены международного стандарта ISO 5807-85 и его российского эквивалента (кальки) ГОСТ 19.701-90.

2. Язык ДРАКОН предлагает другую идеологию, другую терминологию и другую систему правил.

Уважаемый andr, обсуждение этих вопросов ведется на этом форуме с 2008 года. Если Вы хотите снова подвергнуть сомнению основы ДРАКОНа, Вы всегда можете сделать это:

— либо открыв новую тему,

— либо продолжить обсуждение здесь:
viewtopic.php?f=62&t=1503

— либо здесь:
viewtopic.php?f=62&t=1554