DRAKON.SU

Любой вектор в трехмерном пространстве можно разложить на 3 базисных вектора x, y, z.

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

Рифат, это вопрос по визуальному синтаксису языка ДРАКОН.

1. Первоначально графический синтаксис языка ДРАКОН был описан в моей статье, опубликованной в журнале "Программирование" Российской академии наук. Она переведена на английский язык . Вот ссылка
http://drakon.su/_media/video_i_prezent ... yntax_.pdf

2. Последнее описание дано в 2012 году в книге "Учись..." Часть VI. "Конструктор алгоритмов и формальное описание языка" на стр. 393-424.
http://drakon.su/_media/biblioteka/chas ... isanie.pdf

Там есть уже готовый ответ на данный вопрос?

Да, есть. Согласно книге "учись..." графический алфавит языка ДРАКОН насчитывает 20 икон и 26 макроикон, то есть всего 46 элементов.
Правила соединения элементов строго определены. Отклонения от правил запрещены.

Все это должно быть реализовано в правильно построенной программе ДРАКОН-конструктор.

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

А, вообще, увидев такие схемы, понял, что Дракон еще более неструктурый, чем я до этого думал.

Вы правы. Стрелка присутствует в макроиконе "Цикл со стрелкой".

Лиана не имеет ничего общего со стрелкой. Но вы правы, правило про лиану относится к базису.

Это совсем не так.
Ваши слова про "произвольные места в ветке" не имеют никакого отношения к языку ДРАКОН.

В ДРАКОНе есть понятие "валентная точка".
Есть правила, которые строго и однозначно определяют, в какие валентные точки можно осуществлять присоединение лианы, а в какие нельзя.
Стрелку цикла никуда нельзя присоединять. Цикл со стрелкой — это шампур-блок. Он вводится в строго определенные валентные точки.

Язык ДРАКОН описывается совсем другим, НОВЫМ понятийным аппаратом.

Вы используете устаревший понятийный аппарат, который был разработан совсем для другой цели — для текстового (textual) программирования.
И пытаетесь незаконно применить его к принципиально новому средству — к языку визуального программирования ДРАКОН.
Так поступать нельзя. Это концептуальная ошибка.

Все с точностью до наоборот. Программирование с переходами, которые используются в Драконе, исторически возникло раньше, чем структурное программирование. Структурное программирование - более новое явление. То, что сам язык Дракон возник позднее и использует старую технологию программирования, возникшую до структурного программирования, не делает его более новым методом программирования, а структурное программирование устаревшим

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

Когда появляются новые идеи, некоторые опытные представители классического подхода, хорошо знакомые с традиционными идеями, испытывают трудности при восприятии новых идей.
Это давно известно.

В истории науки и техники таких примеров множество.

Это не соответствует действительности.
Язык ДРАКОН не использует старую технологию. Язык ДРАКОН использует принципиально новую технологию, которой раньше никогда не было.
И которая обладает принципиально новыми свойствами.

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

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

То, что Дракон позволяет такие переходы после того, как было показано, что так делать не следует, является возвратом к прошлому.

Было бы хорошо, если бы ветка в Драконе хотя бы соответстовала определению extended basic block:

из диссертации "Optimizing Compilers for Structured Programming Languages".
Это дало бы определенные преимущества в плане легкости определения какие инструкции были выполнены в какой момент времени. И в целом бы помогло упростить задачу для человека, то есть стало бы более эргономичным.
Но, те Дракон схемы, которые изображены на рисунках выше не подпадают под это определение.

Рифат, а ведь это мы уже обсуждали.

Смотрите:

1. На дракон-схеме есть только линии и квадратики. Там нет АБСОЛЮТНО никаких переходов. Нет даже такого понятия.

2. Переходы (goto) появляются после АВТОМАТИЧЕСКОГО преобразования графики в текст.

3. Появление переходов (goto, jump) после автоматического преобразования появляется всюду в рамках структурного программирования. Исключений нет.

4. Переходы (goto), с которыми боролись отцы структурного программирования, это переходы (goto), написанные ВРУЧНУЮ, а не автоматически.

5. В языке ДРАКОН никто не пишет переходы (goto) вручную.

6. Рифат, ваша ошибка в том, что вы не различаете два разных механизма появления перехода (goto): автоматический и ручной.

Переход (goto), написанный программистом ВРУЧНУЮ при создании исходного кода (source code) программы — это плохо.

Переход (goto, jump), появившийся в результате компиляции при создании исполняемого кода (executable code) — это жизненyая необходимость, которая используется повсеместно. Ничего плохого в этом нет.

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

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

Нет, Рифат, проблема именно в этом.
И эта мысль лежит в основе структурного программирования, которое вы активно защищаете.

ДРАКОН обеспечивает более наглядное и удобное разделение на части, чем текстовое программирование (разделяй и властвуй).

ДРАКОН обеспечивает такую структуру зрительных сцен, которая значительно сокращает число ошибок (по сравнению со структурным программированием).

Ваша мысль, что текстовое программирование (пусть даже структурное) нагляднее. чем визуальное программирование на ДРАКОНе объясняется просто. Вы не использовали в своей работе этот язык.

Ваши суждения умозрительны. Вы не привели ни одного реального примера, который показывает минусы ДРАКОНа.
Ваши ссылки на примеры это оторванные от жизни абстракции.

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

Вообще, при переделывании неструктурных алгоритмов в структурные часто становятся заметны ошибки. На сайте oberoncore есть старая тема, от Александра Ильина, где он переделывал циклы loop end в нормальные циклы и при этом находил ошибки.

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

О какой ошибке вы говорите?
Я не смог обнаружить ошибку.
Посмотрите:
viewtopic.php?p=100889#p100889