Ильченко Эдуард писал(а):
Владислав Жаринов писал(а):
... чтобы установить некоторые свойства, каждый раз придётся делать обход графа ...
Так и делаю : ) Мне показалось это проще, чем другими способами поддерживать согласованность графа. Скорость пока удовлетворительна (до двухсот икон).
На начальном этапе проще - тем более, что нужно вникнуть в математику, чтобы построить разметку, адекватную решаемым задачам. Но, как я понимаю, Ермакову с коллегами это удалось (кто знает, м.б. он дошёл до конца именно того пути, коим пошёл и я?).
А вообще это частный случай общего выбора между "абсолютным" и "относительным" в технике. Как раз без теории можно приллюстрировать на дисковых накопителях. Когда-то и на винтах, и на флопах данные были организованы по второму типу - на диск ставился один индекс (если кто помнит, на дискетах дырка делалась для ФД) - и на всех дорожках шёл отсчёт от него на всю длину (полный оборот). Ессно, набегала погрешность - но пока плотность хранения и быстродействие были невелики - на качество это не влияло.
Когда винты пошли вперёд по этим показателям - для сохранения качества записи/чтения пришлось перейти к первому типу. В диск-пакете выделили сервоповерхность - и на ней при калибровке прописывался синхросигнал, определяющий положение каждого элемента данных для всех остальных поверхностей.
То же самое и тут - абсолютная метрика графа (индекс каждой вершины, показывающий что-то важное) или относительная (куда и насколько от базы или фокуса пошли и что важное нашли).
Как это влияет на производительность? Тут надо посмотреть, что редактор делает. Если относительный тип - то "поисковые" обходы есть работа сверх целевых процессов редактирования (я не говорю об анализе моделей - но даже мой уровень матемкультуры
подсказывает, что содержательная разметка и здесь много даёт).
Если абсолютный тип - то обход, как уже говорил, только для переразметки - т.е. по результатам принятия ввода сочинителя. А при выполнении "неатомарных" операций (атомарные-то определяются исключительно согласованием типа атома с типом ввода звена - это, кстати, тоже содержательная разметка, только уже рёбер - и тоже д.б. поддержана) редактор лишь проверяет соблюдение ограничений. Не есть ли это тоже "лишняя работа"? Не вдаваясь в математику - нет. Тут дело в том, что оси порядка (N.* и G.* в "полуфабрикате") введены? Введены. Они физические координаты имеют? Имеют. Стало быть, проверку [не]равенств над индексами порядка, выражающих эти ограничения, можно заменить проверкой координат неатомарно изменяемых частей схемы на отношения с координатами осей? Полагаю - да, можно.
И тут вспомним, что делает редактор, который действительно "эргономичный инструмент" по свойствам пользования (а не по тому, что в нём заявлена реализация эргономичного языка
)?.. Такой, как тот же Автокад - или
DesignIDEF? Правильно - поддерживает пользователя показом "резиновых линий" и "буксируемых двойников". Значит, он фиксирует динамику изменения структуры "в координатах"? Да, фиксирует. Вот эти данные и использует функция контроля ограничений - сравнивая на "больше/меньше/равно" с положением тех осей, которые существенны в данном случае. И никакой лишней работы...
Над сказанным надо подумать, конечно...