Компактне представлення шляхів у графі

У графі є підмножина простих шляхів. Довжина доріжок обмежена знаком $d$ .

Який найбільш компактний спосіб (на пам'ять), який я можу представити таким чином, щоб жоден інший шлях, крім вибраних, не був представлений?

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

Одне уявлення, яке мені прийшло в голову, представляло їх як набір дерев. Але я здогадуюсь, що звести його до оптимальної кількості дерев - це важко? Які ще уявлення було б добре?

graphs data-structures

— Опт
джерело

Під час "повторення цього підмножини" яка інформація про кожен шлях вам потрібна? Довжина? Відвідані вузли? Перехрестя з іншими стежками? ... Може бути

2^{d}

$2^d$ багато, тож вам доведеться бути готовими до "не дуже швидкого", якщо вам потрібно зберігати цілі шляхи.

— Рафаель

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

G

$G$ бути графіком хоста і встановити вагу кожного краю на нуль. Коли ви знайдете цікавий шлях

P

$P$ , приріст ваги кожного краю в

G

$G$ що є в

P

$P$ . Зрештою, вага ребра вказує, скільки контурів з’являється цей край. Можливо, ви могли зараз обчислити мінімальну обсадову дереву

G

$G$ , і опустіть усі краї з нульовою вагою, або щось подібне.

— Juho

Ну, навіть з’єднання двох простих непересічних крайових контурів може створити цикл, тому обчислення MST змусить вас втратити один із шляхів, які я думаю. Але вищесказане може дати вам кілька ідей.

— Juho

Ви можете ознайомитись з документом Еппштейна

k

$k$ найкоротші шляхи та відповідна література. Вони також мають справу з компактними уявленнями.

— Juho

є певна можливість використання FSM для представлення шляхів, і тоді можна робити основні операції, такі як об'єднання, перетини, віднімання тощо ... а також операція "стиснення" мінімізації FSM добре зрозуміла / оптимальна та ефективна. ще не бачив цього в роботі, але запропонував це по іншій схожій проблемі ...

— vzn

Відповіді:

Три може зробити цю справу: http://en.wikipedia.org/wiki/Trie

Позначте кожен край своєї графіки буквою. Потім додайте до трійки рядки, які представляють шляхи через ваш графік. Щоб виконати вимогу, що "жоден інший шлях крім вибраних не відображається", ви можете залишити всі вершини трійки порожніми та позначити краї, за винятком випадків, коли краї, що ведуть від кореня до вершини, представляють один із ваших шляхів, тоді позначити вершину чимось. Бул, номер шляху під деяким замовленням тощо.

Після того, як у вас побудована трійка, з’являються алгоритми їх стиснення до оптимального (або майже оптимального) подання. (див. пов'язану статтю у Вікіпедії.)

— Справжній Джон Коннор
джерело

Цікаво. Проте трие має набагато більший набір специфікацій, про які я не дуже переймаюся (швидкий пошук, асоціація з ключем тощо), тому мені цікаво, чи можливо щось краще ...

— Opt

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

Є такі структури для дерев, словники тощо. Я не пригадую жодної, яка б робила саме те, що ви хочете, але, можливо, якась їх комбінація чи модифікація допомогла б вам.

— Якуб Котовський
джерело

Залежно від складності та обробки до / після обробки, необхідних для вашого алгоритму, можливо, найпростішим варіантом є спосіб. Ви можете банально представляти їх як масиви та зберігати їх стислими у форматі HDF5. Ця бібліотека оснащена деякими алгоритмами швидкого стиснення, так що читання та запис стислих даних може бути навіть швидшим, ніж нестиснене.

Ось кілька сюжетів:

Послідовний час доступу на елемент для EArray об'ємом 15 ГБ та різних розмірів:

Швидкість декомпресії за допомогою Blosc на PyTables: введіть тут опис зображення

І якщо вони обмежені по довжині, ви можете зберігати їх у таблиці, і, ймовірно, отримуючи трохи більше місця. І коли ви отримуєте їх з пам'яті, ви вже в дуже зручній формі застосовуєте свій алгоритм.

— Давидм
джерело