Vấn đề đẳng cấu đồ thị cho đồ thị có nhãn


11

Trong trường hợp đồ thị không được gắn nhãn, vấn đề đẳng cấu đồ thị có thể được giải quyết bằng một số thuật toán thực hiện rất tốt trong thực tế. Đó là, mặc dù thời gian chạy trường hợp xấu nhất là theo cấp số nhân, người ta thường có thời gian chạy đa thức.

Tôi đã hy vọng rằng tình huống tương tự trong trường hợp đồ thị được dán nhãn. Tuy nhiên, tôi có một thời gian thực sự khó khăn để tìm bất kỳ tài liệu tham khảo nào đề xuất thuật toán "thực tế hiệu quả".

Lưu ý: Ở đây, chúng tôi yêu cầu đẳng cấu giữ nguyên nhãn. Đó là, một sự đồng hình giữa hai thuật ngữ đại số tự động / quy trình hữu hạn sẽ ngụ ý rằng automata / thuật ngữ về cơ bản là "bằng với việc đổi tên của các nút".

Tài liệu tham khảo duy nhất tôi tìm thấy là tài liệu trong Wikipedia nói rằng vấn đề đẳng cấu của đồ thị có nhãn có thể được giảm bớt về mặt đa thức so với đồ thị thông thường. Tuy nhiên, bài viết cơ bản là về lý thuyết phức tạp hơn là các thuật toán thực tế.

Tôi đang thiếu một cái gì đó, hoặc thực sự là không có thuật toán "heuristic" hiệu quả để quyết định xem hai biểu đồ được dán nhãn có phải là đẳng cấu không?

Bất kỳ gợi ý hoặc tài liệu tham khảo sẽ là tuyệt vời.


3
Sẽ thật tuyệt khi đưa ra các tài liệu tham khảo cho bài viết trên wikipedia và bài báo mà bạn tìm thấy, để cứu chúng tôi khỏi những rắc rối.
babou

1
Bạn có ý nghĩa gì bởi một đẳng cấu "bảo tồn nhãn"? Trong bối cảnh của một máy tự động, các nhãn đỉnh là khác biệt. Do đó, bất kỳ đẳng cấu nào cũng "bảo tồn nhãn" một cách tầm thường theo nghĩa hai đỉnh trong nguồn có nhãn riêng biệt cũng phải có nhãn riêng biệt trong ảnh. Vấn đề đó giống hệt với bài toán đẳng cấu đồ thị thông thường. Nếu bạn muốn nói rằng đẳng cấu phải ánh xạ một đỉnh với một nhãn có cùng nhãn, thuật toán là tầm thường khi các nhãn đỉnh luôn khác biệt: chỉ cần kiểm tra xem bản đồ nhận dạng trên nhãn có phải là đẳng cấu không.
David Richerby

Nếu bạn muốn xem xét trường hợp một số đỉnh có thể có cùng nhãn và hình ảnh của một đỉnh phải có cùng nhãn với nhãn gốc, thường được gọi là đẳng cấu giữa các đồ thị màu . Trong trường hợp đó, có một sự giảm đơn giản đối với GI chung bằng cách thay thế màu sắc bằng các tiện ích. Bạn có thể có được một thuật toán thực tế phong nha bằng cách áp dụng các tiện ích được chọn cẩn thận và sau đó sử dụng thuật toán GI tiêu chuẩn.
David Richerby

Bạn có thực sự không sẵn lòng coi hai bản đồ được dán nhãn cạnh là đẳng cấu nếu có một dạng đồng phân sơ đồ thông thường cũng bảo tồn các lớp tương đương của nhãn? Trong ví dụ của bạn, coi hai là FA, các ngôn ngữ được và chấp nhận , trong khi khác nhau (có lẽ), thực sự chỉ là hình ảnh đồng nhất của nhau bởi các thay thế . S a c , b dSSac,bd
Rick Decker

4
Vấn đề là hoàn thành GI tầm thường (chỉ cần chọn một biểu đồ trong đó tất cả các cạnh có cùng nhãn). Để chỉ ra rằng nó không khó hơn so với đẳng cấu đồ thị, hãy xây dựng bản đồ 1: 1 từ nhãn đến số nguyên ( và thêm vào giữa mỗi cạnh được gắn nhãn với ký hiệu một biểu đồ hoàn chỉnh trên đỉnh ( ) cộng với một nút phụ ở phía mũi tên của cạnh. Các đồ thị kết quả là đẳng cấu khi và chỉ khi automata ban đầu là đẳng cấu. s g ( s ) K g ( s )g:a1,b2,c3,...)sg(s)Kg(s)
Vor

Câu trả lời:


5

Bạn có thể quan tâm đến bài viết này:

Aidan Hogan: Skolemising Trống Nodes trong khi bảo tồn đẳng cấu. WWW 2015: 430-440

Nó có một thuật toán (dựa trên Nauty) để kiểm tra sự đẳng cấu của đồ thị RDF, về cơ bản là các đồ thị có nhãn có hướng có thể chứa các nhãn cố định. Thuật toán đưa nhãn vào tài khoản để thu hẹp không gian tìm kiếm.

Nếu bạn có thể biểu thị biểu đồ được gắn nhãn đầu vào của mình dưới dạng biểu đồ RDF, bạn có thể thử sử dụng gói phần mềm được liên kết " blabel" để kiểm tra sự đẳng cấu.


4

Tôi đã phát hiện ra rằng thuật toán này thuộc về loại thuật toán Weisfeiler-Lehman thứ k, và nó thất bại với các biểu đồ thông thường. Để biết thêm ở đây:

http://dabacon.org/pontiff/?p=4148

Bài gốc sau:

Nhiều năm trước, tôi đã tạo ra một thuật toán đơn giản và linh hoạt cho chính xác vấn đề này (biểu đồ đẳng cấu với nhãn).

Tôi đặt tên cho nó là "Powerhash", và để tạo ra thuật toán, nó cần có hai cái nhìn sâu sắc. Đầu tiên là thuật toán đồ thị lặp công suất, cũng được sử dụng trong PageRank. Thứ hai là khả năng thay thế chức năng bước bên trong của vòng lặp năng lượng bằng bất cứ thứ gì chúng ta muốn. Tôi đã thay thế nó bằng một hàm thực hiện như sau trên mỗi lần lặp và cho mỗi nút:

  • Sắp xếp các giá trị băm (từ lần lặp trước) của hàng xóm của nút
  • Băm băm được sắp xếp băm
  • Thay thế hàm băm của nút bằng hàm băm mới được tính toán

Ở bước đầu tiên, hàm băm của một nút bị ảnh hưởng bởi các láng giềng trực tiếp. Ở bước thứ hai, hàm băm của một nút bị ảnh hưởng bởi 2 bước nhảy cách xa nó. Ở bước thứ N, hàm băm của nút sẽ bị ảnh hưởng bởi các bước nhảy N lân cận xung quanh nó. Vì vậy, bạn chỉ cần tiếp tục chạy Powerhash cho các bước N = graph_radius. Cuối cùng, hàm băm của nút trung tâm đồ thị sẽ bị ảnh hưởng bởi toàn bộ biểu đồ.

Để tạo ra hàm băm cuối cùng, hãy sắp xếp các nút băm của bước cuối cùng và ghép chúng lại với nhau. Sau đó, bạn có thể so sánh các giá trị băm cuối cùng để tìm xem hai biểu đồ có phải là đẳng cấu không. Nếu bạn có nhãn, sau đó thêm chúng (vào lần lặp đầu tiên) trong các giá trị băm bên trong mà bạn tính cho mỗi nút.

Để biết thêm về điều này, bạn có thể xem bài viết của tôi ở đây:

https://plus.google.com/114866592715069940152/posts/fmBFhjhQcZF

Thuật toán trên được triển khai bên trong cơ sở dữ liệu quan hệ chức năng "madIS". Bạn có thể tìm thấy mã nguồn của thuật toán ở đây:

https://github.com/madgik/madis/blob/master/src/fifts/aggregate/graph.py


Chỉ cần một cảnh báo rằng thuật toán của bạn là đa thức và vì vậy nếu nó hoàn thành, bạn vừa giải quyết một vấn đề mở từ lâu trong CS về GI đang ở P. :) (Có nhiều trường hợp thuật toán bạn mô tả sẽ cho kết quả sai .)
badroit

Thuật toán là gần đúng và chắc chắn không đầy đủ (tôi cũng nói như vậy trong bài viết trên blog). Lý do nó hoạt động là các giá trị băm mà nó tạo ra là rất lớn, do đó, trong một cơ sở dữ liệu thậm chí hàng triệu biểu đồ, khả năng va chạm băm dương tính giả sẽ là vô cùng lớn. Nếu bạn quản lý để tìm thấy bất kỳ trường hợp va chạm băm dương tính giả, tôi sẽ rất quan tâm để biết về nó. Lý do (khi sử dụng băm mật mã) là vì, bạn sẽ quản lý để "phá vỡ" hàm băm mật mã.
estama

Để giải thích về mức độ vô cùng của khả năng xảy ra va chạm băm. Tôi sẽ coi hàm băm mật mã 256 bit là quá đủ để đảm bảo rằng tất cả các tệp khác nhau trên thế giới không băm đến cùng một giá trị (ví dụ git sử dụng SHA-1 là 160 bit để đảm bảo điều đó). Băm từ Powerhash sẽ là 128 bit * graph_node_count (sử dụng hàm băm MD5). Vì vậy, trên thực tế, bạn sẽ không bao giờ có thể tạo ra đủ biểu đồ (trong vũ trụ này) để tìm ra sự va chạm băm giữa chúng.
estama

1
Tôi có nghĩa là thuật toán của bạn sẽ cung cấp cho dương tính giả ngay cả khi giả sử không có va chạm băm. Rất nhiều thuật toán đa thức thời gian đã được đề xuất cho sự đồng hình đồ thị trong tài liệu và tất cả chúng đều cho kết quả dương tính giả. Một câu hỏi liên quan ở đây: cs.stackexchange.com/questions/50939/ ,.
badroit

1
Cảm ơn bạn đã thảo luận. Với một số nghiên cứu khác, tôi đã thấy rằng thuật toán ở trên nằm trong danh mục thuật toán Weisfeiler-Lehman thứ k, và nó thất bại với các biểu đồ thông thường. Để biết thêm tại đây: dabacon.org/pontiff/?p=4148
estama
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.