Коли списки суміжності або матриці є кращим вибором?


15

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

Спасибі заздалегідь!



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

@Raphael Чи можете ви детальніше розповісти про інші міркування?
користувач21312

1
@ user21312, велика різниця - це ітерабельність та доступ до країв. Якщо вам часто потрібно перебирати краї, то список коригувань може бути кориснішим. Якщо вам часто потрібно визначити, чи існує край чи отримати доступ до його ваги (або іншої інформації), матриця може бути кращою.
ryan

З вашою метою ми, мабуть, могли б недбало ставитись до поняття "рідкісний" та "щільний". Просто змалюйте часову складність операції з матрицею, яку ви хочете використовувати для кожного типу структури даних, і подивіться, де знаходиться "точка розриву щільності". Я думаю, що друге посилання від @ryan намагається зробити щось подібне
Apiwat Chantawibul

Відповіді:


17

Перш за все зауважте, що розріджений означає, що у вас дуже мало ребер, а щільний означає багато ребер або майже повний графік. У повному графіку у вас ребер, де - кількість вузлів.nn(n1)/2n

Тепер, коли ми використовуємо матричне подання, ми виділяємо матрицю для зберігання інформації про з'єднання вузла, наприклад, якщо між вузлами та є край , інакше . Але якщо ми використовуємо список суміжності, то у нас є масив вузлів, і кожен вузол вказує на свій список суміжності, що містить ТОЛЬКІ сусідні вузли .M [ i ] [ j ] = 1 i j M [ i ] [ j ] = 0n×nM[i][j]=1ijM[i][j]=0

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

Але якщо графік щільний, то кількість ребер близько до (повного) , або до якщо графік спрямований з самокрутками. Тоді немає переваги використовувати список суміжності над матрицею.n 2n(n1)/2n2

З точки зору складності
простору Матриця суміжності: Список суміжності: де - кількість вузлів, - кількість ребер.O ( n + m ) n mO(n2)
O(n+m)
nm

Коли дерево є
непрямим деревом, тоді матриця суміжності: Список суміжності: є (краще, ніж )O ( n + n ) O ( n ) n 2O(n2)
O(n+n)O(n)n2

Коли графік спрямований, повний, із самозаймами, тоді
матриця суміжності: Список суміжності: є (різниці немає)O ( n + n 2 ) O ( n 2 )O(n2)
O(n+n2)O(n2)

І нарешті, коли ви реалізуєте за допомогою матриці, перевірка наявності краю між двома вузлами займає разів, тоді як зі списком суміжності це може зайняти лінійний час у .nO(1)n


"Хоча зі списком суміжності, це може зайняти лінійний час". - Враховуючи, що у вашому списку суміжності (ймовірно) немає будь-якого природного порядку, чому це список замість хеш-набору?
Кевін

1
@Kevin Тоді його називали б "хеш суміжності" замість "списку". Також можливо, чому б і ні? Але якщо ви просто зробите DFS або BFS, або якусь іншу процедуру, яка систематично сканує всі вузли, то яка перевага використання хешу над списком? У будь-якому випадку ви оглянете всі сусідні вузли.
fade2black

3
Я додам, що у невагомому непрямому випадку для майже повного графа може бути доцільніше зберігати його доповнення, тобто розріджений графік. Тому матриця корисна, коли є приблизно половина ребер.
М. Зимовий

3

Відповісти, запропонувавши просту аналогію. Якби вам довелося зберігати 6 унцій води, чи не зробили б ви це (взагалі кажучи) з контейнером на 5 галонів або з чашкою 8 унцій?

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

Міркування за списком проти матриці насправді в цьому випадку прості.

PS список справді просто матриця однієї колонки !!! (намагаюся показати вам, наскільки це довільне рішення / сценарій)


2

Розглянемо графік з вузлами та ребрами. Ігноруючи умови низького порядку, бітова матриця для графіка використовує біт незалежно від кількості ребер.E N 2NEN2

Скільки бітів вам насправді потрібно?

Якщо припустити, що краї є незалежними, кількість графіків з вузлами та ребрами дорівнює . Мінімальна кількість бітів, необхідних для зберігання цього підмножини, є .E ( N 2NE журнал2 ( N2)(N2E)log2(N2E)

Будемо вважати без втрати спільності, що , тобто, що половина або менше ребер є. Якщо це не так, ми можемо замість цього зберегти набір "не-ребер".EN22

Якщо , , тож матричне подання є асимптотично оптимальним. Якщо , використовуючи наближення Стірлінга та трохи арифметики, знаходимо:E=N22log2(N2E)=N2+o(N2)EN2

log2(N2E)
=log2(N2)!E!(N2E)!
=2Elog2N+O(low order terms)

Якщо ви вважаєте, що - це розмір цілого числа, яке може представляти індекс вузла, оптимальне представлення - це масив ідентифікаторів вузла, тобто масив пар індексів вузлів.log2N2E

Сказавши це, хорошим показником розрідженості є ентропія, яка також є кількістю бітів на край оптимального подання. Якщо є ймовірність наявності ребра, ентропія . Для ентропія дорівнює 2 (тобто два біти на край в оптимальному поданні), а графік щільний. Якщо ентропія значно більша за 2, і, особливо, якщо вона близька до розміру вказівника, графік є рідким.p=EN2log2p(1p)p12

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.