Які k-кращі алгоритми з найкоротшим шляхом слід враховувати?

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

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

Визначні аспекти моєї проблеми:

• Графік складається приблизно з 160 вершин.

• Графік майже повністю пов'язаний (двосторонній, тому ~ 160 ^ 2 ~ = 25 кром)

• k буде зовсім невеликим (можливо, менше 10)

• Максимальна довжина шляху, ймовірно, буде обмежена і дуже мала (наприклад, 3-5 ребер)

• Я говорив «ациклічно» вище, але просто ще раз - рішення не повинні включати цикли. Це не проблема для 1-кращого найкоротшого шляху, але це стає проблемою для k-best - наприклад, розгляньте дорогу маршруту - другий найкоротший шлях від A до B може бути таким же, як 1-кращий, з швидка поїздка кудись кварталом. Це може бути математично оптимальним, але не дуже корисним рішенням. ;-)

• Можливо, нам буде потрібно повторно зважувати кромки під час кожного обчислення. Крайова вартість складається із зваженої суми кількох факторів, і остаточні вимоги (щоразу, коли ми їх отримуємо) можуть дозволити користувачеві визначити власну пріоритетність цих коефіцієнтів зважування, змінюючи ваги крайових. Це порівняно невеликий графік (ми повинні бути в змозі представити його в декількох сотнях КБ), тому, ймовірно, розумно клонувати графік в пам'яті, застосувати повторне зважування та виконати пошук на клонованому графіку. Але якщо є більш ефективний метод виконання пошуку під час обчислення ваг на ходу, мені цікаво.

Я розглядаю алгоритми, описані в Сантосі (алгоритми найкоротшого шляху K), Eppstein 1997 (Пошук k найкоротших шляхів) та інших. Алгоритм Йєна представляє інтерес насамперед через існуючу реалізацію Java . Мені не страшно читати наукові роботи, але я подумав, що варто викинути деталі моєї проблеми та попросити покажчиків заощадити трохи часу на читання.

А якщо у вас є вказівники на реалізацію Java, ще краще.

Щоб частково відповісти на моє власне питання:

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

Алгоритм Йєна і більшість інших, які я розглядав, залежать від серії найкращих пошуків; більшість використовують Dijkstra для цих проміжних пошуків. Dijkstra не підтримує негативні ваги, але ми можемо замінити Беллмана-Форда на його місце (принаймні, в Єні; імовірно, також у Лоулера або Еппштейна). Я розробив модифікацію Беллмана-Форда з обмеженням довжини шляху (в краях) і чіткої перевірки циклу під час пошуку (замість стандартного детектування циклу після пошуку). Комп'ютерна складність гірша, але все ж простежується для моїх вимог. Я відредагую цю відповідь і посилаюсь на технічний звіт, якщо отримаю дозвіл на його публікацію.

Я б сказав, що це питання може бути легко гугл, а також є дублікатом:

• /programming/12773525/k-shortest-alternative-path-algorithm-java-implementations
• /programming/7208720/finding-kth-shortest-paths

Як було сказано, я вже використовував і впроваджував Еппштейн і рекомендую його. Я вважав це досить елегантним. Якщо я пам'ятаю правильно, це може бути і оптимальним, і наступний документ пояснює це дуже добре:

http://pdf.aminer.org/001/059/121/finding_the_k_shortest_paths.pdf