Tại sao không có thuật toán gần đúng cho SAT và các vấn đề quyết định khác?

Tôi có một vấn đề quyết định NP-đầy đủ. Đưa ra một ví dụ của vấn đề, tôi muốn thiết kế một thuật toán tạo ra CÓ, nếu vấn đề đó là khả thi, và, KHÔNG, ngược lại. (Tất nhiên, nếu thuật toán không tối ưu, nó sẽ mắc lỗi.)

Tôi không thể tìm thấy bất kỳ thuật toán gần đúng cho các vấn đề như vậy. Tôi đã tìm kiếm cụ thể về SAT và tôi đã tìm thấy trên trang Wikipedia về Thuật toán xấp xỉ như sau: Một hạn chế khác của cách tiếp cận là nó chỉ áp dụng cho các vấn đề tối ưu hóa và không phải là các vấn đề quyết định "thuần túy" như thỏa mãn, mặc dù thường có thể .. .

Tại sao chúng ta không, ví dụ, xác định tỷ lệ gần đúng là một cái gì đó tỷ lệ thuận với số lỗi mà thuật toán gây ra? Làm thế nào để chúng ta thực sự giải quyết các vấn đề quyết định theo cách tham lam và không tối ưu?

Các thuật toán gần đúng chỉ dành cho các vấn đề tối ưu hóa, không phải cho các vấn đề quyết định.

Tại sao chúng ta không định nghĩa tỷ lệ gần đúng là một phần sai lầm của thuật toán, khi cố gắng giải quyết một số vấn đề quyết định? Bởi vì "tỷ lệ gần đúng" là một thuật ngữ có nghĩa chuẩn, được xác định rõ, một nghĩa có nghĩa khác và sẽ khó hiểu khi sử dụng cùng một thuật ngữ cho hai điều khác nhau.

OK, chúng ta có thể định nghĩa một số tỷ lệ khác (hãy gọi nó là một tỷ lệ khác - ví dụ: "tỷ lệ det") định lượng số lượng lỗi mà thuật toán gây ra, cho một số vấn đề quyết định? Chà, không rõ làm thế nào để làm điều đó. Điều gì sẽ là mẫu số cho phân số đó? Hoặc, nói một cách khác: sẽ có vô số trường hợp vấn đề và đối với một số trong số đó, thuật toán sẽ đưa ra câu trả lời đúng và một số khác thì nó sẽ trả lời sai, vì vậy bạn kết thúc với một tỷ lệ "Một cái gì đó chia cho vô cùng", và cuối cùng là vô nghĩa hoặc không được xác định.

Ngoài ra, chúng ta có thể định nghĩa là một phần sai lầm của các lỗi thuật toán, trong các trường hợp vấn đề có kích thước . Sau đó, chúng ta có thể tính giới hạn của là , nếu giới hạn đó tồn tại. Điều này sẽ được xác định rõ (nếu giới hạn tồn tại). Tuy nhiên, trong hầu hết các trường hợp, điều này có thể không hữu ích lắm. Cụ thể, nó mặc nhiên thừa nhận một phân phối thống nhất trong các trường hợp vấn đề. Tuy nhiên, trong thế giới thực, phân phối thực tế trong các trường hợp sự cố có thể không đồng nhất - nó thường rất xa so với đồng phục. Do đó, số bạn nhận được theo cách này thường không hữu ích như bạn có thể hy vọng: nó thường mang lại ấn tượng sai lệch về mức độ tốt của thuật toán. n r n n → $r_n$$n$$r_n$$n \to \infty$

Để tìm hiểu thêm về cách mọi người đối phó với độ hấp dẫn (độ cứng NP), hãy xem Xử lý sự khó hiểu: Các vấn đề hoàn chỉnh NP .

Lý do bạn không thấy những thứ như tỷ lệ gần đúng trong các vấn đề ra quyết định là vì chúng thường không có ý nghĩa trong bối cảnh các câu hỏi mà người ta thường hỏi về các vấn đề ra quyết định. Trong một cài đặt tối ưu hóa, điều đó có ý nghĩa bởi vì thật hữu ích khi "đóng". Trong nhiều môi trường, nó không có ý nghĩa. Sẽ không có ý nghĩa khi thấy mức độ thường xuyên bạn "gần gũi" trong một vấn đề logarit rời rạc. Sẽ không có ý nghĩa khi thấy mức độ thường xuyên bạn "gần gũi" với việc tìm kiếm một đồng phân đồ thị. Và tương tự như vậy, trong hầu hết các vấn đề ra quyết định, sẽ không có nghĩa là "gần gũi" với quyết định đúng đắn.

Bây giờ, trong các triển khai thực tế, có nhiều trường hợp rất hữu ích để biết phần nào của các vấn đề có thể được quyết định "nhanh chóng" và phần nào không thể. Tuy nhiên, không giống như tối ưu hóa, không có cách nào phù hợp với một kích thước để định lượng điều này. Bạn có thể làm điều đó theo thống kê, như bạn đề xuất, nhưng chỉ khi bạn biết phân phối thống kê các đầu vào của mình. Hầu hết thời gian, những người quan tâm đến các vấn đề quyết định không may mắn có được các bản phân phối như vậy.

Như một trường hợp nghiên cứu, xem xét vấn đề tạm dừng. Vấn đề tạm dừng được biết là không thể giải quyết được. Thật là xấu hổ, bởi vì đây là một vấn đề thực sự hữu ích để có thể giải quyết nếu bạn đang tạo một trình biên dịch. Tuy nhiên, trên thực tế, chúng tôi thấy rằng hầu hết các chương trình thực sự rất dễ phân tích từ góc độ vấn đề tạm dừng. Trình biên dịch tận dụng điều này để tạo mã tối ưu trong những trường hợp này. Tuy nhiên, một trình biên dịch phải nhận ra rằng có khả năng một khối mã cụ thể không thể quyết định được. Bất kỳ chương trình nào dựa vào mã là "có khả năng quyết định" đều có thể gặp rắc rối.

Tuy nhiên, số liệu được các trình biên dịch sử dụng để xác định mức độ họ giải quyết các trường hợp cụ thể này của vấn đề tạm dừng rất khác so với số liệu được sử dụng bởi một chương trình mã hóa để kiểm tra xem một cặp số nguyên tố cụ thể có được chấp nhận chống lại các cuộc tấn công hay không. Không có một kích thước phù hợp với tất cả các giải pháp. Nếu bạn muốn một số liệu như vậy, bạn sẽ muốn điều chỉnh nó để phù hợp với không gian vấn đề cụ thể và logic kinh doanh của bạn.

Ngoài các câu trả lời hiện có, hãy để tôi chỉ ra rằng có những tình huống có ý nghĩa để có một giải pháp gần đúng cho một vấn đề quyết định, nhưng nó hoạt động khác với bạn nghĩ.

Với các thuật toán này, chỉ có một trong hai kết quả được xác định một cách chắc chắn, trong khi kết quả còn lại có thể không chính xác. Hãy kiểm tra Miller-Rabin cho số nguyên tố , ví dụ: Nếu kiểm tra xác định rằng một số là không quan trọng, mà kết quả là chắc chắn. Nhưng trong trường hợp khác, điều đó chỉ có nghĩa là con số có thể là số nguyên tố. Tùy thuộc vào thời gian tính toán mà bạn sẵn sàng đầu tư, bạn có thể tăng sự tự tin về kết quả, nhưng nó sẽ không phải là 100% vì đây là trường hợp không chính.

Điều này đặc biệt mạnh mẽ khi giải quyết các vấn đề không thể giải quyết được: Bạn có thể viết một công cụ cố gắng giải quyết vấn đề tạm dừng cho một đoạn mã cụ thể. Nếu nó có thể tìm thấy một bằng chứng rằng chương trình sẽ không lặp lại vô tận, bạn có thể yêu cầu như vậy với sự chắc chắn 100%. Nếu bạn không thể tìm thấy bằng chứng như vậy, có thể là luồng điều khiển chương trình quá phức tạp để công cụ của bạn phân tích, nhưng đó không phải là bằng chứng cho thấy nó sẽ lặp lại mãi mãi. Bằng cách đơn giản hóa các cấu trúc điều khiển, bạn có thể tạo ra một chương trình tương đương đủ đơn giản để công cụ chứng minh rằng nó sẽ tạm dừng.