Існує три способи зберігати графік у пам'яті:
Я знаю, як писати всі три, але не впевнений, що продумав усі переваги та недоліки кожного.
Які переваги та недоліки кожного з цих способів зберігання графіка в пам’яті?
Відповіді:
Один із способів проаналізувати це - з точки зору складності пам’яті та часу (що залежить від того, як ви хочете отримати доступ до графіка).
Зберігання вузлів як об’єктів із вказівниками один на одного
Зберігання матриці крайових ваг
Залежно від того, який алгоритм ви запускаєте на графіку, і скільки вузлів є, вам доведеться вибрати відповідне подання.
Ще кілька речей, які слід врахувати:
Матрична модель легше піддається графікам із зваженими краями, зберігаючи ваги в матриці. Модель об'єкта / вказівника повинна зберігати ваги країв у паралельному масиві, що вимагає синхронізації з масивом вказівника.
Модель об’єкта / вказівника працює краще з направленими графіками, ніж з неорієнтованими графіками, оскільки вказівники повинні підтримуватися парами, які можуть стати несинхронізованими.
Як зазначають деякі, метод "об'єкти та вказівники" страждає від труднощів пошуку, але цілком природний для таких речей, як побудова бінарних дерев пошуку, де є багато зайвої структури.
Я особисто люблю матриці суміжності, оскільки вони значно полегшують всілякі задачі, використовуючи інструменти з алгебраїчної теорії графів. (K-та ступінь матриці суміжності дає кількість шляхів довжиною k від вершини i до вершини j, наприклад. Додайте матрицю ідентичності, перш ніж приймати k-ту степінь, щоб отримати кількість шляхів довжиною <= k. Візьміть ранг n-1 мінор лапласіанця, щоб отримати кількість розкритих дерев ... І так далі.)
Але всі кажуть, що матриці суміжності дорого пам’яті! Вони лише наполовину праві: Ви можете обійти це за допомогою розріджених матриць, коли у вашого графіка мало ребер. Розріджені матричні структури даних роблять саме роботу, просто зберігаючи список суміжностей, але все ще мають повну гаму стандартних матричних операцій, що дає вам найкраще з обох світів.
Я думаю, що ваш перший приклад трохи неоднозначний - вузли як об’єкти, а ребра як вказівники. Ви можете відстежувати їх, зберігаючи лише вказівник на якийсь кореневий вузол, і в цьому випадку доступ до даного вузла може бути неефективним (скажімо, ви хочете вузол 4 - якщо об’єкт вузла не наданий, можливо, доведеться його шукати) . У цьому випадку ви також втратите частини графіку, недоступні з кореневого вузла. Я думаю, що це той випадок, коли припускає f64 rainbow, коли він каже, що складність часу для доступу до даного вузла становить O (n).
В іншому випадку ви також можете зберегти масив (або хеш-карту), повний покажчиків на кожен вузол. Це дозволяє O (1) отримати доступ до даного вузла, але трохи збільшує використання пам'яті. Якщо n - кількість вузлів, а e - кількість ребер, просторова складність цього підходу буде O (n + e).
Складність простору для матричного підходу буде уздовж лінії O (n ^ 2) (припускаючи, що ребра односпрямовані). Якщо ваш графік розріджений, у вашій матриці буде багато порожніх комірок. Але якщо ваш графік повністю зв’язаний (e = n ^ 2), це вигідно порівняно з першим підходом. Як каже RG, у вас також може бути менше помилок кеш-пам’яті при такому підході, якщо ви виділите матрицю як один шматок пам’яті, що може зробити швидше дотримання багатьох ребер навколо графіка.
Третій підхід є, мабуть, найефективнішим у більшості випадків - O (e) - але робить пошук усіх країв даного вузла клопотом O (e). Я не можу подумати про випадок, коли це було б дуже корисно.
Погляньте на порівняльну таблицю у Вікіпедії. Це дає досить хороше розуміння того, коли використовувати кожне представлення графіків.
Існує ще один варіант: вузли як об’єкти, ребра як об’єкти теж, при цьому кожне ребро одночасно знаходиться у двох подвійно пов’язаних списках: список усіх ребер, що виходять з одного вузла, і список усіх ребер, що йдуть в один вузол .
struct Node {
... node payload ...
Edge *first_in; // All incoming edges
Edge *first_out; // All outgoing edges
};
struct Edge {
... edge payload ...
Node *from, *to;
Edge *prev_in_from, *next_in_from; // dlist of same "from"
Edge *prev_in_to, *next_in_to; // dlist of same "to"
};
Накладні витрати на пам’ять великі (2 вказівники на вузол і 6 вказівників на ребро), але ви отримуєте
Структура також може представляти досить загальний графік: орієнтований мультиграф з циклами (тобто ви можете мати кілька різних ребер між однаковими двома вузлами, включаючи безліч різних петель - ребра, що йдуть від x до x).
Більш детальне пояснення цього підходу доступне тут .
Добре, так що якщо ребра не мають ваг, матриця може бути двійковим масивом, і використання двійкових операторів може змусити справи йти дуже, дуже швидко в такому випадку.
Якщо графік розріджений, метод об’єкта / покажчика здається набагато ефективнішим. Утримання об’єкта / покажчиків у структурі даних, спеціально для того, щоб переконувати їх в один шматок пам'яті, також може бути хорошим планом або будь-яким іншим способом змусити їх залишатися разом.
Список суміжності - просто перелік підключених вузлів - здається на сьогоднішній день найбільш ефективним, але, мабуть, і найповільнішим.
Повернути спрямований графік легко за допомогою представлення матриці та легко за допомогою списку суміжностей, але не так добре з поданням об’єкта / покажчика.