Chúng ta biết gì về các chương trình có thể chứng minh chính xác?

Sự phức tạp ngày càng tăng của các chương trình máy tính và các máy tính có vị trí ngày càng quan trọng trong xã hội khiến tôi tự hỏi tại sao chúng ta vẫn không sử dụng chung các ngôn ngữ lập trình mà bạn phải đưa ra bằng chứng chính thức rằng mã của bạn hoạt động chính xác.

Tôi tin rằng thuật ngữ này là một 'trình biên dịch chứng nhận' (tôi đã tìm thấy nó ở đây ): một trình biên dịch biên dịch một ngôn ngữ lập trình, trong đó người ta không chỉ phải viết mã, mà còn nêu rõ đặc tả của mã và chứng minh rằng mã tuân thủ đặc điểm kỹ thuật (hoặc sử dụng một prover tự động để làm như vậy).

Trong khi tìm kiếm trên internet, tôi chỉ tìm thấy các dự án sử dụng ngôn ngữ lập trình rất đơn giản hoặc các dự án thất bại cố gắng điều chỉnh các ngôn ngữ lập trình hiện đại. Điều này dẫn tôi đến câu hỏi của tôi:

Có bất kỳ trình biên dịch chứng nhận nào thực hiện một ngôn ngữ lập trình toàn diện, hay điều này rất khó / về mặt lý thuyết là không thể?

Ngoài ra, tôi chưa thấy bất kỳ lớp phức tạp nào liên quan đến các chương trình có thể chứng minh được, chẳng hạn như 'lớp của tất cả các ngôn ngữ có thể quyết định bằng máy Turing có bằng chứng cho thấy máy Turing này tạm dừng', mà tôi sẽ gọi , tương tự như , tập hợp các ngôn ngữ đệ quy.$ProvableR$$R$

Tôi có thể thấy những lợi thế của việc nghiên cứu một lớp phức tạp như vậy: ví dụ, đối với , vấn đề Ngừng là có thể quyết định (tôi thậm chí còn phỏng đoán được định nghĩa theo cách rõ ràng sẽ là lớp ngôn ngữ lớn nhất mà nó có thể quyết định được). Ngoài ra, tôi nghi ngờ chúng tôi sẽ loại trừ bất kỳ chương trình thực tế hữu ích nào: ai sẽ sử dụng chương trình khi bạn không thể chứng minh chương trình đó chấm dứt?$ProvableR$$ProvableRE$

Vì vậy, câu hỏi thứ hai của tôi là:

Chúng ta biết gì về các lớp phức tạp đòi hỏi ngôn ngữ chứa chúng phải có các thuộc tính nhất định?

"Trình biên dịch xác nhận" thường có nghĩa là một cái gì đó hơi khác: nó có nghĩa là bạn có một trình biên dịch có thể chứng minh rằng mã máy mà nó phát ra thực hiện chính xác ngữ nghĩa cấp cao. Đó là, đây là một bằng chứng cho thấy không có lỗi biên dịch. Các chương trình mà mọi người cung cấp cho trình biên dịch vẫn có thể sai, nhưng trình biên dịch sẽ tạo ra một phiên bản mã máy chính xác của chương trình sai. Câu chuyện thành công lớn nhất dọc theo các dòng này là trình biên dịch được xác minh CompCert , là trình biên dịch cho một tập hợp con lớn của C.

Bản thân trình biên dịch Compcert là một chương trình có bằng chứng chính xác (được thực hiện trong Coq), đảm bảo rằng nếu nó tạo mã cho một chương trình, nó sẽ đúng (đối với ngữ nghĩa hoạt động của lắp ráp & C mà các nhà thiết kế CompCert đã sử dụng). Nỗ lực kiểm tra máy những thứ này là khá lớn; thông thường, bằng chứng chính xác sẽ có kích thước từ 1 đến 100 lần kích thước của chương trình bạn đang xác minh. Viết chương trình và bằng chứng kiểm tra máy là một kỹ năng mới mà bạn phải học - nó không phải là toán học hay lập trình như bình thường, mặc dù nó phụ thuộc vào việc có thể làm tốt cả hai. Cảm giác như bạn đang bắt đầu lại từ đầu, giống như là một lập trình viên mới làm quen một lần nữa.

Không có rào cản lý thuyết đặc biệt cho điều này, mặc dù. Điều duy nhất dọc theo các dòng này là định lý Blum Size cho bất kỳ ngôn ngữ nào có tổng số chương trình, bạn có thể tìm thấy một chương trình bằng ngôn ngữ đệ quy chung sẽ lớn hơn theo cấp số nhân khi được lập trình bằng ngôn ngữ tổng. Cách để hiểu kết quả này là một ngôn ngữ tổng thể mã hóa không chỉ là một chương trình, mà còn là một bằng chứng chấm dứt. Vì vậy, bạn có thể có các chương trình ngắn với bằng chứng chấm dứt dài. Tuy nhiên, điều này không thực sự quan trọng trong thực tế, vì chúng ta sẽ chỉ viết các chương trình với bằng chứng chấm dứt có thể quản lý được.

EDIT: Dai Le yêu cầu một số chi tiết của điểm cuối cùng.

Đây chủ yếu là một tuyên bố thực dụng, dựa trên thực tế là nếu bạn có thể hiểu tại sao một chương trình hoạt động, thì không chắc lý do là một số lượng lớn bất biến dài hàng triệu trang. (Các bất biến dài nhất mà tôi đã sử dụng là một vài trang dài, và cậu bé làm cho các nhà phê bình càu nhàu

Nhưng cũng có một số lý do lý thuyết. Về cơ bản, chúng ta không biết rất nhiều cách để phát minh một cách có hệ thống các chương trình mà bằng chứng chính xác của nó rất dài. Phương pháp chính là (1) lấy logic mà bạn chứng minh tính đúng đắn, (2) tìm một thuộc tính không thể được biểu thị trực tiếp trong logic đó (bằng chứng nhất quán là nguồn điển hình) và (3) tìm một chương trình có bằng chứng chính xác dựa trên một gia đình về hậu quả rõ ràng của tài sản không thể diễn tả được. Bởi vì (2) không thể diễn tả được, điều này có nghĩa là việc chứng minh từng hậu quả rõ ràng phải được thực hiện độc lập, điều này cho phép bạn làm nổ tung kích thước của bằng chứng chính xác. Một ví dụ đơn giản, lưu ý rằng trong logic thứ nhất với quan hệ cha mẹ, bạn không thể biểu thị quan hệ tổ tiên.$k$$k$) là rõ ràng, cho mỗi cố định . Vì vậy, bằng cách đưa ra một chương trình sử dụng một số thuộc tính của tổ tiên đến độ sâu nào đó (giả sử 100), bạn có thể buộc một bằng chứng chính xác trong FOL để chứa bằng chứng về các thuộc tính đó hàng trăm lần.$k$

Sự tinh vi trong môn học này được gọi là "toán học ngược", và là nghiên cứu về các tiên đề được yêu cầu để chứng minh các định lý đã cho. Tôi không biết nhiều về nó, nhưng nếu bạn đăng câu hỏi lên ứng dụng của mình cho CS, và tôi chắc chắn ít nhất Timothy Chow, và có lẽ một vài người khác, sẽ có thể nói với bạn những điều thú vị.

Tôi nghĩ rằng câu trả lời cho câu hỏi đầu tiên là nhìn chung nó quá nhiều công việc với các công cụ hiện tại. Để có được cảm giác, tôi khuyên bạn nên cố gắng chứng minh tính đúng đắn của Bubble Sort trong Coq (hoặc nếu bạn muốn thử thách hơn một chút, hãy sử dụng Sắp xếp nhanh). Tôi không nghĩ là hợp lý khi mong đợi các lập trình viên viết các chương trình đã được xác minh miễn là việc chứng minh tính đúng đắn của các thuật toán cơ bản như vậy là rất khó khăn và tốn thời gian.

Câu hỏi này tương tự như câu hỏi tại sao các nhà toán học không viết bằng chứng chính thức có thể kiểm chứng bằng trình kiểm tra bằng chứng? Viết một chương trình với một bằng chứng chính xác có nghĩa là chứng minh một định lý toán học về mã viết và câu trả lời cho câu hỏi đó cũng áp dụng cho câu hỏi của bạn.

Điều này không có nghĩa là chưa có trường hợp thành công của các chương trình được xác minh. Tôi biết rằng có những nhóm đang chứng minh tính đúng đắn của các hệ thống như hypanneror của Microsoft . Một trường hợp liên quan là Trình biên dịch C đã được xác minh của Microsoft . Nhưng nói chung, các công cụ hiện tại cần rất nhiều sự phát triển (bao gồm các khía cạnh SE và HCI của chúng) trước khi trở nên hữu ích cho các lập trình viên nói chung (và các nhà toán học).

Về đoạn cuối câu trả lời của Neel về tăng trưởng kích thước chương trình cho các ngôn ngữ chỉ có tổng số chức năng, thực sự rất dễ để chứng minh hơn nữa (Nếu tôi hiểu chính xác). Thật hợp lý khi hy vọng rằng cú pháp của bất kỳ ngôn ngữ lập trình nào sẽ là ce và tập hợp các hàm tính toán tổng thể không phải là ce, vì vậy đối với bất kỳ ngôn ngữ lập trình nào có tất cả các chương trình đều có một hàm tính toán tổng thể không thể tính được bởi bất kỳ chương trình nào ( có kích thước bất kỳ) trong ngôn ngữ đó.

Đối với câu hỏi thứ hai, tôi đã trả lời một câu hỏi tương tự trên blog của Scott cách đây không lâu. Về cơ bản nếu lớp phức tạp có một đặc tính tốt và có thể tính toán được (nghĩa là ce) thì chúng ta có thể chứng minh rằng một số đại diện của các vấn đề trong lớp phức tạp có thể chứng minh tổng thể trong một lý thuyết rất yếu tương ứng với lớp phức tạp. Ý tưởng cơ bản là các hàm tổng số có thể chứng minh được của lý thuyết chứa tất cả các hàm và một vấn đề là A C $AC^0$$AC^0$- Hoàn thành cho lớp phức tạp, do đó nó chứa tất cả các vấn đề trong lớp phức tạp và có thể chứng minh tổng số của các chương trình đó. Mối quan hệ giữa bằng chứng và lý thuyết phức tạp được nghiên cứu về độ phức tạp của bằng chứng, xem cuốn sách gần đây của SA Cook và P. Nguyen " Các nền tảng logic của độ phức tạp chứng minh " nếu bạn quan tâm. (Một bản nháp từ năm 2008 đã có sẵn.) Vì vậy, câu trả lời cơ bản là cho nhiều lớp "Có thể là C = C".

Điều này nói chung là không đúng vì có các lớp phức tạp ngữ nghĩa không có đặc tính cú pháp, ví dụ như các hàm tính toán tổng. Nếu theo đệ quy, bạn có nghĩa là tổng các hàm đệ quy thì hai hàm này không bằng nhau và tập hợp các hàm tính toán có thể chứng minh được tổng số trong một lý thuyết được nghiên cứu kỹ trong tài liệu lý thuyết bằng chứng và được gọi là các hàm tổng thể có thể chứng minh được của lý thuyết. Ví dụ: tổng các hàm có thể chứng minh được của là các hàm có giá trị ϵ 0 (hoặc các hàm tương đương trong hệ thống T của Godel ), tổng các hàm có thể chứng minh của P A 2 là các hàm trong hệ thống F của Girard , các hàm tổng có thể chứng minh được của$PA$$\epsilon_0$$T$$PA^2$$F$ là hàm đệ quy nguyên thủy, ....$I\Sigma_1$

Nhưng dường như điều này đối với tôi không có nghĩa gì nhiều trong bối cảnh xác minh chương trình, vì cũng có những chương trình tính toán mở rộng cùng chức năng nhưng chúng tôi không thể chứng minh rằng hai chương trình đang tính toán cùng một chức năng, tức là các chương trình đều mở rộng bằng nhau nhưng không cố ý (Điều này tương tự như Sao mai và Sao đêm.) Ngoài ra, thật dễ dàng để sửa đổi một chương trình tổng thể có thể chứng minh được để có được một chương trình mà lý thuyết không thể chứng minh được toàn bộ.

Tôi nghĩ rằng hai câu hỏi có liên quan. Mục tiêu là để có được một chương trình xác minh. Một chương trình được xác minh có nghĩa là chương trình thỏa mãn một mô tả, đó là một tuyên bố toán học. Một cách là viết một chương trình bằng ngôn ngữ lập trình và sau đó chứng minh các thuộc tính của nó giống như nó thỏa mãn mô tả, đó là cách làm phổ biến hơn. Một lựa chọn khác là cố gắng chứng minh tuyên bố toán học mô tả vấn đề bằng các phương tiện bị hạn chế và sau đó trích xuất một chương trình đã được xác minh từ nó. Ví dụ, nếu chúng ta chứng minh trong lý thuyết tương ứng với rằng với bất kỳ số n đã cho nào, có một dãy số nguyên tố mà sản phẩm của chúng bằng n , thì chúng ta có thể trích xuất một $P$$n$$n$$P$thuật toán cho nhân tố từ bằng chứng. (Cũng có nhà nghiên cứu cố gắng tự động hóa cách tiếp cận đầu tiên càng nhiều càng tốt, nhưng việc kiểm tra các thuộc tính không tầm thường thú vị của các chương trình là khó tính toán và không thể được xác minh hoàn toàn nếu không có dương tính và phủ định sai.)

Những gì bạn đang hỏi về câu hỏi đầu tiên đôi khi được gọi là "trình biên dịch xác minh", và một vài năm trước Tony Hoare đã đưa ra nó như một thách thức lớn cho nghiên cứu điện toán . Ở một mức độ nào đó, điều này đã tồn tại và được sử dụng tích cực trong các công cụ như người ủng hộ định lý Coq , tổ chức vấn đề bằng lý thuyết loại và nguyên tắc loại như mệnh đề (" Curry-Howard ").

EDIT: chỉ muốn thêm nhấn mạnh vào "ở một mức độ nào đó". Điều này còn lâu mới được giải quyết, nhưng thành công của Coq mang đến hy vọng rằng đó không phải là một giấc mơ xa vời.

Một công cụ kiểm tra xem một chương trình có đúng hay không đôi khi được gọi là trình xác minh chương trình. Trong ngữ cảnh này, "chính xác" thường có nghĩa là hai điều: chương trình không bao giờ tạo ra các đầu ra nhất định (nghĩ lỗi phân đoạn, NullPulumException, v.v.) và chương trình đồng ý với một đặc tả.

Mã và đặc tả có thể đồng ý và vẫn bị coi là sai. Theo một nghĩa nào đó, yêu cầu các nhà phát triển viết thông số kỹ thuật cũng giống như yêu cầu hai nhà phát triển giải quyết vấn đề. Nếu hai triển khai đồng ý thì bạn có độ tin cậy cao hơn rằng chúng ổn. Tuy nhiên, theo một nghĩa khác, thông số kỹ thuật tốt hơn so với triển khai thứ hai. Bởi vì đặc tả không cần phải hiệu quả hoặc thậm chí có thể thực thi được, nên nó có thể ngắn gọn hơn nhiều và do đó khó bị sai hơn.

Với những lưu ý này, tôi khuyên bạn nên xem trình xác minh chương trình Spec # .

Trong trường hợp chung, không thể tạo ra một thuật toán xác nhận xem một thuật toán có tương đương với một đặc điểm kỹ thuật hay không. Đây là một bằng chứng không chính thức:

Hầu như tất cả các ngôn ngữ lập trình là Turing-Complete. Do đó, bất kỳ ngôn ngữ nào được quyết định bởi một TM cũng có thể được quyết định bởi một chương trình được viết bằng ngôn ngữ này.

$Equivalence/TM$

$Equivalence/TM$$Non-emptiness/TM$$Emptiness/TM$$Emptiness/TM$$Equivalence/TM$$Equivalence/TM$cũng không thể chấp nhận được. Do đó, bạn có thể sử dụng thuật toán cho dù hai máy có tương đương hay không, nhưng bạn không thể chắc chắn liệu chúng có tương đương hay không, hoặc bạn đã không cho thuật toán của mình đủ thời gian.

Tuy nhiên, điều này chỉ dành cho trường hợp chung. Có thể là bạn có thể quyết định xem các thông số kỹ thuật có tương đương với chương trình hay không, bằng cách giải quyết một phiên bản thoải mái hơn của vấn đề. Ví dụ: bạn chỉ có thể kiểm tra một số đầu vào hoặc nói rằng hai chương trình tương đương với một số điểm không chắc chắn. Đây là những gì kiểm thử phần mềm là tất cả về.

Đối với phần còn lại của câu hỏi của bạn:

Lưu ý: Phần này đã được chỉnh sửa để làm rõ. Hóa ra tôi đã làm sai mà tôi đang cố tránh, xin lỗi.

$TrueR$$TrueR \subseteq R$

$ProvableR = TrueR$$ProvableR \subset TrueR$$TrueR \subset ProvableR$$A \epsilon TrueR$$A$$A$$A \epsilon ProvableR$

Một cách không chính thức, điều này có thể được tóm tắt là: Bạn không biết rằng một ngôn ngữ có thể quyết định được cho đến khi bạn chứng minh được nó là ngôn ngữ. Vì vậy, nếu trong một hệ thống chính thức, bạn có kiến ​​thức rằng một ngôn ngữ có thể quyết định được, thì kiến ​​thức này cũng có thể đóng vai trò là bằng chứng cho điều đó. Do đó, bạn không thể đồng thời có kiến ​​thức rằng một ngôn ngữ là có thể quyết định và nó không thể được chứng minh vì vậy, hai tuyên bố này là loại trừ lẫn nhau.

$R$$ProvableR$$ProvableR \subset R$$R$

@Kaveh tóm tắt nó tốt nhất: Có thể chứng minh luôn có nghĩa là có thể chứng minh được trong một số hệ thống / lý thuyết và không trùng với sự thật nói chung.

Điều tương tự cũng xảy ra đối với bất kỳ lớp phức tạp nào khác: Để xác định tư cách thành viên trước tiên bạn cần có bằng chứng. Đây là lý do tại sao tôi tin rằng câu hỏi thứ hai của bạn quá chung chung, vì nó không chỉ chứa lý thuyết phức tạp, mà còn cả lý thuyết tính toán, tùy thuộc vào tài sản mà bạn muốn ngôn ngữ có.

Các chuyên khảo cổ điển sau đây nghiên cứu gần như chính xác câu hỏi thứ hai của bạn:

Hartmanis, J. Tính toán khả thi và tính chất phức tạp có thể chứng minh được , Chuỗi hội nghị khu vực CBMS-NSF về Toán ứng dụng, 30. Hiệp hội toán học công nghiệp và ứng dụng (SIAM), Philadelphia, Pa., 1978.

$\{L(M_i) | T_i(n) \leq T(n) \text{ is provable in F}\}$$M_i$$T_i(n)$$M_i$$n$

$T(n) \geq n \log(n)$$g(n) \geq 1$$F$$TIME[T(n)] \subsetneq TIME[T(n) g(n)]$

$T(n)$$F$$TIME[T(n)] \neq TIME[T(n)]$

$T(n) \geq n \log(n)$$TIME[T(n)] = \{ L(M_i) | \text{F proves} (\exists j)[L(M_j) = L(M_i) \wedge T_j(n) \leq T(n)] \}$

Đối với không gian, tuy nhiên, tình hình được kiểm soát tốt hơn:

$s(n) \geq n$$SPACE[s(n)] = F$$SPACE[s(n)]$

$SPACE[S(n)]=F$$SPACE[S(n)]$$S(n) \geq n$$s(n)$$SPACE[S(n)]=SPACE[s(n)]$

Câu hỏi phải được đặt ra chính xác. Ví dụ, không ai muốn biết liệu một chương trình thực tế có hoàn thành bộ nhớ vô hạn và một số phương tiện truy cập hay không (có thể là một thao tác để di chuyển địa chỉ cơ sở theo một số nào đó). Định lý của Turing không liên quan đến tính đúng đắn của chương trình theo bất kỳ ý nghĩa cụ thể nào và những người trích dẫn nó như một rào cản để xác minh chương trình đang nhầm lẫn hai điều hoàn toàn khác nhau. Khi các kỹ sư / lập trình viên nói về tính đúng đắn của chương trình, họ muốn biết về các thuộc tính hữu hạn. Điều này cũng khá đúng đối với các nhà toán học, những người quan tâm đến việc liệu điều gì đó có thể chứng minh được. Thư của Godel http://vyodaiken.com/2009/08/28/godels-lost-letter/ giải thích điều này một cách chi tiết.

Cụ thể, điều đó rõ ràng có nghĩa là mặc dù tính không ổn định của Entscheidungsprobols, công việc tinh thần của một nhà toán học liên quan đến câu hỏi Có hoặc Không có thể được thay thế hoàn toàn bằng máy. Rốt cuộc, người ta chỉ cần chọn số tự nhiên n lớn đến mức khi máy không mang lại kết quả, sẽ không có ý nghĩa gì khi nghĩ thêm về vấn đề.

Có thể không kiểm tra được trạng thái bao la của chương trình thực thi trên máy tính thực tế và phát hiện trạng thái xấu, không có lý do lý thuyết nào khiến nó không thể được thực hiện. Trên thực tế, đã có rất nhiều tiến bộ trong lĩnh vực này - ví dụ, hãy xem http://www.cs.cornell.edu/gomes/ con / SATSolvers-KR-book-draft-07.pdf (cảm ơn Neil Immerman cho nói với tôi về điều này)

Một vấn đề khác và khó khăn hơn là chỉ định chính xác những thuộc tính mà người ta muốn một chương trình có để có thể chính xác.