DRAKON.SU

Текущее время: Пятница, 27 Апрель, 2018 06:12

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




Начать новую тему Ответить на тему  [ Сообщений: 31 ]  На страницу Пред.  1, 2
Автор Сообщение
СообщениеДобавлено: Среда, 22 Май, 2013 11:02 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3624
Откуда: Москва
Илья Ермаков писал(а):
Вообще, конечно, Вы смешиваете в один уровень сам граф и его визуальное представление...


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

Цитата из русской Википедии
Цитата:
Визуализация графов

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

Проблема визуализации графов встаёт, например, при отображении больших интегральных схем, анализе социальных сетей, в таких областях как картография и биоинформатика.
http://ru.wikipedia.org/wiki/%D0%92%D0% ... 0%BE%D0%B2


Вот цитата из англовики:
Цитата:
Graph drawing

From Wikipedia, the free encyclopedia

            This article is about the general subject of graph drawing. For the annual research symposium, see International Symposium on Graph Drawing.

Graph drawing is an area of mathematics and computer science combining methods from geometric graph theory and information visualization to derive two-dimensional depictions of graphs arising from applications such as social network analysis, cartography, and bioinformatics.[1]

http://en.wikipedia.org/wiki/Graph_drawing


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Май, 2013 11:45 
Аватара пользователя

Зарегистрирован: Вторник, 04 Октябрь, 2011 17:45
Сообщения: 456
Madzi писал(а):
На самом деле, представляя схему ДРАКОНА как набор узлов, вы убиваете изначальную идею автора.

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

Силуэт - это набор прямых.

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

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

Если перевести вашу мысль на язык баз данных, то получается вот что:
"Имеется денормализация данных, в которых хранятся положения икон. У соседа сверху такой же x. Так зачем же его хранить два раза?"

С данным соображением согласен. Разрешить его можно так:
1. Хранить координату "x" в отдельной сущности "вертикаль".
2. Хранить координату "y" в отдельной сущности "горизонталь".
3. Сущность "узел" будет ссылаться на вертикаль и горизонталь.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Май, 2013 12:29 
Аватара пользователя

Зарегистрирован: Суббота, 12 Июль, 2008 22:49
Сообщения: 73
Откуда: Россия, Санкт-Петербург
Степан Митькин писал(а):
Почему я предлагаю этого не делать?
Усложняется схема данных и код, который с ней работает.

В чём усложнение ?
Вычислить координаты в момент построения схемы ?

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Май, 2013 12:40 
Аватара пользователя

Зарегистрирован: Суббота, 29 Март, 2008 19:27
Сообщения: 949
Откуда: Россия, Чебоксары
Степан Митькин писал(а):
1. Хранить координату "x" в отдельной сущности "вертикаль".
2. Хранить координату "y" в отдельной сущности "горизонталь".
Это тоже денормализация. Даже x на самом деле не нужен! :wink:

Степан Митькин писал(а):
3. Сущность "узел" будет ссылаться на вертикаль и горизонталь.
Соответственно, тоже лишнее...

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Май, 2013 21:22 

Зарегистрирован: Понедельник, 09 Ноябрь, 2009 17:29
Сообщения: 904
Откуда: Россия, Питер
Madzi писал(а):
На самом деле, представляя схему ДРАКОНА как набор узлов, вы убиваете изначальную идею автора.

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

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

А зачем вручную править текст, представляющий дракон-схему?

От текстового представления только две пользы:

1.
Поиск багов при отладке редактора.

2.
Разработка трансляторов в другие представления.

Принципиальной разницы нет, в каком виде использовать текстовое представление.
Я использовал оба.

Сейчас пользуюсь таким:
Код:
<?xml version="1.0" encoding="Windows-1251"?>
<fbrep version="0.1">
    <space value="-50000 -50000 100000 100000"/>
    <viewport value="0.420448 83.2445 382.925"/>
    <scheme kind="drakon_plus" version="0.1" type="primitive" un="0">
        <residence value="-269 -141"/>
        <un_last value="78"/>
        <has_end value="yes"/>
        <route value="branch">
            <un value="3"/>
            <boundary value="0 0 0 1545.5"/>
            <first value="1"/>
        </route>
        <item name="begin">
            <un value="1"/>
            <boundary value="-50 0 100 25"/>
            <below value="14"/>
            <right value="4"/>
            <skewer value="3"/>
            <text1_HTML>Untitled</text1_HTML>
        </item>
        <item name="param">
            <un value="4"/>
            <boundary value="0 0 100 25"/>
            <left value="1"/>
            <sideLoc value="2"/>
            <modeLocation value="2"/>
         </item>

         . . .

        <item name="join_bottom">
            <un value="74"/>
            <boundary value="0 0 10 10"/>
            <above value="72"/>
            <below value="2"/>
            <right value="73"/>
            <skewer value="3"/>
        </item>
        <item name="end">
            <un value="2"/>
            <boundary value="-40 0 80 25"/>
            <above value="74"/>
            <skewer value="3"/>
            <text1_HTML>Конец</text1_HTML>
            <hidden value="no"/>
        </item>
    </scheme>
</fbrep>


Это часть представления вот для этой схемы:
Вложение:
dummy__.png
dummy__.png [ 40.73 КБ | Просмотров: 3091 ]

Это полный текст.
Вложение:
dummy.txt [16.61 КБ]
Скачиваний: 87


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Среда, 22 Май, 2013 21:52 

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

Ещё как-то нужно хранить форматированный текст, да и форматирование самих икон. Ну там, цвет, перо, фон, шрифт ...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 23 Май, 2013 08:09 

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


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

1. Моя идея воплощена в визуальном языке. При этом показано, что визуальное представление — это строгий математический объект.

2. Я никогда не делал (и не собираюсь делать в будущем) никаких утверждений и рекомендаций о желательной форме ТЕКСТОВОГО представления. Считаю, что это не мое дело. Этот вопрос должны решать компетентные специалисты (которые сделают это гораздо лучше меня).

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 23 Май, 2013 18:07 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
kirushik в viewtopic.php?p=80204#p80204 писал(а):
Владислав Жаринов писал(а):
В общем, Вы считаете "нишей" для техноязыка (кроме программирования простых железяк "пошагово") представление сценариев использования разного софта?

Не совсем так. Я скорее считаю, что любое решение программистской задачи имеет некоторую позицию на оси «общее–частное решение».
...
Полной противоположностью к ним являются “частные решения”, когда решается максимально локальная информатизационная задача, и перед разработчиком софта не ставится ни малейшей цели сделать “универсально”, “масштабируемо” или там, на английский манер “future proof”... Возможных «экологических ниш» в этой половине шкалы на самом деле гораздо, на порядки, больше. Но все многочисленные ниши тут пока абсолютно свободны, а несчастные пользователи выполняют работу компьютеров и вручную борются с рутиной. И очень редко когда какая–нибудь корпоративная ИС (документооборота, планирования ресурсов предприятия, управления клиенской базой...) имеет «человеческое лицо» и решает задачу в частности, зато отлично и эргономично. ...
Важное уточнение. Дело в том, что есть ещё один путь - делать локально для конкретной предметки, но законченную систему. Как можно понять, на базе корректного подхода такое возможно (разработки Усова, например).


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 23 Май, 2013 18:12 

Зарегистрирован: Воскресенье, 01 Ноябрь, 2009 05:13
Сообщения: 1442
Илья Ермаков в viewtopic.php?p=80267#p80267 писал(а):
... С другой... Возможно, как раз для задачи визуального языка это и сработает эффективно: ссылки на "географических" соседей.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Воскресенье, 02 Июнь, 2013 00:32 

Зарегистрирован: Четверг, 11 Апрель, 2013 21:07
Сообщения: 6
Во–первых, огромное спасибо всем вступившим в обсуждение собственного формата.
Отдельное, специальное спасибо (практически медаль) достаётся Степану Митькину, давшему потрясающе детальный и аргументированный построчный комментарий строго по основной теме разговора. Позволю себе именно по этой причине пополемизировать в первую очередь с ним :-) .

Степан Митькин писал(а):
line 11
"skewers" - (означает шампуры) Неподходящий здесь термин.
Должно быть "branches" (ветки).

Не уверен. Всё–таки авторский вариант названия — «шампуры», это отражает их некоторое существенное отличие от просто «веток». Кроме того, я вслед за Фейнманом считаю, что введение “свежей”, отличной от всего предыдущего номенклатуры — очень хорошая и помогающая мышлению практика, ибо не “загрязняет” понимание нерелевантными контекстами из прошлых инкарнаций термина.

Степан Митькин писал(а):
line 22
Содержимое иконы хранится в уже разобранном виде. Почему это плохо?
1. Получается, что каждый тип икон имеет разный набор полей.
Это неудобно для хранения диаграмм в базе данных.
2. Синтаксический разбор (parsing) перемешан с хранением схемы.
Это хороший повод для появления макаронного кода в будущем.

Современные БД — это далеко не только реляционные табличные системы. Наоборот, наибольший расцвет сейчас испытывают именно системы для хранения и обработки неоднородных данных, под общим (не очень удачным на мой взгляд) называнием «NoSQL». Советую обратить внимание как минимум на Apache Cassandra, RethinkDB и Redis.
Более того, даже в сугубо табличной реляционной PostgreSQL есть даже специальный тип данных для хранения подобных JSON–документов с валидацией и достаточно разнообразными функциями для обработки, а любые сложные выборки–преобразования возможны при помощи погруженного в базу обработчика Javascript PLV8.

Второй пункт я, честно признаться, не понял. Сериализация — этап, всегда предществующий сохранению объекта (а десериализация — последующий за загрузкой) в хранилище, будь то файл, принтер или удалённая БД. В большинстве известных мне сред программирования это разные этапы, но реализуются они в семантически близких местах (например, сериализация — в классе, унаследованном от правильного “сохранятора” в Qt или наоборот, сохранение в БД — в классе, правильно описаном аннотациями сериализации в Java). При этом под сериализацией обычно понимают сохранение либо в текстовом, либо в бинарном представлении, подразумевающем взаимнооднозначное восстановление структуры программных объектов при обратном преобразовании.
Если совсем кратко — сериализация и сохранение это два этапа, которые нужны удивительно часто и в 99,99% случаев реальной жизни следуют друг за другом, поэтому способы их “правильной” (“чистой”, “идеологичной” для используемого языка/среды, несвязной в смысле «decoupled», какой угодно ещё) реализации разработаны давно и используются повсеместно.

Степан Митькин писал(а):
line 36
"default_answer", "alternative_answer" - больно напыщенно, по-учёному.
Я бы чего-нибудь попроще выбрал: yes_answer, no_answer.

Я специально передумал и заменил «yes» и «no» на «default» и «alternative». Значение этих “рукавов” — принципиально не логические (в смысле значений логической функции), а компоновочные (в смысле компоновки элементов диаргаммы). «default_answer» служит продлением уже идущего шампура и визуализирует наиболее вероятный алгоритмически путь развития событий. «alternative» — описывает ответвление, и по идее должен встречаться реже чем «default». Это, кстати, важно не только для графического представления алгоритма, но и для подсказки правильных ветвлений компилятору для генерации оптимального машинного кода тоже.

Степан Митькин писал(а):
line 37
"text": "Да" - хранение излишней информации.
И так ясно, что "Да".
Если наклеечки "Да" и "Нет" переставлены, для хранения этого факта достаточно логической переменной. Иными словами, данные не нормализованы.

А китайцам как в таком формате надписи хранить? У них, насколько мне известно, нет универсального утвердительного/отрицательного слов, а в качестве выражения согласия/несогласия используется утверждение, производное от вопросительной фразы. Собственно, даже в русском есть такие фразы, вроде «Ты же не куришь, верно?» Ветка, на которой написано «Да», она куда ведёт? Лучше дать пользователю возможность написать «Курю» и «Не курю».
Вообще, “прибивать гвоздями” текст к логическим состояниям — это очень плохая практика для продуктов, которые потом придётся на другие языки мира локализовывать.

Степан Митькин писал(а):
line 78
"clause" - это разобранное представление поля "text"?
1. Дублируем информацию.
2. Смешиваем синтаксический разбор с рисованием квадратиков.

Я опять–таки настаиваю, что текст на квадратике и логика, за ним стоящая — это не всегда одно и то же, и содержит в себе разную информацию. Поленюсь сейчас подбирать пример, впрочем — честно признаюсь.

Степан Митькин писал(а):
Общие замечания:

1. Нет информации о координатах.
Мы же работаем с графикой! Да, координаты можно вывести автоматически.
Но это редко будет красиво.

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

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

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

Остаётся только “человеческая” сложность. Но мы в любом случае представляем двумерный объект (плоский граф) в виде одномерного (упорядоченная последовательность символов, то есть текст в файле), то есть избыточная сложность “на чтении–письме” всё равно будет иметь место, вопрос только, в каком из программных компонентов она будет иметь место. И тут мне кажется, что нет никакого криминала положить её в явном виде в сериализационные механизмы, а не доверяться в этом автоматике систем вроде RDBMS.
Кроме того, про хранение JSON–документов в базах данных (всплывало уже выше) я могу рассказать сколь угодно подробно, благо это достаточно часто использующаяся в промышленности техника.

Касательно пункта про связь между иконками — не уверен, что это вообще валидное возражение. Запись нескольких десятков килобайт на диск — абсолютно нечувствительная операция для современных ПК, передавать обновлённую схему по медленной внешней сети “на каждый чих” нет никакой необходимости (для этого есть механизмы вроде rsync или diff, которые прекрасно адаптируются к текстовым слабоменяющимся локальным файлам небольшой длины), а для поддержания целостности софту давно уже следует использовать механизм “двойной записи” — когда на диск сначала пишется в сериализованном виде команда из «Undo–буфера», и только потом (возможно, после выполнения нескольких команд пачкой) — специальным образом помеченная сериализованная текущая версия документа. Последнее поведение, кроме ускорения дисковых операций на сохранение состояния, полезно ещё тем, что история изменений (Undo/Redo, как это по–русски лучше всего сказать?) сохраняется полностью между сессиями работы с кодом. Такой подход, в частности, реализуют все современные онлайновые офисные пакеты, вроде Google Docs или Miscrosoft Office LIVE.

Илья Ермаков писал(а):
Вообще, конечно, Вы смешиваете в один уровень сам граф и его визуальное представление...

Вот это — очень похожая на мою мысль. Я ни в коем разе не хотел делать формат, задачей которого было бы однозначное расшифровывание графического представления ДРАКОНосхемы. А только лишь алгоритма, в этой схеме закодированного.
Всё остальное — опционально. То есть каждый ДРАКОНоредактор может насоздавать любых полей для сохранения собственной графической информации — и это не сломает парсинг/обработку. Стандартизировать такие вещи, на мой вкус, бессмысленно, пока у нас нет редакторов с устоявшейся и чётко зафиксированной (например, в объёме коммерческих продаж) функциональностью.

Если хотите, могу добавить пример с подобными расширенными атрибутами узлов к себе в репозиторий. А ещё лучше — если эти атрибуты можно будет не выдумывать “от фонаря”, а где–нибудь посмотреть. Это, повторюсь, не сделает их обязательными для сериализации алгоритма, скрытого в ДРАКОНограмме, но поможет программистам понять перспективу и/или потестировать собственные парсеры.

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

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

Однако я повторю, что считаю вредной тащить эти вещи в стандартную запись, поскольку в разных средах ДРАКОНа наверняка необходимы разные наборы подобных метаданных отображения. А стандартизировать алгоритмы отрисовки ДРАКОНа среди разнородных редакторов — очевидно задача не только бессмысленная, но и вредная на современном этапе становления экосистемы. Поэтому (по крайней мере пока кто–нибудь меня не переубедит) я буду выступать против включения любой специальной графической информации в описание текстового обменного формата ДРАКОНа.

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

Повторюсь, абсолютно без проблем можно расширить набор полей для любых узлов. По стандарту JSON все избыточные для парсинга узлы должны игнорироваться, а недостающие — заменяться на значения типа null. Соответственно, десериализатор не должен ломаться в этих случаях, а должен просто прибегать к более–менее разумным “умолчальным” значениям.

Владислав Жаринов писал(а):
Дело в том, что есть ещё один путь - делать локально для конкретной предметки, но законченную систему.

Мне больше симпатичен подход той же системы Cucumber (по–моему, я где–то в этом обсуждении на неё ссылался уже), когда задача формализации предметной области наперёд не ставится, но недостающие элементы формального описания человекочитаемых алгоритмов прописываются post factum, с каждой итерацией покрывая всё большую и большую часть предметной области и потому требуя всё меньше человеческого вмешательства.
Я не настаиваю, впрочем, и это дело конкретной реализации ДРАКОНоредактора под конкретную задачу — работать в режиме гибкого текстового ввода чего угодно или в режиме конструктора для заранее сформированного DSL.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Понедельник, 15 Август, 2016 22:01 

Зарегистрирован: Воскресенье, 24 Февраль, 2008 15:32
Сообщения: 3624
Откуда: Москва
Очень интересная тема. Жаль, что она не имеет продолжения.
А ведь прошло уже три года...

Кирилл Пименов! Как Ваши дела?

Какие новости? Как успехи?

Какие есть новые идеи?


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

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


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

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


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

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