Những thuật toán đường dẫn ngắn nhất nào tốt nhất tôi nên xem xét?


13

Tôi đang giải quyết vấn đề tối ưu hóa tìm kiếm đồ thị. Tôi cần tìm k đường đi ngắn nhất theo chu kỳ tốt nhất thông qua biểu đồ có trọng số theo hướng.

Tôi biết có một số thuật toán k-best chính xác và gần đúng, nhưng hầu hết các nghiên cứu gần đây dường như được định hướng theo các biểu đồ rất lớn, được kết nối rất thưa thớt (ví dụ: định tuyến và chỉ đường), và biểu đồ của tôi cũng không.

Phân biệt các khía cạnh của vấn đề của tôi:

  • Biểu đồ bao gồm khoảng 160 đỉnh.

  • Biểu đồ được kết nối gần như hoàn toàn (hai chiều, vì vậy ~ 160 ^ 2 ~ = 25k cạnh)

  • k sẽ khá nhỏ (có thể dưới 10)

  • Độ dài đường dẫn tối đa có thể sẽ bị giới hạn và cũng rất nhỏ (ví dụ: 3-5 cạnh)

  • Tôi đã nói 'acyclic' ở trên, nhưng chỉ để nhắc lại - các giải pháp không được bao gồm các chu kỳ. Đây không phải là vấn đề đối với đường đi ngắn nhất 1 lần, nhưng nó trở thành vấn đề đối với đường dẫn tốt nhất - ví dụ: hãy xem xét tuyến đường - đường đi ngắn thứ 2 từ A đến B có thể giống với đường 1 tốt nhất, với một chuyến đi nhanh chóng xung quanh một khối ở đâu đó. Đó có thể là tối ưu về mặt toán học, nhưng không phải là một giải pháp rất hữu ích. ;-)

  • Chúng tôi có thể cần phải cân lại các cạnh khi đang di chuyển cho mỗi phép tính. Chi phí cạnh bao gồm tổng trọng số của một số yếu tố và các yêu cầu cuối cùng (bất cứ khi nào chúng tôi nhận được) có thể cho phép người dùng chỉ định mức độ ưu tiên của riêng họ đối với các yếu tố trọng số đó, thay đổi trọng số cạnh. Đây là một biểu đồ tương đối nhỏ (chúng ta sẽ có thể biểu thị nó trong vài trăm KB), vì vậy có thể hợp lý để sao chép biểu đồ trong bộ nhớ, áp dụng trọng số lại và sau đó thực hiện tìm kiếm trên biểu đồ nhân bản. Nhưng nếu có một phương pháp hiệu quả hơn để thực hiện tìm kiếm trong khi tính toán trọng lượng một cách nhanh chóng, tôi quan tâm.

Tôi đang xem xét các thuật toán được mô tả trong Santos (thuật toán đường đi ngắn nhất K), Eppstein 1997 (Tìm đường đi k ngắn nhất) và các thuật toán khác. Thuật toán của Yen được quan tâm, chủ yếu là do triển khai Java hiện có . Tôi không sợ đọc các tài liệu nghiên cứu, nhưng tôi nghĩ rằng nó đáng để bỏ qua các chi tiết về vấn đề của tôi và yêu cầu con trỏ để tiết kiệm thời gian đọc.

Và nếu bạn có con trỏ để triển khai Java, thậm chí tốt hơn.


+1, vì tôi quan tâm đến những gợi ý mà mọi người có, và đây có vẻ như là loại câu hỏi chính xác mà trang web này được đưa ra.
KChaloux

Không phải điều kiện chu kỳ của bạn có nghĩa là BẤT K path con đường nào khác từ đầu đến mục tiêu sẽ tạo ra chu kỳ với đường dẫn đầu tiên? Và nếu cả hai bắt đầu và mục tiêu là trong hẻm mù, mọi con đường phải sử dụng hai cạnh này.
user470365

Có lẽ tôi đã không rõ ràng. Ràng buộc theo chu kỳ chỉ áp dụng cho một đường dẫn duy nhất - một cách tự nhiên, bất kỳ 2 đường dẫn riêng biệt nào từ A đến B sẽ tạo thành một chu kỳ.
AaronD

@AaronD: vậy, cuối cùng bạn đã sử dụng cái nào?
dagnelies

@arnaud: Tôi không chắc chắn tôi đã giải quyết được một thuật toán chưa; Tôi sẽ thêm một bản cập nhật cho câu hỏi này khi tôi có. Tôi đã loại bỏ Eppstein vì nó không đảm bảo các giải pháp theo chu kỳ (hay còn gọi là 'đơn giản'). Tôi hiện đang làm việc với thuật toán của Yen, nhưng tôi chưa nhận được hồ sơ chi tiết hoặc tối ưu hóa, vì vậy tôi có thể phải thay thế nó bằng thuật toán khác. Tôi sẽ cập nhật trong một hoặc hai tuần tới.
AaronD

Câu trả lời:


2

Để trả lời một phần câu hỏi của riêng tôi:

Kể từ khi đăng câu hỏi này, tôi phát hiện ra rằng chúng ta cần xử lý các trọng số cạnh âm cũng như dương (giới hạn đối với các đường đi vòng / đơn giản / không vòng lặp có nghĩa là giải pháp tốt nhất được xác định, trong khi đó không giới hạn đường đi ngắn nhất qua biểu đồ có âm chu kỳ chi phí là không xác định).

Thuật toán của Yen và hầu hết các thuật toán khác mà tôi đã kiểm tra, phụ thuộc vào một loạt các tìm kiếm tốt nhất; hầu hết sử dụng Dijkstra cho những tìm kiếm trung gian. Dijkstra không hỗ trợ trọng số cạnh âm, nhưng chúng ta có thể thay thế Bellman-Ford ở vị trí của nó (ít nhất là ở Yen; có lẽ là ở Lawler hoặc Eppstein). Tôi đã phát triển một bản sửa đổi của Bellman-Ford với giới hạn độ dài đường dẫn (tính theo các cạnh) và kiểm tra chu kỳ rõ ràng trong quá trình tìm kiếm (thay cho phát hiện chu kỳ sau tìm kiếm tiêu chuẩn). Sự phức tạp tính toán là tồi tệ hơn, nhưng vẫn có thể dễ dàng cho các yêu cầu của tôi. Tôi sẽ chỉnh sửa phản hồi này và liên kết đến một báo cáo công nghệ nếu tôi được phép đăng nó.


1

Tôi muốn nói rằng câu hỏi này có thể dễ dàng bị googled và cũng là một bản sao:

Điều đó đang được nói, tôi đã sử dụng và thực hiện Eppstein và giới thiệu nó. Tôi thấy nó khá thanh lịch. Nếu tôi nhớ đúng, nó cũng có thể là tối ưu, và bài báo sau đây giải thích nó rất độc đáo:

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


Đầu tiên, cảm ơn lời giới thiệu của Eppstein. Tôi sẽ tìm kiếm nhiều hơn ở đó. Tôi cho rằng đây không phải là một bản sao chính xác, cũng không dễ để google; thật dễ dàng để tìm ra một thuật toán tốt nhất, nhưng không dễ để lựa chọn hợp lý giữa chúng. Tôi hy vọng tôi muốn một thuật toán rất khác nhau cho một biểu đồ được kết nối thưa thớt gồm hàng triệu đỉnh so với tôi sẽ giải quyết vấn đề này. Tôi sẽ quan tâm nhiều hơn về độ phức tạp trong k nếu tôi muốn 1000 tốt nhất thay vì 10 tốt nhất. Và, trong khi các yếu tố không đổi không quan trọng khi xuất bản giấy tờ, chúng chắc chắn là khi vận chuyển mã sản xuất.
AaronD

@AaronD: chỉ cần thông tin của bạn, tôi nghĩ thuật toán rất hiệu quả cho dù thế nào đi nữa. Có lẽ có những trường hợp đặc biệt trong đó các tìm kiếm theo hướng heuristic đánh bại nó, nhưng đối với trường hợp chung, tôi nghĩ rằng nó làm rất tốt. Hiệu suất chính xác có thể sẽ phụ thuộc nhiều hơn vào cách bạn thực hiện chính xác, hiệu quả của cơ sở dữ liệu của bạn và mức độ phù hợp với vấn đề của bạn.
dagnelies

@arnaud Xin chào, bạn có thể chia sẻ việc triển khai eppstein của mình không? Tôi có một câu hỏi tương tự được đăng ở đây: math.stackexchange.com/questions/1661737/NH
Tina J
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.