Không thể biết được nếu một chương trình trả về đúng hay sai


7

Xem xét vấn đề lấy máy Turing đầu vào và xác định xem ô cuối cùng là hay sau khi dừng tính toán. Trong trường hợp nó viết một cái gì đó khác hoặc không dừng lại, bạn được phép đưa ra bất kỳ câu trả lời nào (nhưng bạn phải dừng lại và đưa ra một số câu trả lời trên tất cả các đầu vào).01

Là vấn đề này không thể giải quyết được? Ruột của tôi nói rằng nó nên như vậy, nhưng tôi không thể tìm ra cách giảm bớt vấn đề tạm dừng. Với một máy Turing có thể dừng hoặc không dừng, chúng ta có thể thiết lập máy kết thúc bằng trong trường hợp nó dừng lại, nhưng không thể kết thúc với bất cứ điều gì trong trường hợp không dừng, vì vậy nhà tiên tri chỉ có thể nói trong trường hợp này mà không cần phải tìm hiểu xem trên thực tế máy có dừng lại hay không.00

Lưu ý rằng việc giảm theo hướng khác là đơn giản; nếu bạn có thể giải quyết vấn đề tạm dừng, sau đó đưa ra một TM kết thúc bằng hoặc , chúng tôi thay thế bước chữ viết bằng một vòng lặp vô hạn để tạo ra một TM mới. Nếu TM mới tạm dừng, chúng tôi nói "nó viết " và nếu nó không dừng lại, chúng tôi sẽ nói "nó viết ". Câu trả lời này được đảm bảo là chính xác miễn là trên thực tế TM tạm dừng bằng hoặc , vì vậy chúng tôi có thể giải quyết vấn đề ban đầu.0110101

Câu trả lời:


8

Giả sử bạn có một chức năng giống như chức năng bạn mô tả:

def haltify(f):
    # Never fails to halt.
    # If 'f' halts, returns f().
    # If 'f' doesn't halt, anything could be returned.
    ... magic ...

Nhưng sau đó, một người nào đó đi cùng và làm điều này:

def evil():
    return not haltify(evil)

Thấy vấn đề?

  1. Nếu haltify(f)được đảm bảo tạm dừng cho tất cả f, thì evilcũng được đảm bảo tạm dừng vì nó chỉ gọi haltifymột số cụ thể fvà đảo ngược đầu ra.
  2. Kể từ khi evildừng lại, haltify(evil)phải đánh giá để điều tương tự như evil().
  3. Vì vậy, not haltify(evil)đơn giản hóa not evil()và đó là những gì evil()trả lại.
  4. Đó là một vấn đề, bởi vì không có xthỏa mãn x == not x. Kết quả của cái ác là mâu thuẫn.
  5. Do đó, một trong những giả định mà chúng tôi sử dụng là sai: hoặc haltifykhông được bảo đảm tạm dừng hoặc không được bảo đảm sẽ quay trở lại f()khi thông qua tạm dừng f.

Bài tập bổ sung: tại sao hàm không def good(): return haltify(good)gây ra vấn đề cho việc dừng, mặc dù rõ ràng đơn giản hóa thành vòng lặp vô hạn def good(): return good()?


Rất đẹp. Đây là sự đồng hình với câu trả lời của Yuval, nhưng ngắn gọn hơn một chút. Re: Bonus, haltifysẽ được chọn kết quả good()và nó sẽ tự đồng nhất trong cả hai trường hợp, nhưng nó vẫn sẽ quay trở lại vì (bằng phép thuật voodoo) haltify(good)tạm dừng, vì vậy nó không thực sự là một vòng lặp vô hạn như là một ràng buộc đối với câu trả lời. (Trong thực tế, cách để thực hiện haltifychỉ là chạy tranh luận, trong trường hợp đó cả hai goodevilđược cứu khỏi mâu thuẫn bằng cách chuyển hướng, nhưng tất nhiên sau đó chúng tôi buộc phải cho phép haltifyphân kỳ, đánh bại điểm này.)
Mario Carneiro

Một câu hỏi thú vị khác là liệu có thể viết một "trình biên dịch tối ưu hóa" lấy TM đầu vào và đưa ra một số tính toán kết quả tương tự, nhưng nhanh hơn. Câu trả lời phụ thuộc rất nhiều vào các chi tiết của máy móc, và là một lĩnh vực nghiên cứu tích cực. Kết quả này cho thấy rằng đối với bất kỳ trình biên dịch nào như vậy, có ít nhất một số tính toán vô hạn không thể được "tăng tốc" để thực thi trong thời gian hữu hạn (là một phiên bản vô hạn của định lý không thể nén cho các sơ đồ mã hóa). TT
Mario Carneiro

@MarioCarneiro phiên bản hữu hạn cũng áp dụng ở đây: có ít nhất một số máy turing luôn thực thi trong thời gian hữu hạn nhưng chúng không thể được tăng tốc.
John Dvorak

Có phải IEEE 754 không NaNthỏa mãn x == !x?
mèo

@tac Trong python, not float('nan')đánh giá là sai. notcũng là một trong những toán tử bạn không thể quá tải; nó luôn trả về một bool. (Bạn có thể xác định một chuyển đổi tùy chỉnh thành bool, nhưng trình thông dịch kiểm tra xem bạn thực sự đã trả về một bool). Ngay cả khi có một cách khó khăn để xây dựng một xcon trăn thỏa mãn x == not x, ví dụ này chỉ nhằm mục đích chính xác về mặt sư phạm chứ không đúng về mặt sư phạm.
Craig Gidney

6

Giả sử rằng là một máy giải quyết vấn đề này; Tôi giả sử rằng chấp nhận máy Turing và đầu vào, nhưng bạn có thể sắp xếp rằng nó chỉ chấp nhận máy Turing nếu bạn thích. Chúng tôi xây dựng một máy khác nhau hoạt động như sau. Trên đầu vào , nó chạy trên máy và đầu vào , ghi lại đầu ra là và ghi vào ô ban đầu. Bây giờ chạy trên chính nó để đạt được một mâu thuẫn.MMTxMxxb1bT


1
Không hoạt động. Thay thế các ràng buộc sau trong vấn đề ban đầu; máy Turing đầu vào được đảm bảo tạm dừng. Trong thực tế, việc giảm này cũng sai đối với vấn đề tạm dừng, nhưng vì những lý do khá khó hiểu.
Joshua

Tôi không thấy vấn đề. Có lẽ bạn có thể giải thích nó?
Yuval Filmus

1
Nếu đầu vào được đảm bảo để dừng máy, chỉ cần thực hiện nó để tìm câu trả lời và do đó không thể không làm như vậy.
Joshua

1
Để mỗi mình.
Yuval Filmus

@Joshua: Bạn đang nói rằng tất cả các máy Turing đầu vào được đảm bảo tạm dừng, hoặc một máy Turing đầu vào cụ thể được đảm bảo tạm dừng? Không có gì đảm bảo rằng tất cả các đầu vào đều dừng lại và để "chỉ thực hiện" đầu vào sẽ yêu cầu nó xác định các đầu vào tạm dừng. M
user2357112 hỗ trợ Monica

-3

Việc bạn giảm bớt vấn đề tạm dừng là một cách hợp lý. Nếu máy của bạn dừng lại, nó phải dừng trong một thời gian T dựa trên cấu trúc nguyên thủy của đầu vào. Nếu vấn đề tạm dừng là không thể giải quyết, việc xây dựng phải bị tổn thất; do đó, tồn tại một cỗ máy mà nó đoán sai và dừng lại mà không được đánh giá đầy đủ, và một chuỗi dài các lực lượng XOR đánh giá đầy đủ để đạt được câu trả lời đúng. Do đó, tồn tại một máy mà nó mang lại câu trả lời sai.

Trong thực tế, bất kỳ vấn đề không cần thiết nào không loại trừ các máy không tạm dừng vì đầu vào làm giảm vấn đề tạm dừng theo cách này. Tham chiếu: https://en.wikipedia.org/wiki/Rice's_theorem


2
Thật không may, câu trả lời của bạn không có nhiều ý nghĩa.
Yuval Filmus

Tôi không biết đoạn cuối của bạn nghĩa là gì. Hầu hết các vấn đề không làm giảm vấn đề tạm dừng; ví dụ: bộ máy Turing tạm dừng trên mọi đầu vào không thể giảm bớt vấn đề tạm dừng, mà thay vào đó là độ phức tạp lớn hơn nhiều . (0>T0)

@NoahSchweber: Đó là một định lý sâu sắc về khoa học máy tính. Bạn không thể chứng minh bất kỳ thuộc tính không cần thiết nào của tất cả các hàm đệ quy chưa được xử lý bởi vì bạn không thể giải quyết vấn đề tạm dừng. Bạn phải hạn chế miền vấn đề của mình đối với các hàm đệ quy tạm dừng.
Joshua

Định lý @Joshua Rice không phải là một "định lý sâu sắc của khoa học máy tính", đó là một định lý rất cơ bản của lý thuyết tính toán. Và nó không có nghĩa là những gì bạn dường như nghĩ nó có nghĩa - vấn đề tạm dừng thể hiện mức độ không ổn định rất yếu . (Định lý của Rice nói ngược lại với những gì bạn đã viết, trên thực tế: nó nói rằng vấn đề tạm dừng có thể giảm bớt - nghĩa là, có độ phức tạp bằng hoặc ít hơn so với - bất kỳ "thuộc tính không cần thiết nào của các hàm tính toán một phần.") có giá trị kiểm tra lại những điều cơ bản; bạn có quen thuộc với ví dụ với thực tế mà tôi đã đề cập ở trên ( ) không? 0>T0
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.