Масштабирование графа

[kstrizhov]

Реализовать возможность масштабирования графа, возможность вписать граф по ширине в экран интерфейса.

Минимальные размеры вершины графа. Продумать, как и до каких пор вписывать текст в рамку вершины.

[kstrizhov]

@aurusov @bogachev-pa Возник вопрос по масштабированию. Предлагалось при изменении размеров вершин отображать разное количество информации в них. В старом РДО было 2 варианта помимо номера вершины внутри.

Первый:

Второй:

Вопрос по формату вывода. Я так понимаю, что через / перечислены <уровень вложенности вершины>/<значение, возвращаемое эвристикой>/<стоимость применения правила>. В варианте с максимумом информации еще отображается значение параметра ресурса, видимо его места для данного состояния (через равно) и имя правила. Нужно реализовать аналогичный формат, или что-то изменить? Значения, выводимые через /, вообще кажутся неочевидными. Плюс непонятно значение какого параметра выводить у ресурса, ведь в старом рдо все было однозначно, плагин только для пятнашек, а здесь ситуация другая.

[bogachev-pa]

Насчет уровня вложенности - думаю это просто значение g, т.е. стоимость пройденного пути. Т.е. там формат <g>/<h>/<стоимость применения правила> Значение параметра для общего случая выводить точно не нужно. Имя правила, думаю, стоит вывести, а стоимость его применения как-то с ним объединить.

В общем, если не придумывать ничего дополнительно, то предлагаю такой формат:

<номер_вершины> (<f> = <g> + <h>)
<имя_правила> (<cтоимость_правила>)

Вроде так максимально близко к трассировке, или я путаю?

Edit: путаю. В трассировке <имя правила>(<релевантные ресурсы правила>) = <стоимость>, <f> = <g> + <h>

Тогда, может, так?

<номер_вершины> (<f> = <g> + <h>)
<имя_правила> (<релевантные ресурсы правила>) = <стоимость правила>

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

Может еще стоит сделать подробно, в духе:

<номер_вершины>
f = <f>, g = <g>, h= <h>
rule = <имя_правила>(<релевантные ресурсы правила>)
cost = <cтомость_правила>

Но вообще первый вариант (компактный) мне больше нравится.

[kstrizhov]

Насчет уровня вложенности - думаю это просто значение g, т.е. стоимость пройденного пути. Т.е. там формат //<стоимость применения правила>

Мда, вчера уже голова не соображала. Надо же мне было так g обозвать =)

<номер_вершины> (<f> = <g> + <h>)

По поводу этого формата, единственное что смущает, что это будет выглядеть как то вроде

(3 = 2 + 1)

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

По поводу релевантных ресурсов, может взять такой формат:

<имя_правила> (<стоимость правила>) <релевантные ресурсы правила>

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

[bogachev-pa]

Похоже на пример для второго класса

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

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

Ты ведь можешь оценивать по объему текста, влезет у тебя какой-то текст или нет? Можно выводить по приоритетам:

номер -> f/g/h -> имя+стоимость правила -> список ресурсов

Что не влезает, не выводишь. Не знаю, насколько трудно это будет реализовать.

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

<имя_правила> = <стоимость_правила>

А если влезают, то, например, так:

<имя_правила> (<рел_рес_1>,
<рел_рес_2>, <рел_рес_3>) = <стоимость_правила>

[kstrizhov]

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

[aurusov]

Я за три варианта (Кирилл напомнил про третий) и вывод детальной информации по выбранной вершине

Минимальная нода

<номер_вершины>

Краткая нода

<номер_вершины>
<f> = <g> + <h>

Полная нода

<номер_вершины>
<f> = <g> + <h>
<имя_правила> = <cтоимость_правила>

Детальная информация по выбранной вершине в правом верхнем углу

<номер_вершины>
<f> = <g> + <h>
<имя_правила> (<релевантные ресурсы правила>) = <стоимость правила>

Да, как и предложил Пашеа, можно расширять полную ноду до детальной информации, если влезает. Это зависит от стратегии подсчета минимальной шинины ноды. Насколько я помню, стратегия требовала сначала расчитать минимальную ширину, опираясь на объем текста. А это проиворечит всем нашим рассуждениям об объеме информации в ноде.

[kstrizhov]

Минимальные размеры исходя из текста надо рассчитывать из случая, когда отображается минимум информации, то есть только номер вершины, так? Тогда можно взять 4, максимум 5 знаков, потому что еще по прошлому семестру помню, что когда гонял модели, после минут 20 моделирования на нескольких тысячах, происходит переполнение памяти. Тогда хотя бы это будет какой-то отправной точкой.

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

[aurusov]

Минимальные размеры исходя из текста надо рассчитывать из случая, когда отображается минимум информации, то есть только номер вершины, так?

Да. В минималке надо просто выводить номер. Обновил сообщение выше https://github.com/kstrizhov/rdo-xtext/issues/11#issuecomment-108808682.

Тогда можно взять 4, максимум 5 знаков...

Предлагаю взять 5 знаков 88888.

[aurusov]

По поводу дополнения информацией, если влезает...

Давай начнём с первых трех. По ним вопросы есть ?

[kstrizhov]

Нет, пока все понятно. Тогда начну делать, допишу в записку и перенесу в код.

[aurusov]

ТЗ уже показывал ? Что с листам ?

[kstrizhov]

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

[aurusov]

Сбрасывать ничего не надо, разберись с github.io. Создай таску по примеру Оли https://github.com/LeKaitoW/lekaitow.github.io/issues/1.

[kstrizhov]

Ну я это и имел в виду, в прошлом семестре же уже разбирался. Сейчас сделаю.

[kstrizhov]

@aurusov Создал таску для обсуждения, материалы там же. https://github.com/kstrizhov/kstrizhov.github.io/issues/2

[aurusov]

Хорошо, я на неё подписался.

[kstrizhov]

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

Перемещение_влево(Фишка1.Дырка) = 1,

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

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

• хранить полную строку вида Перемещение_влево(Фишка1.Дырка) = 1, и сокращенную Перемещение_влево = 1, в ноде, и считывать по клику одну, при масштабировании другую
• вырезать то, что в скобках, непосредственно в методе зума

[aurusov]

Второе, вырезать.