2009-03-23 5 views
11

Tôi đã chơi đùa với một số thứ và nghĩ ra ý tưởng cố gắng tìm ra số Kevin Bacon. Tôi có dữ liệu cho một trang web cho mục đích này chúng ta có thể xem xét một mạng xã hội. Hãy giả vờ rằng đó là Facebook (để đơn giản hóa thảo luận). Tôi có người và tôi có một danh sách bạn bè của họ, vì vậy tôi có mối liên hệ giữa họ. Làm thế nào tôi có thể tính toán khoảng cách từ một người khác (về cơ bản, một số Kevin Bacon)?Tính số "Kevin Bacon"

Ý tưởng hay nhất của tôi là Bidirectional search, với giới hạn chiều sâu (để giới hạn độ phức tạp tính toán và tránh vấn đề của những người không thể kết nối trong biểu đồ), nhưng tôi nhận ra đây là lực mạnh. Có thể tốt hơn nếu tạo ít đồ thị phụ (nói điều gì đó tương đương với các nhóm trên Facebook), tính khoảng cách ngắn nhất giữa chúng (trước thời hạn, có lẽ) và sau đó thử sử dụng THOSE để tìm một liên kết? Trong khi điều này đòi hỏi tính toán trước, nó có thể làm cho nó có thể tìm kiếm nhiều nút ít hơn (các nút có thể là các nhóm thay vì cá nhân, làm cho đồ thị nhỏ hơn nhiều). Tuy nhiên, đây vẫn là một tìm kiếm hai chiều.

Tôi cũng có thể tính toán trước số lượng cá nhân được kết nối, tìm kiếm nút cho những người "phổ biến" trước tiên vì họ có cơ hội kết nối tốt nhất với cá nhân đích nhất định. Tôi nhận ra đây sẽ là một sự cân bằng tốc độ cho con đường ngắn nhất có thể. Tôi nghĩ rằng tôi cũng muốn sử dụng một tìm kiếm chiều sâu đầu tiên thay vì tìm kiếm rộng đầu tiên tôi dự định sử dụng trong các trường hợp khác.

Ai đó có thể nghĩ ra cách đơn giản/nhanh hơn để thực hiện việc này? Tôi muốn có thể tìm thấy chiều dài ngắn nhất giữa hai người, do đó, nó không phải dễ dàng như luôn luôn có cùng một điểm kết thúc (chẳng hạn như trong vấn đề Kevin Bacon).

Tôi nhận ra rằng có những vấn đề như tôi có thể nhận được chuỗi 200 người và như vậy, nhưng điều đó có thể giải quyết được việc tôi có giới hạn về chiều sâu mà tôi sẵn sàng tìm kiếm.

+0

BTW, vì đây không phải là về phim, không có lý do thuyết phục để gọi nó là số Kevin Bacon thay vì số quen thuộc hơn (đối với một số ;-)) Erdős: http://en.wikipedia.org/wiki/Erdos_number – ShreevatsaR

+0

Tôi thấy thuật ngữ đó trong khi thực hiện một số nghiên cứu, nhưng bằng cách gọi nó là số Kevin Bacon, mọi người đều biết ngay những gì tôi đang nói. Tôi nghĩ rằng sẽ cắt giảm việc giải thích. – MBCook

+0

"mức độ tách" cũng sẽ có ý nghĩa –

Trả lời

17

Đây là tiêu chuẩn shortest path problem. Có rất nhiều giải pháp, bao gồm Dijkstra's algorithmBellman-Ford. Bạn có thể đặc biệt quan tâm đến việc xem xét A* algorithm và xem nó sẽ hoạt động như thế nào với hàm chi phí liên quan đến nghịch đảo của bất kỳ mức độ nút cụ thể nào. Ý tưởng sẽ là ghé thăm các nút phổ biến hơn (những người có trình độ cao hơn) trước tiên.

+1

+1 Như tôi đã đề cập sau khi suy nghĩ về mọi thứ trong một vài phút, Dijkstra và Bellman-Ford sẽ giảm xuống thành một tìm kiếm đơn giản đầu tiên khi trọng lượng cạnh là tất cả 1. A * đáng xem, vì nó bổ sung thêm heuristic . Kết hợp với độ sâu giới hạn, nó có thể là tốt nhất bạn có thể nhận được. –

+0

A * có lẽ là tồi tệ nhất trong ba loại tìm kiếm này vì nó chỉ trả về nút gần nhất với heuristic, trong khi thuật toán Dijkstra trả về bất kỳ nút nào gần nhất (nút đầu tiên tìm thấy). Và do đó có thể được thực hiện sớm hơn bởi vì bạn không tìm kiếm bất cứ điều gì cụ thể. –

+1

@Jasper - trực giác sẽ là những con đường ngắn nhất có xu hướng đi qua các nút được kết nối tốt - đây sẽ là giả thuyết để kiểm tra. Nếu đúng, các heuristic sẽ cung cấp cho bạn con đường ngắn nhất sớm hơn dẫn bạn để có thể chấm dứt con đường tiềm năng khác (không ngắn nhất) trước đó. – tvanfosson

4

Có vẻ như một công việc cho Dijkstra's algorithm.

ED: Eh, tôi không nên bóp cò quá nhanh. Dijkstra's (và Bellman-Ford) giảm xuống mức tìm kiếm rộng rãi khi trọng lượng là 1, vì vậy điều này không hữu ích. Oh well.

A* algorithm, được đề cập bởi tvanfosson, có thể lý tưởng cho việc này. Ý tưởng là thay vì tìm kiếm và đệ quy theo thứ tự các phần tử ở mỗi cấp độ của cây (bắt nguồn từ điểm bắt đầu hoặc điểm kết thúc), bạn sử dụng một số heuristic để xác định yếu tố nào bạn sẽ thử trước. Trong trường hợp của bạn, đặt cược tốt có thể là mức của một nút (số "bạn bè"), nhưng bạn có thể muốn sử dụng số lượng người trong một số độ tùy ý của một người cụ thể (tức là, người có có ba người bạn, mỗi người có 100 người bạn có khả năng là một nút tốt hơn so với người có 20 người bạn trong một clique mà shun bên ngoài). Có rất nhiều thứ khác bạn có thể sử dụng như một heuristic (bạn bè có 2 điểm, bạn bè của bạn bè có được 1 điểm, bất cứ điều gì, thử nghiệm).

Kết hợp điều này với giới hạn chiều sâu (cắt sau 6 độ tách hoặc bất kỳ thứ gì) và bạn có thể cải thiện đáng kể trường hợp trung bình của mình (trường hợp xấu nhất vẫn giống như BFS cơ bản).

+0

Đồng ý, tôi đã sử dụng Dijkstra để giải quyết vấn đề Kevin Bacon. – sfossen

+0

có vấn đề gì với BFS? Tôi nghi ngờ nó có thể được thực hiện nhanh hơn ... –

+0

Không có gì sai với nó. Tuy nhiên, nếu bạn muốn giới hạn độ sâu, khoảng 6 độ tách, có nghĩa là sử dụng một số loại phỏng đoán để xác định nút nào sẽ xem tiếp theo trong tìm kiếm rộng đầu tiên của bạn (ví dụ: A *). –

0

chạy một tìm kiếm theo chiều rộng theo cả hai hướng (từ mỗi thiết bị đầu cuối) và dừng lại khi bạn có kết nối hoặc đạt đến giới hạn chiều sâu của bạn

+0

Tốt hơn so với A * trong trường hợp này vì hàm ước tính có thể không có sẵn. – Joshua

0

Cái này có thể là tốt hơn tổng thể Floyd-Warshall các tất cả các cặp khoảng cách ngắn nhất.