Điều gì là tốt hơn, danh sách kề hoặc ma trận kề cho các vấn đề đồ thị trong C ++?

Điều gì là tốt hơn, danh sách kề hoặc ma trận kề, cho các vấn đề đồ thị trong C ++? Những lợi thế và bất lợi của mỗi là gì?

Nó phụ thuộc vào vấn đề.

Ma trận kề

• Sử dụng bộ nhớ O (n ^ 2)
• Thật nhanh chóng để tra cứu và kiểm tra sự hiện diện hay vắng mặt của một cạnh cụ thể
  giữa bất kỳ hai nút O (1) nào
• Nó chậm để lặp lại trên tất cả các cạnh
• Thật chậm để thêm / xóa một nút; một hoạt động phức tạp O (n ^ 2)
• Thật nhanh chóng để thêm một cạnh mới O (1)

Danh sách điều chỉnh

• Việc sử dụng bộ nhớ phụ thuộc vào số cạnh (không phải số nút),
  có thể tiết kiệm rất nhiều bộ nhớ nếu ma trận kề là thưa thớt
• Tìm sự hiện diện hoặc vắng mặt của cạnh cụ thể giữa hai nút bất kỳ
  chậm hơn một chút so với ma trận O (k); Trong đó k là số nút lân cận
• Nó nhanh chóng lặp đi lặp lại trên tất cả các cạnh vì bạn có thể truy cập trực tiếp vào bất kỳ nút lân cận nút nào
• Thật nhanh chóng để thêm / xóa một nút; dễ dàng hơn so với biểu diễn ma trận
• Thật nhanh chóng để thêm một cạnh mới O (1)

Câu trả lời này không chỉ dành cho C ++ vì mọi thứ được đề cập là về chính cấu trúc dữ liệu, bất kể ngôn ngữ. Và, câu trả lời của tôi là giả sử rằng bạn biết cấu trúc cơ bản của danh sách kề và ma trận.

Ký ức

Nếu bộ nhớ là mối quan tâm chính của bạn, bạn có thể làm theo công thức này cho một biểu đồ đơn giản cho phép các vòng lặp:

Một ma trận kề là chiếm không gian ^2/8 byte (một bit cho mỗi mục nhập).

Một danh sách kề chiếm không gian 8e, trong đó e là số cạnh (máy tính 32 bit).

Nếu chúng ta xác định mật độ của biểu đồ là d = e / n ² (số cạnh chia cho số cạnh tối đa), chúng ta có thể tìm thấy "điểm dừng" trong đó danh sách chiếm nhiều bộ nhớ hơn ma trận:

8e> n ² /8 khi d> 1/64

Vì vậy, với những con số này (vẫn là 32 bit cụ thể), điểm dừng ở 1/64 . Nếu mật độ (e / n ² ) lớn hơn 1/64, thì nên sử dụng ma trận nếu bạn muốn tiết kiệm bộ nhớ.

Bạn có thể đọc về điều này tại wikipedia (bài viết về ma trận kề) và rất nhiều trang web khác.

Lưu ý bên lề : Người ta có thể cải thiện hiệu quả không gian của ma trận kề bằng cách sử dụng bảng băm trong đó các khóa là các cặp đỉnh (chỉ vô hướng).

Lặp lại và tra cứu

Danh sách điều chỉnh là một cách nhỏ gọn chỉ đại diện cho các cạnh hiện có. Tuy nhiên, điều này đi kèm với chi phí có thể tìm kiếm chậm các cạnh cụ thể. Vì mỗi danh sách miễn là mức độ của một đỉnh, thời gian tra cứu trường hợp xấu nhất để kiểm tra một cạnh cụ thể có thể trở thành O (n), nếu danh sách không có thứ tự. Tuy nhiên, việc tìm kiếm các lân cận của một đỉnh trở nên tầm thường và đối với một biểu đồ thưa thớt hoặc nhỏ, chi phí lặp lại qua các danh sách kề có thể không đáng kể.

Mặt khác, ma trận điều chỉnh sử dụng nhiều không gian hơn để cung cấp thời gian tra cứu liên tục. Vì mỗi mục có thể tồn tại, bạn có thể kiểm tra sự tồn tại của một cạnh trong thời gian không đổi bằng cách sử dụng các chỉ mục. Tuy nhiên, tra cứu hàng xóm mất O (n) vì bạn cần kiểm tra tất cả các hàng xóm có thể. Hạn chế không gian rõ ràng là đối với các biểu đồ thưa thớt, rất nhiều phần đệm được thêm vào. Xem các cuộc thảo luận về bộ nhớ ở trên để biết thêm thông tin về điều này.

Nếu bạn vẫn không chắc chắn nên sử dụng cái gì : Hầu hết các vấn đề trong thế giới thực tạo ra các biểu đồ thưa thớt và / hoặc lớn, phù hợp hơn cho các biểu diễn danh sách kề. Chúng có vẻ khó thực hiện hơn nhưng tôi đảm bảo với bạn rằng chúng không phải và khi bạn viết BFS hoặc DFS và muốn tìm nạp tất cả hàng xóm của một nút thì chúng chỉ cách một dòng mã. Tuy nhiên, lưu ý rằng tôi không quảng bá danh sách kề.

Được rồi, tôi đã biên soạn độ phức tạp Thời gian và Không gian của các hoạt động cơ bản trên biểu đồ.
Hình ảnh dưới đây nên tự giải thích.
Lưu ý cách Ma trận điều chỉnh thích hợp hơn khi chúng ta kỳ vọng biểu đồ sẽ dày đặc và cách Danh sách điều chỉnh thích hợp hơn khi chúng ta mong đợi biểu đồ sẽ thưa thớt.
Tôi đã đưa ra một số giả định. Hỏi tôi nếu một sự phức tạp (Thời gian hoặc Không gian) cần làm rõ. (Ví dụ: Đối với một biểu đồ thưa thớt, tôi đã coi En là một hằng số nhỏ, vì tôi đã giả sử rằng việc thêm một đỉnh mới sẽ chỉ thêm một vài cạnh, bởi vì chúng tôi hy vọng biểu đồ vẫn còn thưa thớt ngay cả sau khi thêm đỉnh.)

Xin vui lòng cho tôi biết nếu có bất kỳ sai lầm.

Nó phụ thuộc vào những gì bạn đang tìm kiếm.

Với ma trận kề, bạn có thể trả lời nhanh các câu hỏi liên quan đến việc nếu một cạnh cụ thể giữa hai đỉnh thuộc về biểu đồ và bạn cũng có thể có các phần chèn và xóa nhanh các cạnh. Các nhược điểm là bạn phải sử dụng không gian quá nhiều, đặc biệt đối với đồ thị với nhiều đỉnh, đó là rất không hiệu quả đặc biệt là nếu đồ thị của bạn là thưa thớt.

Mặt khác, với các danh sách kề , khó kiểm tra xem một cạnh đã cho có nằm trong biểu đồ hay không, bởi vì bạn phải tìm kiếm qua danh sách thích hợp để tìm cạnh, nhưng chúng hiệu quả hơn về không gian.

Nói chung, mặc dù, danh sách kề là cấu trúc dữ liệu phù hợp cho hầu hết các ứng dụng của đồ thị.

Giả sử chúng ta có một đồ thị có n số nút và m số cạnh,

Biểu đồ ví dụ

Ma trận điều chỉnh: Chúng tôi đang tạo một ma trận có n số hàng và cột để trong bộ nhớ, nó sẽ chiếm không gian tỷ lệ với n ² . Kiểm tra nếu hai nút có tên là u và v có cạnh giữa chúng sẽ mất (1) thời gian. Ví dụ: kiểm tra (1, 2) là một cạnh sẽ trông như sau trong mã:

if(matrix[1][2] == 1)

Nếu bạn muốn xác định tất cả các cạnh, bạn phải lặp lại ma trận tại đây sẽ yêu cầu hai vòng lặp lồng nhau và sẽ mất (n ² ). (Bạn chỉ có thể sử dụng phần tam giác trên của ma trận để xác định tất cả các cạnh nhưng nó sẽ lại (n ² ))

Danh sách điều chỉnh: Chúng tôi đang tạo một danh sách mà mỗi nút cũng trỏ đến một danh sách khác. Danh sách của bạn sẽ có n phần tử và mỗi phần tử sẽ trỏ đến một danh sách có số mục bằng với số hàng xóm của nút này (nhìn hình ảnh để hiển thị rõ hơn). Vì vậy, nó sẽ chiếm không gian trong bộ nhớ tỷ lệ với n + m . Kiểm tra xem (u, v) là một cạnh sẽ mất thời gian O (deg (u)) trong đó deg (u) bằng số hàng xóm của u. Bởi vì nhiều nhất, bạn phải lặp đi lặp lại danh sách được chỉ bởi u. Xác định tất cả các cạnh sẽ mất Θ (n + m).

Danh sách điều chỉnh của đồ thị ví dụ

Bạn nên lựa chọn theo nhu cầu của bạn. Vì danh tiếng của tôi, tôi không thể đặt hình ảnh của ma trận, xin lỗi vì điều đó

Nếu bạn đang xem phân tích biểu đồ trong C ++, có lẽ nơi đầu tiên để bắt đầu sẽ là thư viện biểu đồ boost , nơi thực hiện một số thuật toán bao gồm BFS.

• Tài liệu thư viện Boost

BIÊN TẬP

Câu hỏi trước đây về SO có thể sẽ giúp:

how-to-created-ac-boost-undirected-graph-and-traverse-it-in-deep-First-searc h

Điều này được trả lời tốt nhất với các ví dụ.

Hãy nghĩ về Floyd-Warshall chẳng hạn. Chúng ta phải sử dụng ma trận kề, nếu không thuật toán sẽ chậm hơn.

Hoặc nếu đó là một biểu đồ dày đặc trên 30.000 đỉnh thì sao? Sau đó, một ma trận kề có thể có ý nghĩa, vì bạn sẽ lưu trữ 1 bit cho mỗi cặp đỉnh, thay vì 16 bit trên mỗi cạnh (mức tối thiểu mà bạn cần cho danh sách kề): đó là 107 MB, thay vì 1,7 GB.

Nhưng đối với các thuật toán như DFS, BFS (và những thuật toán sử dụng nó, như Edmonds-Karp), tìm kiếm ưu tiên đầu tiên (Dijkstra, Prim, A *), v.v., một danh sách kề là tốt như một ma trận. Chà, một ma trận có thể có một cạnh nhỏ khi đồ thị dày đặc, nhưng chỉ bởi một yếu tố không đổi không đáng kể. (Bao nhiêu? Đó là vấn đề thử nghiệm.)

Để thêm vào câu trả lời của keyer5053 về việc sử dụng bộ nhớ.

Đối với bất kỳ đồ thị có hướng nào, một ma trận kề (tại 1 bit trên mỗi cạnh) sẽ tiêu tốn n^2 * (1)bit của bộ nhớ.

Đối với một biểu đồ hoàn chỉnh , một danh sách kề (với con trỏ 64 bit) sẽ tiêu tốn n * (n * 64)bit của bộ nhớ, không bao gồm chi phí danh sách.

Đối với một biểu đồ không đầy đủ, một danh sách kề sẽ tiêu tốn 0bit của bộ nhớ, không bao gồm chi phí danh sách.

Đối với danh sách kề, bạn có thể sử dụng công thức sau để xác định số cạnh tối đa ( e) trước khi ma trận kề là tối ưu cho bộ nhớ.

edges = n^2 / sđể xác định số cạnh tối đa, skích thước con trỏ của nền tảng ở đâu.

Nếu biểu đồ của bạn được cập nhật động, bạn có thể duy trì hiệu quả này với số cạnh trung bình (trên mỗi nút) là n / s.

Một số ví dụ với con trỏ 64 bit và biểu đồ động (Biểu đồ động cập nhật giải pháp cho vấn đề một cách hiệu quả sau khi thay đổi, thay vì tính toán lại từ đầu mỗi lần sau khi thay đổi được thực hiện.)

Đối với đồ thị có hướng, trong đó nlà 300, số cạnh tối ưu trên mỗi nút sử dụng danh sách kề là:

= 300 / 64
= 4

Nếu chúng ta cắm công thức này vào công thức của keyer5053, d = e / n^2(trong đó etổng số cạnh), chúng ta có thể thấy chúng ta ở dưới điểm ngắt ( 1 / s):

d = (4 * 300) / (300 * 300)
d < 1/64
aka 0.0133 < 0.0156

Tuy nhiên, 64 bit cho một con trỏ có thể là quá mức cần thiết. Thay vào đó, nếu bạn sử dụng số nguyên 16 bit làm điểm bù con trỏ, chúng ta có thể khớp tối đa 18 cạnh trước khi ngắt điểm.

= 300 / 16
= 18

d = ((18 * 300) / (300^2))
d < 1/16
aka 0.06 < 0.0625

Mỗi ví dụ này bỏ qua chi phí chung của danh sách kề ( 64*2đối với một con trỏ vectơ và 64 bit).

Tùy thuộc vào việc triển khai Ma trận điều chỉnh, 'n' của biểu đồ nên được biết trước để triển khai hiệu quả. Nếu đồ thị quá động và yêu cầu mở rộng ma trận mọi lúc và sau đó điều đó cũng có thể được tính là nhược điểm?

Nếu bạn sử dụng bảng băm thay vì ma trận kề hoặc danh sách, bạn sẽ nhận được thời gian và không gian lớn hơn cho tất cả các hoạt động (kiểm tra một cạnh là O(1), có được tất cả các cạnh liền kề O(degree), v.v.).

Có một số yếu tố chi phí không đổi mặc dù cho cả thời gian chạy và không gian (bảng băm không nhanh như danh sách liên kết hoặc tra cứu mảng và cần thêm một khoảng trống để giảm va chạm).

Tôi sẽ tiếp tục khắc phục sự đánh đổi của đại diện danh sách kề, vì các câu trả lời khác đã đề cập đến các khía cạnh khác.

Có thể biểu thị một biểu đồ trong danh sách kề với truy vấn EdgeExists trong thời gian không đổi được khấu hao, bằng cách tận dụng các cấu trúc dữ liệu của Dictionary và Hashset . Ý tưởng là giữ các đỉnh trong từ điển và với mỗi đỉnh, chúng ta giữ một tập băm tham chiếu đến các đỉnh khác mà nó có các cạnh.

Một sự đánh đổi nhỏ trong triển khai này là nó sẽ có độ phức tạp không gian O (V + 2E) thay vì O (V + E) như trong danh sách kề kề thông thường, vì các cạnh được biểu thị hai lần ở đây (vì mỗi đỉnh có bộ băm riêng của các cạnh). Nhưng các hoạt động như AddVertex , AddEdge , RemoveEdge có thể được thực hiện trong thời gian khấu hao O (1) với việc triển khai này, ngoại trừ RemoveVertex có ma trận kề (O) như ma trận kề. Điều này có nghĩa là ngoài việc đơn giản thực hiện, ma trận kề không có bất kỳ lợi thế cụ thể nào. Chúng ta có thể tiết kiệm không gian trên biểu đồ thưa thớt với hiệu suất gần như tương tự trong việc thực hiện danh sách kề này.

Hãy xem các triển khai bên dưới trong kho lưu trữ Github C # để biết chi tiết. Lưu ý rằng đối với biểu đồ có trọng số, nó sử dụng từ điển lồng nhau thay vì kết hợp bộ băm từ điển để phù hợp với giá trị trọng lượng. Tương tự như vậy đối với đồ thị có hướng, có các bộ băm riêng cho các cạnh vào & ra.

Thuật toán nâng cao

Lưu ý: Tôi tin rằng bằng cách sử dụng xóa lười biếng, chúng tôi có thể tối ưu hóa thêm hoạt động RemoveVertex thành O (1) được khấu hao, mặc dù tôi chưa thử nghiệm ý tưởng đó. Ví dụ, khi xóa, chỉ cần đánh dấu đỉnh là đã xóa trong từ điển và sau đó xóa các cạnh mồ côi một cách lười biếng trong các hoạt động khác.