Компактное представление путей в графе

У меня есть подмножество простых путей в графе. Длина путей ограничена . $d$

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

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

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

graphs data-structures

— выбирать
источник

Какая информация о каждом пути нужна вам при «переборе этого подмножества»? Длина? Посещенные узлы? Пересечения с другими путями? ... Их может быть

, поэтому вы должны быть готовы к "не очень быстрому", если вам нужно хранить целые пути.

2^{d}

$2^d$

— Рафаэль

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

будет графом хоста, и установите вес каждого ребра на ноль. Если вы нашли путь процентной

, увеличивать вес каждого ребра

, которая находится в

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

и отбросить все ребра с нулевым весом или что-то в этом роде.

G

$G$

P

$P$

G

$G$

P

$P$

G

$G$

— Juho

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

— Юхо

Возможно, вы захотите проверить статью Эппштейна о

кратчайших путях и соответствующую литературу. Они также имеют дело с компактными представлениями.

k

$k$

— Юхо

Существует некоторая возможность использования автоматов FSM для представления путей, а затем можно выполнять основные операции, такие как объединения, пересечения, вычитания и т. д., а также операция «сжатия» минимизации автоматов FSM хорошо понята / оптимальна и эффективна. Я не видел, как это было сделано в статье, но предложил еще одну похожую проблему ...

— vzn

Ответы:

Три может сделать свое дело: http://en.wikipedia.org/wiki/Trie

Пометьте каждый край вашего графика буквой. Затем добавьте строки, которые представляют пути через ваш график в Trie. Чтобы выполнить требование, что «никакие другие пути, кроме выбранных, не представлены», вы можете оставить все вершины дерева пустыми и пометить ребра, кроме случаев, когда ребра, ведущие от корня к вершине, представляют один из ваших путей, а затем пометить вершину чем-то. A bool, номер пути при некотором порядке и т. Д.

После того, как вы построили свой файл, есть алгоритмы его сжатия до оптимального (или почти оптимального) представления. (см. связанную статью Wikipedia.)

— Настоящий Джон Коннор
источник

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

— Опция

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

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

— Якуб Котовски
источник

В зависимости от сложности и предварительной / последующей обработки, требуемой для вашего алгоритма, возможно, самый простой вариант - это способ. Вы можете тривиально представить их как массивы и сохранить их в сжатом виде в формате HDF5. Эта библиотека оснащена некоторыми быстрыми алгоритмами сжатия, так что чтение и запись сжатых данных может быть даже быстрее, чем без сжатия.

Вот несколько сюжетов:

Время последовательного доступа на элемент для массива EAR на 15 ГБ и различных размеров фрагментов:

Скорость распаковки с использованием Blosc на PyTables: введите описание изображения здесь

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

— Davidmh
источник