Чому в алгоритмі Дейкстри використовується клавіша зменшення?

Алгоритм Дейкстри мене навчили таким чином

while pqueue is not empty:
    distance, node = pqueue.delete_min()
    if node has been visited:
        continue
    else:
        mark node as visited
    if node == target:
        break
    for each neighbor of node:
         pqueue.insert(distance + distance_to_neighbor, neighbor)

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

Чому це відбувається, і в чому різниця між двома підходами?

Причиною використання клавіші зменшення, а не повторного вставлення вузлів, є збереження невеликої кількості вузлів у черзі пріоритетів, таким чином, загальна кількість вилучень черг пріоритетів невелика, а вартість кожного балансу черги пріоритетів низькою.

У реалізації алгоритму Дейкстри, який повторно вставляє вузли в чергу пріоритетів зі своїми новими пріоритетами, один вузол додається до черги пріоритетів для кожного з m ребер на графіку. Це означає, що в пріоритетній черзі є m операцій черги та m операцій виведення черги, що дає загальний час виконання O (m T _e + m T _d ), де T _e - час, необхідний для черги в пріоритетну чергу, а T _d - час, необхідний для зняття з черги пріоритетів.

У реалізації алгоритму Дейкстри, який підтримує клавішу зменшення, пріоритетна черга, що утримує вузли, починається з n вузлів у ній, і на кожному кроці алгоритму видаляється по одному вузлу. Це означає, що загальна кількість декуерів купи є n. Кожен вузол буде мати натиснутий клавішу зменшення потенційно один раз для кожного ребра, що в нього входить, тому загальна кількість виконаних клавіш зменшення становить не більше m. Це дає час виконання (n T _e + n T _d + m T _k ), де T _k - час, необхідний для виклику клавіші зменшення.

То який вплив це впливає на час роботи? Це залежить від того, яку чергу пріоритетів ви використовуєте. Ось коротка таблиця, яка показує різні черги пріоритетів та загальний час виконання різних алгоритмів реалізації Дейкстри:

Queue          |  T_e   |  T_d   |  T_k   | w/o Dec-Key |   w/Dec-Key
---------------+--------+--------+--------+-------------+---------------
Binary Heap    |O(log N)|O(log N)|O(log N)| O(M log N)  |   O(M log N)
Binomial Heap  |O(log N)|O(log N)|O(log N)| O(M log N)  |   O(M log N)
Fibonacci Heap |  O(1)  |O(log N)|  O(1)  | O(M log N)  | O(M + N log N)

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

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

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

Сподіваюся, це допомагає!

У 2007 році було опубліковано статтю, яка вивчала різницю у часі виконання між використанням версії із зменшувальним ключем та версії для вставки. Див. Http://www.cs.utexas.edu/users/shaikat/papers/TR-07-54.pdf

Їх основним висновком було не використовувати клавішу зменшення для більшості графіків. Особливо для розріджених графіків ключ без зменшення значно швидший, ніж версія із зменшенням. Докладніше див. У статті.

Існує два способи реалізації Dijkstra: один використовує купу, що підтримує клавішу зменшення, а інший купу, яка цього не підтримує.

Вони обидва є дійсними загалом, але останньому зазвичай надають перевагу. Далі я буду використовувати 'm' для позначення кількості ребер, а 'n' для позначення кількості вершин нашого графіка:

Якщо ви хочете якнайкраще ускладнити найгірший випадок, вам слід скористатися купою Фібоначчі, яка підтримує клавішу зменшення: ви отримаєте гарний O (m + nlogn).

Якщо ви дбаєте про середній випадок, ви можете також скористатися купою двійкових файлів: ви отримаєте O (m + nlog (m / n) logn). Доказ - тут , сторінки 99/100. Якщо графік щільний (m >> n), і цей, і попередній прагнуть до O (m).

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

Результати експериментів покажуть, що «простіша» купа дасть найкращі результати в більшості випадків.

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

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