Có một tập hợp con các chương trình tránh vấn đề tạm dừng

Tôi vừa đọc một lời giải thích khác về vấn đề tạm dừng, và nó khiến tôi suy nghĩ về tất cả các vấn đề mà tôi đã thấy được đưa ra như các ví dụ liên quan đến các chuỗi vô hạn. Nhưng tôi không bao giờ sử dụng trình tự vô hạn trong các chương trình của mình - chúng mất quá nhiều thời gian. Tất cả các ứng dụng trong thế giới thực có giới hạn dưới và trên. Ngay cả các thực tế không thực sự là thực - chúng là các xấp xỉ được lưu trữ dưới dạng 32/64 bit, v.v.

Vì vậy, câu hỏi là, có một tập hợp con của các chương trình có thể được xác định nếu chúng dừng lại? Là nó đủ tốt cho hầu hết các chương trình. Tôi có thể xây dựng một tập hợp các cấu trúc ngôn ngữ mà tôi có thể xác định 'khả năng tạm dừng' của chương trình không. Tôi chắc chắn rằng điều này đã được nghiên cứu ở đâu đó trước đây vì vậy bất kỳ con trỏ sẽ được đánh giá cao. Ngôn ngữ sẽ không được hoàn thiện, nhưng liệu có thứ gì đó gần như hoàn thiện đến mức đủ tốt?

Tất nhiên, một cấu trúc như vậy sẽ phải loại trừ đệ quy và không bị ràng buộc trong khi các vòng lặp, nhưng tôi có thể viết một chương trình mà không cần những thứ đó đủ dễ dàng.

Đọc từ đầu vào tiêu chuẩn làm ví dụ sẽ phải bị ràng buộc, nhưng điều đó đủ dễ dàng - tôi sẽ giới hạn đầu vào của mình ở mức 10.000.000 ký tự, v.v., tùy thuộc vào miền vấn đề.

tia

[Cập nhật]

Sau khi đọc các bình luận và câu trả lời có lẽ tôi nên nói lại câu hỏi của mình.

Đối với một chương trình nhất định trong đó tất cả các đầu vào bị ràng buộc, bạn có thể xác định xem chương trình đó có dừng không. Nếu vậy các ràng buộc của ngôn ngữ là gì và các giới hạn của bộ đầu vào là gì. Tập hợp tối đa của các cấu trúc này sẽ xác định một ngôn ngữ có thể được suy ra để tạm dừng hoặc không. Có một số nghiên cứu đã được thực hiện trên này?

[Cập nhật 2]

Đây là câu trả lời, đúng vậy, trở lại vào năm 1967 từ http://www.isp.uni-luebeck.de/kps07/files/ con / gnerner.pdf

Rằng vấn đề tạm dừng có thể được giải quyết ít nhất về mặt lý thuyết cho các hệ thống trạng thái đã được tranh luận bởi Minsky vào năm 1967 [4]: mô hình lặp đi lặp lại. Thời lượng của mẫu lặp lại này không thể vượt quá số trạng thái bên trong của máy ...

(và vì vậy nếu bạn gắn bó với các máy turing hữu hạn thì bạn có thể xây dựng một nhà tiên tri)

Vấn đề không nằm ở đầu vào (rõ ràng, với đầu vào không bị chặn, bạn có thể có thời gian chạy không giới hạn chỉ để đọc đầu vào), đó là về số lượng trạng thái bên trong.

Khi số lượng trạng thái nội bộ bị giới hạn, về mặt lý thuyết, bạn có thể giải quyết vấn đề tạm dừng trong mọi trường hợp (chỉ cần mô phỏng nó cho đến khi bạn đạt đến trạng thái dừng hoặc lặp lại trạng thái), khi không, có thể giải quyết được . Nhưng ngay cả khi số lượng trạng thái nội bộ trong thực tế bị ràng buộc, nó cũng lớn đến mức các phương pháp dựa vào giới hạn của số lượng trạng thái nội bộ là vô ích để chứng minh việc chấm dứt bất kỳ chương trình nào tầm thường nhất.

Có nhiều cách thực tế hơn để kiểm tra việc chấm dứt các chương trình. Ví dụ, diễn đạt chúng bằng ngôn ngữ lập trình không đệ quy cũng không phải goto và cấu trúc vòng lặp của nó có tất cả ràng buộc về số lần lặp phải được chỉ định khi vào vòng lặp. (Lưu ý rằng ràng buộc không thực sự liên quan đến số lần lặp hiệu quả, một cách tiêu chuẩn để chứng minh việc chấm dứt vòng lặp là có một chức năng mà bạn chứng minh là giảm nghiêm ngặt từ lần lặp này sang lần lặp khác và điều kiện nhập cảnh của bạn đảm bảo là tích cực, bạn có thể đặt đánh giá đầu tiên là ràng buộc của bạn).

Trước hết, hãy xem xét những gì sẽ xảy ra nếu chúng ta có một máy dò tạm dừng. Chúng tôi biết từ đối số đường chéo rằng tồn tại ít nhất một chương trình sẽ khiến máy dò tạm dừng không bao giờ dừng hoặc đưa ra câu trả lời sai. Nhưng đó là một chương trình kỳ lạ và không thể.

Có một lập luận khác mặc dù một máy dò tạm dừng là không thể, và đó là lập luận trực quan hơn rằng máy dò tạm dừng sẽ là ma thuật. Giả sử bạn muốn biết Định lý cuối cùng của Fermat là đúng hay sai. Bạn chỉ cần viết một chương trình tạm dừng nếu nó đúng và chạy mãi mãi nếu nó sai, và sau đó chạy trình phát hiện dừng trên đó. Bạn không chạy chương trình , bạn chỉ chạy trình phát hiện tạm dừng trên chương trình . Một máy dò tạm dừng sẽ cho phép chúng tôi giải quyết ngay một số lượng lớn các vấn đề mở trong lý thuyết số chỉ bằng cách viết chương trình.

Vì vậy, bạn có thể viết một ngôn ngữ lập trình được đảm bảo để tạo ra các chương trình mà việc tạm dừng có thể luôn luôn được xác định không? Chắc chắn rồi. Nó chỉ không thể có vòng lặp, điều kiện và sử dụng lưu trữ nhiều tùy ý. Nếu bạn sẵn sàng sống không có vòng lặp, hoặc không có câu lệnh "nếu" hoặc dung lượng lưu trữ bị hạn chế nghiêm ngặt, thì chắc chắn, bạn có thể viết một ngôn ngữ mà việc tạm dừng luôn luôn có thể xác định được.

Tôi khuyên bạn nên đọc Gôdel, Escher, Bach . Đó là một cuốn sách rất thú vị và sáng sủa, trong số những thứ khác, chạm vào định lý không hoàn chỉnh của Gôdel và vấn đề tạm dừng.

Để trả lời câu hỏi của bạn một cách ngắn gọn: vấn đề tạm dừng là có thể quyết định miễn là chương trình của bạn không chứa một whilevòng lặp (hoặc bất kỳ biểu hiện nào có thể xảy ra).

Đối với mọi chương trình hoạt động trên một lượng bộ nhớ hạn chế (bao gồm cả lưu trữ các loại), vấn đề tạm dừng có thể được giải quyết; tức là một chương trình không thể giải quyết được sẽ bị chiếm nhiều bộ nhớ hơn khi chạy.

Nhưng ngay cả như vậy, cái nhìn sâu sắc này không có nghĩa là nó có thể được sử dụng cho các vấn đề trong thế giới thực, vì một chương trình tạm dừng, chỉ hoạt động trong vài kilobyte bộ nhớ, có thể dễ dàng mất nhiều thời gian hơn thời gian còn lại của vũ trụ.

Để (một phần) trả lời câu hỏi của bạn "Có một tập hợp con các chương trình tránh vấn đề tạm dừng": có, thực tế là có. Tuy nhiên, tập hợp con này vô dụng một cách đáng kinh ngạc (lưu ý rằng tập hợp con mà tôi đang nói đến là một tập hợp con nghiêm ngặt của các chương trình tạm dừng).

Nghiên cứu về mức độ phức tạp của các vấn đề đối với 'hầu hết các đầu vào' được gọi là độ phức tạp của trường hợp chung . Bạn xác định một số tập hợp con của các đầu vào có thể, chứng minh rằng tập hợp con này bao gồm 'hầu hết các đầu vào' và đưa ra thuật toán giải quyết vấn đề cho tập hợp con này.

Ví dụ, vấn đề tạm dừng có thể giải quyết được trong thời gian đa thức cho hầu hết các đầu vào (trên thực tế, trong thời gian tuyến tính, nếu tôi hiểu đúng về bài viết ).

Tuy nhiên, kết quả này khá vô dụng vì có ba lưu ý phụ: thứ nhất, chúng tôi nói về máy Turing bằng một cuộn băng, thay vì các chương trình máy tính trong thế giới thực trên máy tính trong thế giới thực. Theo như tôi biết, không ai biết liệu máy tính trong thế giới thực có giống nhau hay không (mặc dù máy tính trong thế giới thực có thể tính toán các chức năng tương tự như máy Turing, số lượng chương trình được phép, độ dài của chúng và liệu chúng có thể dừng lại không hoàn toàn khác nhau).

Thứ hai, bạn phải xem 'phần lớn đầu vào' nghĩa là gì. Điều đó có nghĩa là xác suất có thể kiểm tra một chương trình ngẫu nhiên có độ dài bằng thuật toán này có xu hướng 1 vì n có xu hướng vô cùng. Nói cách khác, nếu n đủ lớn, thì một chương trình ngẫu nhiên có độ dài n gần như chắc chắn có thể được kiểm tra bằng thuật toán này.

Những chương trình có thể được kiểm tra theo cách tiếp cận được mô tả trong bài báo? Về cơ bản, tất cả các chương trình tạm dừng trước khi lặp lại một trạng thái (trong đó 'trạng thái' gần tương ứng với một dòng mã trong một chương trình).

Mặc dù gần như tất cả các chương trình có thể được kiểm tra theo cách này, không có chương trình nào có thể được kiểm tra theo cách này rất thú vị và chúng thường không được thiết kế bởi con người, vì vậy điều này không có giá trị thực tế nào.

Nó cũng chỉ ra rằng độ phức tạp của trường hợp chung có thể sẽ không thể giúp chúng ta giải quyết vấn đề tạm dừng, vì gần như tất cả các chương trình thú vị (dường như) khó kiểm tra. Hoặc, thay vào đó là cụm từ: gần như tất cả các chương trình đều không thú vị, nhưng dễ kiểm tra.

Có, và trên thực tế, có những chương trình trong cuộc sống thực giải quyết vấn đề tạm dừng cho các vấn đề khác mọi lúc. Chúng là một phần của hệ điều hành mà bạn đang chạy trên máy tính của mình. Không thể giải quyết được là một tuyên bố kỳ lạ chỉ nói rằng không có chương trình nào hoạt động cho TẤT CẢ các chương trình khác.

Một người tuyên bố chính xác rằng bằng chứng tạm dừng dường như là chương trình duy nhất mà nó không thể được giải quyết, vì nó vô cùng dấu vết giống như một tấm gương. Người này cũng tuyên bố rằng nếu có một máy dừng, nó sẽ là phép màu bởi vì nó sẽ cho chúng ta biết các bài toán khó bằng cách cho chúng ta biết trước nếu thuật toán giải sẽ dừng lại.

Giả định trong cả hai trường hợp này là máy tạm dừng không theo dõi vì không có bằng chứng nào cho thấy nó có dấu vết. Tuy nhiên, trong thực tế, nó thực sự theo dõi / chạy chương trình mà nó được chạy với đầu vào đã cho.

Bằng chứng logic ít nhất là đơn giản. Nếu nó không cần theo dõi ít ​​nhất là bước đầu tiên, thì nó sẽ không cần đầu vào cùng với chương trình mà nó chạy. Để sử dụng thông tin, ít nhất nó phải theo dõi bước đầu tiên trước khi cố gắng phân tích nơi con đường đó đang đi.

Các bài toán khó được đề cập trong câu trả lời hàng đầu là những bài toán mà bạn không thể nhanh chóng tìm ra câu trả lời, điều đó có nghĩa là bài toán tạm dừng sẽ phải tiếp tục truy tìm cho đến khi một số mẫu có thể nhận ra.

Vì vậy, lý lẽ thực tế duy nhất để có được từ vấn đề tạm dừng là một máy tạm dừng không thể xác định kết quả của trình giải quyết vấn đề được tối ưu hóa nhanh hơn trình giải quyết vấn đề có thể kết thúc.

Đưa ra một bằng chứng chính thức cho lý do này là khó hơn, và mặc dù tôi tin rằng tôi có thể, cố gắng giải thích nó cho bất cứ ai, một học viện sẽ dẫn đến việc họ ném một con vượn như giận dữ và đung đưa từ đèn chùm. Tốt nhất là đừng tranh cãi với những người đó.

Đây là câu trả lời, đúng vậy, trở lại vào năm 1967 từ http://www.isp.uni-luebeck.de/kps07/files/ con / gnerner.pdf

Rằng vấn đề tạm dừng có thể được giải quyết ít nhất về mặt lý thuyết cho các hệ thống trạng thái đã được tranh luận bởi Minsky vào năm 1967 [4]: mô hình lặp đi lặp lại. Thời lượng của mẫu lặp lại này không thể vượt quá số trạng thái bên trong của máy ...

(và vì vậy nếu bạn gắn bó với các máy turing hữu hạn thì bạn có thể xây dựng một nhà tiên tri)

Tất nhiên điều này mất bao lâu là một câu hỏi khác

Có một tập hợp con các chương trình có thể được xác định nếu chúng dừng lại không?

Vâng.

Nó có đủ tốt cho hầu hết các chương trình không?

Xác định "nhất".

Tôi có thể xây dựng một tập hợp các cấu trúc ngôn ngữ mà tôi có thể xác định 'khả năng tạm dừng' của chương trình không?

Vâng.

Có một thứ như gần hoàn thành mà đủ tốt?

Xác định "gần".

Nhiều người viết Python mà không sử dụng whilecâu lệnh hoặc đệ quy.

Nhiều người viết Java chỉ sử dụng forcâu lệnh với các trình lặp hoặc bộ đếm đơn giản có thể được chứng minh tầm thường để chấm dứt; và họ viết mà không cần đệ quy.

Nó khá dễ dàng để tránh whilevà đệ quy.

Đối với một chương trình nhất định trong đó tất cả các đầu vào bị ràng buộc, bạn có thể xác định xem chương trình đó có dừng không?

Không.

Nếu vậy các ràng buộc của ngôn ngữ là gì và các giới hạn của bộ đầu vào là gì.

Ừm. Vấn đề Dừng có nghĩa là chương trình không bao giờ có thể xác định mọi thứ về các chương trình phức tạp như chính nó. Bạn có thể thêm bất kỳ một trong số lượng lớn các ràng buộc để vượt qua vấn đề tạm dừng.

Cách tiếp cận tiêu chuẩn cho vấn đề tạm dừng là cho phép các bằng chứng sử dụng một tập hợp các hình thức toán học "phong phú" hơn một chút so với có sẵn trong ngôn ngữ lập trình.

Dễ dàng mở rộng hệ thống bằng chứng hơn là hạn chế ngôn ngữ. Bất kỳ hạn chế nào cũng dẫn đến các đối số cho một thuật toán khó diễn đạt do hạn chế.

Tập hợp tối đa của các cấu trúc này sẽ xác định một ngôn ngữ có thể được suy ra để tạm dừng hoặc không. Có một số nghiên cứu đã được thực hiện trên này?

Vâng. Nó được gọi là "Lý thuyết nhóm". Một tập hợp các giá trị được đóng dưới một tập hợp các hoạt động. Công cụ khá hiểu.