아마도 올바른 프로그램에 대해 무엇을 알고 있습니까?

점점 더 복잡 해지는 컴퓨터 프로그램과 점점 더 사회에서 컴퓨터의 중요성이 높아짐에 따라 코드가 올바르게 작동한다는 공식적인 증거를 제공해야하는 프로그래밍 언어를 집단적으로 사용하지 않는 이유가 궁금합니다.

이 용어는 '인증 ​​컴파일러'라고 생각합니다 ( 여기서 찾았습니다 ). 코드를 작성해야 할뿐만 아니라 코드의 사양을 명시하고 코드가 코드를 준수한다는 것을 입증하는 프로그래밍 언어를 컴파일하는 컴파일러 사양 (또는 자동화 된 프로 버를 사용).

인터넷을 검색하는 동안 매우 간단한 프로그래밍 언어를 사용하거나 최신 프로그래밍 언어를 적용하려는 프로젝트가 실패했습니다. 이것은 내 질문으로 이어집니다.

완전한 프로그래밍 언어를 구현하는 인증 컴파일러가 있습니까? 아니면 매우 어렵거나 이론적으로 불가능합니까?

또한, 나는 복잡 클래스는 다음과 같은 증명 프로그램과 관련된보고 아직했습니다 '증거가 존재하는 튜링 기계에 의해 모든 언어의 클래스를 decidable가이 튜링 기계가 정지'나는 부를 것이다, $ProvableR$ 에 아날로그로, $R$ , 재귀 적 언어의 집합.

I 이러한 복잡도 종류 공부의 이점을 볼 수있다 : 예를 들어,에 대한 $ProvableR$ 중단 문제가 decidable이다 (I에도 추측 $ProvableRE$ 명백한 방식으로 정의 된 것 결정 가능한 언어의 가장 큰 클래스). 또한, 실제로 유용한 프로그램을 배제 할 수 있을지 의심됩니다.

두 번째 질문은 다음과 같습니다.

포함 언어가 특정 속성을 가질 수 있어야하는 복잡성 클래스에 대해 무엇을 알고 있습니까?

"컴파일러 인증"은 일반적으로 약간 다른 것을 의미합니다. 즉, 생성하는 기계어 코드가 상위 레벨 시맨틱을 올바르게 구현 함을 증명할 수있는 컴파일러가 있음을 의미합니다. 즉, 이것은 컴파일러 버그가 없다는 증거입니다. 사람들이 컴파일러에 제공하는 프로그램은 여전히 ​​틀릴 수 있지만 컴파일러는 잘못된 프로그램의 올바른 기계 코드 버전을 생성합니다. 이 라인에서 가장 큰 성공 사례는 CompCert에서 검증 한 컴파일러 인데, 이는 C의 큰 부분 집합을위한 컴파일러입니다.

Compcert 컴파일러 자체는 정확성 증명 (Coq에서 수행)이있는 프로그램으로, 프로그램 코드를 생성 할 경우 (CompCert 설계자가 사용한 어셈블리 및 C의 작동 의미와 관련하여) 정확함을 보장합니다. 이러한 것들을 기계 점검하는 노력은 상당히 크다. 일반적으로 정확성 증명은 확인중인 프로그램 크기의 1x에서 100x 사이입니다. 기계 검사 프로그램과 증명을 작성하는 것은 배우는 새로운 기술입니다. 수학이나 프로그래밍은 아니지만 둘 다 잘 수행하는 데 달려 있습니다. 초보자 프로그래머처럼 다시 시작하는 것처럼 느껴집니다.

그러나 이에 대한 특별한 이론적 장벽은 없습니다. 이 행을 따르는 유일한 것은 모든 프로그램이 전체 언어 인 모든 언어에 대해 전체 언어로 프로그래밍 할 때 기하 급수적으로 더 큰 일반적인 재귀 언어로 프로그램을 찾을 수 있다는 Blum Size 정리 입니다. 이 결과를 이해하는 방법은 전체 언어가 프로그램뿐만 아니라 종료 증명을 인코딩한다는 것입니다. 따라서 긴 종료 증명 기능을 갖춘 짧은 프로그램을 가질 수 있습니다. 그러나 관리 가능한 종료 증명 기능이있는 프로그램 만 작성하므로 실제로는 실제로 중요하지 않습니다.

편집 : Dai Le는 마지막 요점에 대해 자세히 설명했습니다.

이것은 프로그램이 왜 작동하는지 이해할 수 있다면 그 이유가 수백만 페이지에 달하는 막대한 가능성이 거의 없다는 사실에 근거한 실질적인 주장입니다. (내가 사용한 가장 긴 불변은 몇 페이지 길이이며 소년은 리뷰어를 불평하게 만듭니다! 변하지 않는 것도 사람들이 그것을 이해하는 데 도움이되는 모든 이야기를 제거하는 이유이기 때문에 이해할 수 있습니다.)

그러나 이론적 인 이유도 있습니다. 기본적으로 정확성 증명이 매우 긴 프로그램을 체계적으로 발명하는 방법은 많이 모릅니다. 주요 방법은 (1) 정확성을 입증하는 논리를 취하고 (2) 해당 논리에 직접 표현할 수없는 속성을 찾고 (일관성 증명은 일반적인 출처 임) (3) 다음과 같은 프로그램을 찾는 것입니다. 정확성 증명은 표현할 수없는 재산의 표현 가능한 결과에 의존합니다. (2)는 표현할 수 없기 때문에 각 표현 가능한 결과의 증거는 독립적으로 수행되어야하므로 정확성 증명의 크기를 높일 수 있습니다. 간단한 예로 부모 관계가있는 1 차 논리에서는 조상 관계를 표현할 수 없습니다.$k$$k$$k$

이 주제에 대한 정교한 이해를 "역 수학"이라고하며, 주어진 이론을 증명하기 위해 어떤 공리가 필요한지에 대한 연구입니다. 나는 그것에 대해 많이 알지 못하지만 CS에 응용 프로그램에 대한 질문을 게시하면 적어도 Timothy Chow와 다른 여러 사람들이 흥미로운 것을 말할 수 있다고 확신합니다.

첫 번째 질문에 대한 대답은 일반적으로 현재 도구로 는 너무 많은 작업이라는 것 입니다. 느낌을 얻으려면 Coq에서 Bubble Sort의 정확성을 증명하는 것이 좋습니다 (또는 조금 더 도전을 원한다면 Quick Sort를 사용하십시오). 그런 기본 알고리즘의 정확성을 입증하는 것이 너무 어렵고 시간이 많이 걸리는 한 프로그래머가 검증 된 프로그램을 작성할 것으로 기대하는 것이 합리적이라고 생각하지 않습니다.

이 질문은 왜 수학자들이 증거 확인자가 검증 할 수있는 공식적인 증거를 쓰지 않는지 묻는 것과 비슷합니다. 공식적인 정확성 증명을 가진 프로그램을 작성한다는 것은 쓰여진 코드에 대한 수학적 정리를 증명하는 것을 의미하며, 그 질문에 대한 답변도 귀하의 질문에 적용됩니다.

이것은 확인 된 프로그램의 성공 사례가 없다는 것을 의미하지는 않습니다. Microsoft 하이퍼 바이저 와 같은 시스템의 정확성을 입증하는 그룹 이 있다는 것을 알고 있습니다. 관련 사례는 Microsoft의 Verified C Compiler 입니다. 그러나 일반적으로 현재 도구는 일반 프로그래머 (및 수학자)에게 유용하기 전에 많은 개발 (SE 및 HCI 측면 포함)이 필요합니다.

전체 기능 만있는 언어의 프로그램 크기 증가에 대한 Neel의 답변 의 마지막 단락과 관련하여 실제로는 더 많은 것을 쉽게 증명할 수 있습니다 (정확히 이해하면). 모든 프로그래밍 언어의 구문이 ce이고 총 계산 가능한 함수 집합이 ce가 아닌 것으로 기대하는 것이 합리적이므로 모든 프로그램이 총체 인 프로그래밍 언어의 경우 모든 프로그램에서 계산할 수없는 총 계산 가능한 함수가 있습니다 ( 해당 언어로 제공됩니다.

$AC^0$$AC^0$-복잡성 클래스에 대해 완전하므로 복잡성 클래스의 모든 문제를 포함하며 해당 프로그램의 전체 성을 증명할 수 있습니다. 증명 이론과 복잡성 이론의 관계는 증명 복잡성에 대해 연구됩니다 . 관심이 있으시면 SA Cook과 P. Nguyen의 최근 저서 인 " Proof Complexity of Proof Complexity "를 참조하십시오. ( 2008 년 초안 을 사용할 수 있습니다.) 따라서 기본적인 대답은 많은 클래스 "아마도 C = C"입니다.

$PA$$\epsilon_0$$T$$PA^2$$F$$I\Sigma_1$

그러나 같은 기능을 확장 적으로 계산하는 프로그램도 있지만 두 프로그램이 동일한 기능을 계산하고 있음을 증명할 수는 없습니다. 즉, 프로그램이 확장 적으로 동일하지만 그렇지 않다는 것을 증명할 수는 없습니다. 의도적으로. (이것은 모닝 스타 및 이브닝 스타와 유사합니다.) 또한 이론적으로 전체를 증명할 수없는 프로그램을 얻기 위해 주어진 전체 프로그램을 쉽게 수정할 수 있습니다.

$P$$n$$n$$P$증명으로부터 인수 분해를위한 알고리즘. (가능한 첫 번째 방법을 최대한 자동화하려고하는 연구원도 있지만 프로그램의 흥미로운 비 사소한 속성을 확인하는 것은 계산이 어렵고 오 탐지 없이는 완전히 확인할 수 없습니다.)

첫 번째 질문에서 묻는 것은 때때로 "확인 컴파일러"라고하며, 몇 년 전 Tony Hoare는이 를 컴퓨팅 연구를위한 커다란 도전 으로 제공했습니다 . 어느 정도까지는 이미 존재하며 Coq theorem prover 와 같은 도구에서 적극적으로 사용되고 있으며 , 이는 유형 이론 및 유형별 제안 원칙 ( " Curry-Howard ")을 통해 문제를 구성합니다 .

편집 : "어느 정도"에 중점을두고 싶었습니다. 이것은 해결 된 문제와는 거리가 멀지 만 Coq의 성공은 그것이 파이프 꿈이 아니라는 희망을줍니다.

프로그램이 올바른지 확인하는 도구를 프로그램 검증기라고도합니다. 이러한 맥락에서 "올바른"은 일반적으로 두 가지를 의미합니다. 프로그램은 특정 출력을 생성하지 않으며 (세그먼트 오류, NullPointerException 등) 사양에 동의합니다.

코드와 사양은 동의하고 여전히 잘못된 것으로 인식 될 수 있습니다. 어떤 의미에서 개발자에게 사양 작성을 요청하는 것은 두 개발자에게 문제를 해결하도록 요청하는 것과 같습니다. 두 가지 구현이 모두 동의하면 정상이라는 확신을 갖게됩니다. 그러나 다른 의미에서 사양은 두 번째 구현보다 낫습니다. 사양은 효율적이거나 실행 가능할 필요가 없기 때문에 훨씬 간결 해져서 잘못 이해하기가 더 어려울 수 있습니다.

이러한 경고를 염두에두고 Spec # 프로그램 검증기 를 살펴 보는 것이 좋습니다 .

일반적으로 알고리즘이 사양과 같은지 확인하는 알고리즘을 만드는 것은 불가능합니다. 이것은 비공식 증거입니다.

거의 모든 프로그래밍 언어는 Turing-complete입니다. 따라서 TM에 의해 결정된 모든 언어는이 언어로 작성된 프로그램에 의해 결정될 수도 있습니다.

$Equivalence/TM$

$Equivalence/TM$$Non-emptiness/TM$$Emptiness/TM$$Emptiness/TM$$Equivalence/TM$$Equivalence/TM$또한 용납 할 수 없습니다. 따라서 두 시스템이 같지 않은지 여부에 관계없이 알고리즘을 사용할 수 있지만 해당 시스템이 동등한 지 또는 알고리즘에 충분한 시간을 제공하지 않았는지 확신 할 수 없습니다.

그러나 이것은 일반적인 경우에만 해당됩니다. 보다 편안한 버전의 문제를 해결하여 사양이 프로그램과 동등한 지 여부를 결정할 수 있습니다. 예를 들어, 많은 입력 만 조사하거나 두 프로그램이 약간의 불확실성과 동일하다고 말할 수 있습니다. 이것이 바로 소프트웨어 테스트의 핵심입니다.

나머지 질문에 관해서는 :

참고 :이 부분은 설명을 위해 편집되었습니다. 내가 피하려고했던 실수를 저지른 것으로 밝혀졌습니다. 죄송합니다.

$TrueR$$TrueR \subseteq R$

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

비공식적으로 이것은 다음과 같이 요약 될 수 있습니다. 언어가 입증 될 때까지 언어를 결정할 수 있다는 것을 모릅니다. 따라서 공식적인 시스템에서 언어를 결정할 수 있다는 지식을 가지고 있다면이 지식도이를 증명할 수 있습니다. 따라서 언어를 결정할 수 있고 증명할 수 없다는 사실을 동시에 알 수는 없습니다.이 두 문장은 상호 배타적입니다.

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

@Kaveh는 그것을 가장 잘 요약합니다 : Provable은 항상 일부 시스템 / 이론에서 입증 가능하며 일반적으로 진실과 일치하지 않습니다.

다른 복잡성 클래스도 마찬가지입니다. 멤버십을 확인하려면 먼저 증명이 필요합니다. 그렇기 때문에 두 번째 질문은 언어가 갖고 싶은 속성에 따라 복잡성 이론뿐만 아니라 계산 이론도 포함하기 때문에 너무 일반적이라고 생각합니다.

다음 고전 논문은 거의 정확히 두 번째 질문입니다.

Hartmanis, J. 실현 가능한 계산 및 입증 가능한 복잡성 속성 , 응용 수학에서의 CBMS-NSF 지역 회의 시리즈, 30. SIAM (Society for Industrial and Applied Mathematics), 미국 펜실베이니아 주 필라델피아, 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)] \}$

그러나 공간의 경우 상황이 더 잘 제어됩니다.

$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)]$

질문은 올바르게 제기되어야합니다. 예를 들어, 실제 프로그램이 무한 메모리와 주어진 메모리에 접근 할 수있는 방법을 알고 싶어하는 사람은 없습니다 (기본 주소를 일부 숫자만큼 이동시키는 작업 일 수 있습니다). 튜링의 정리는 구체적인 의미에서 프로그램의 정확성과 관련이 없으며 프로그램 검증의 장벽으로 인용하는 사람들은 두 가지 다른 것을 혼동합니다. 엔지니어 / 프로그래머가 프로그램 정확성에 대해 이야기 할 때 유한 속성에 대해 알고 싶어합니다. 이것은 또한 무언가 가능성이 있는지에 관심이있는 수학자에게도 마찬가지입니다. Godel의 편지 http://vyodaiken.com/2009/08/28/godels-lost-letter/ 는 이것을 자세히 설명합니다.

즉, 엔 치도 문제의 결정 불가능 함에도 불구하고, 예 또는 아니오 질문에 관한 수학자의 정신 연구는 기계로 완전히 대체 될 수 있음을 의미합니다. 결국, 자연수 n을 너무 크게 선택하여 기계가 결과를 제공하지 않을 때 문제에 대해 더 많이 생각하는 것은 의미가 없습니다.

실제 컴퓨터에서 실행되는 프로그램의 거대한 상태 세트를 검사하고 불량 상태를 감지하는 것은 불가능할 수 있습니다. 이론적으로는 불가능한 이유가 없습니다. 실제로이 분야에서 많은 진전이있었습니다. 예를 들어 http://www.cs.cornell.edu/gomes/papers/SATSolvers-KR-book-draft-07.pdf(Neil Immerman에게 감사드립니다) 이것에 대해 말해줘)

다른 어려운 문제는 프로그램이 올바르게하기 위해 원하는 속성을 정확하게 지정하는 것입니다.