나는 버그없이 컴퓨터 프로그램을 작성하는 것보다 실수를하지 않고 수학 증명을 작성하는 것이 훨씬 쉽다는 것을 알았습니다.

이것은 내 경험보다 더 널리 퍼진 것 같습니다. 대부분의 사람들은 프로그래밍에서 항상 소프트웨어 버그를 만들고, 실수가 무엇인지 알려주는 컴파일러를 가지고 있습니다. 한 번에 실수없이 큰 컴퓨터 프로그램을 작성한 사람에 대해 들어 본 적이 없으며 버그가 없을 것이라고 확신했습니다. (실제로, 어떤 프로그램도 버그가없고, 심지어 고도로 디버깅 된 프로그램도 거의 없습니다).

그러나 사람들은 컴파일러가 실수를 한 것에 대한 피드백을 제공하지 않고 때로는 다른 사람들로부터 피드백을받지 않고도 전체 논문이나 수학 증명 책을 쓸 수 있습니다.

분명히하겠습니다. 이것은 사람들이 수학적 증거에서 실수를 저 지르지 않는다는 것이 아니라, 약간 경험이 많은 수학자에게도 실수는 그다지 문제가되지 않으며 컴파일러를 가리키는 "외부 오라클"의 도움 없이는 해결할 수 있습니다. 잘못.

사실, 이것이 사실이 아니라면 수학은 거의 불가능할 것입니다.

그래서 이것은 다음과 같은 질문을하게되었습니다. 결함없는 수학적 증거를 작성하는 것과 결함이없는 컴퓨터 코드를 작성하는 것의 차이점은 전자가 후자보다 훨씬 다루기 쉬운가?

사람들이 단순히 프로그래머가 게으르게 만드는 실수를 가리키는 컴파일러의 "외부 오라클"을 가지고 있다는 사실은 코드를 엄격하게 작성하는 데 필요한 것을 수행하지 못하게 할 수 있다고 말할 수 있습니다. 이 견해는 그들이 컴파일러가 없다면 수학자처럼 완벽 할 수 있다는 것을 의미합니다.

설득력이 있지만 내 경험을 바탕으로 프로그래밍하고 수학적 증거를 작성해 본 결과 이것이 실제로 설명이 아니라는 것은 직관적으로 보입니다. 두 가지 노력에 대해 근본적으로 다른 것이있는 것 같습니다.

나의 초기 생각은, 차이가있을 수있는 것은, 수학자에게는 정확한 증거가 모든 단일 논리 단계 만 정확하면된다는 것입니다. 모든 단계가 올바른 경우 전체 증거가 올바른 것입니다. 반면에 프로그램이 버그가 없도록하려면 모든 코드 줄이 정확해야 할뿐만 아니라 프로그램의 다른 모든 코드 줄과의 관계도 작동해야합니다.

스텝 경우 즉, 증명에서이 올바른지, 다음 단계에서 실수하고 Y 하지 않습니다 엉망 단계 X 이제까지. 그러나 코드 X 행 이 올바르게 기록되면 Y 행에서 실수를 하면 X 행 작업에 영향을 미치 므로 X 행을 쓸 때마다$X$$Y$$X$$X$$Y$$X$$X$ 우리가 다른 모든 라인에 고려의 관계를 취할합니다. 캡슐화와 모든 것을 사용하여 이것을 제한 할 수는 있지만 완전히 제거 할 수는 없습니다.

이는 수학적 증명에서 오류를 확인하는 절차는 실질적으로 증명 단계 수에서 선형이지만 컴퓨터 코드에서 오류를 확인하는 절차는 코드 줄 수에서 본질적으로 지수 적이라는 것을 의미합니다.

어떻게 생각해?

참고 :이 질문에는 다양한 사실과 관점을 탐구하는 많은 답변이 있습니다. 대답하기 전에 모든 내용을 읽고 추가 할 새로운 내용이있는 경우에만 대답하십시오. 중복 답변 또는 사실에 대한 의견을 뒷받침하지 않는 답변은 삭제 될 수 있습니다.

하나의 이유와 하나의 오해를 귀하의 질문에 대한 답변으로 제시하겠습니다.

주된 이유 는 (겉으로는) 올바른 증명을 쓰기 쉽다는 것을 그들은 매우 높은 수준에서 작성된 것입니다. 다음과 같은 프로그램을 작성할 수 있다고 가정하십시오.

function MaximumWindow(A, n, w):
    using a sliding window, calculate (in O(n)) the sums of all length-w windows
    return the maximum sum (be smart and use only O(1) memory)

프로그램 의 사양 이 구현 보다 훨씬 간결하기 때문에 이런 식으로 프로그래밍 할 때 잘못하는 것이 훨씬 더 어려울 것 입니다. 실제로 의사 코드를 코드, 특히 효율적인 코드로 변환하려고 시도하는 모든 프로그래머 는 알고리즘 아이디어 와 구현 세부 정보 사이에 큰 차이가 발생합니다 . 수학적 증거는 아이디어에 더 집중하고 세부 사항에 덜 집중합니다.

수학 증명을위한 코드의 실제 대응은 컴퓨터 지원 증명 입니다. 이것들은 일반적인 텍스트 증명보다 개발하기가 훨씬 어렵고 독자에게 "명백한"(보통 눈치 채지 못하는) 다양한 숨겨진 구석을 발견하지만 컴퓨터에는 분명하지 않습니다. 또한, 컴퓨터는 현재 비교적 작은 간격 만 채울 수 있기 때문에, 사람이 읽은 수치가 나무의 숲을 그리워 할 정도의 수준으로 증거를 정교화해야합니다.

중요한 오해 는 수학적 증거가 종종 정확 하다는 것 입니다. 실제로 이것은 아마도 낙관적 일 것입니다. 실수없이 복잡한 증거를 작성하는 것은 매우 어렵고 용지에는 종종 오류가 있습니다. 아마도 가장 유명한 최근의 경우는 약간의 1000 페이지를 포함하여 유한 단순 그룹의 분류 와일즈 '처음 시도 (의 특별한 경우) (페르마의 마지막 정리를 의미) 모듈화 정리, 각종 간격이다 quasithin 그룹 이었다 분류가 완료된 후 20 년 후에 작성된 것입니다.

Voevodsky의 논문에서 실수는 그를 의심 그가 개발을 시작 너무 많은 증거를 기록했다 호모 토피 유형 이론 , 공식적으로 호모 토피 이론을 개발하는 데 유용 논리적 프레임 워크를, 이제부터는 확인하기 위해 컴퓨터를 사용하는 모든 (적어도 자신에 따라 그 이후의 일을 입장). 이것은 극단적이고 (현재는 비현실적인) 위치이지만, 결과를 사용할 때 증거를 검토하고 그것이 올바른지 확인해야하는 경우가 여전히 있습니다. 내 지역에는 잘못된 것으로 알려져 있지만 철회 된 적이없는 논문이 몇 군데 있는데, 그 논문의 상태는 전문가들 사이에서 입에서 귀로 전달됩니다.

(나는 이것을 적절한 대답으로 만들 시간 / 관심이 없기 때문에 아마도 여기에 약간의 다운 투표를 할 위험이 있지만, 아래 인용 된 텍스트 (및 인용 된 나머지 기사)는 상당히 통찰력이 있으며, 그것들이 쓰여진 것을 고려할 때 잘 알려진 수학자에 의해 나중에 대답을 향상시킬 수 있습니다.)

제가 생각하는 것은 기존의 답변과 특별히 다르지 않다는 생각은 "증거"또는 논증이 수학적 공동체와 의사 소통하는 것이며, 그 목적은 원칙적으로 (지루한) 세부 사항을 채울 수 있음을 확신시키는 것입니다. 종종 전혀하지 않고 완전히 지정된 공식적인 증거를 얻기 위해. 이에 대한 한 가지 중요한 사례는 기존 정리를 단순히 진술하여 사용할 수 있지만 코드 재사용은 일반적으로 훨씬 더 어렵다는 것입니다. 또한 사소한 "버그"를 고려하여 코드 조각을 완전히 쓸모 없게 만들 수 있지만 (예 : SEGFAULTs) 수학 인수를 크게 그대로 남겨 둘 수 있습니다 (즉, 인수 축소없이 오류가 포함될 수있는 경우).

컴퓨터 프로그램이 전혀 작동하도록하는 데 필요한 정확성과 완전성의 표준은 수학적 커뮤니티의 유효한 증명 표준보다 몇 배나 더 높습니다. 그럼에도 불구하고, 대규모 컴퓨터 프로그램은 매우 신중하게 작성되고 매우 신중하게 테스트 된 경우에도 항상 버그가있는 것 같습니다. [...] 우리가 실천하는 수학은 다른 과학보다 형식적으로 완전하고 정확하지만, 컴퓨터 프로그램보다 형식적으로 완전하고 정확하지 않습니다. 그 차이는 단지 노력의 양과는 상관이 없습니다. 노력의 종류는 질적으로 다릅니다. 대규모 컴퓨터 프로그램에서는 무수한 호환성 문제에 엄청난 노력을 기울여야합니다. 모든 정의가 일관성을 유지하고 "양호한"개발 유용하지만 번거롭지 않은 일반성을 지니고 기능 등에 대한 "올바른"일반성을 결정하는 데이터 구조. 부기 부분과 구별되는 큰 프로그램의 작업 부분에 소비되는 에너지의 비율은 놀랍게도 작습니다. 일반 성과 기능이 추가됨에 따라 "올바른"정의가 변경되기 때문에 필연적으로 확대되는 호환성 문제로 인해 컴퓨터 프로그램은 대개 처음부터 자주 다시 작성해야합니다.

WILLIAM P. THURSTON의 수학 (pp. 9-10) 증거 및 진행에 관한 https://arxiv.org/pdf/math/9404236.pdf

EW Dijkstra를 인용하여 시작하겠습니다.

"프로그래밍은 응용 수학의 가장 어려운 분야 중 하나입니다. 가난한 수학자는 순수 수학자가 더 잘 남아 있습니다." (EWD498에서)

Dijkstra가 '프로그래밍'에서 의미하는 바는 현재 사용법과는 약간 다르지만이 인용에는 여전히 장점이 있습니다. 다른 답변은 수학의 추상화 수준이 프로그래밍보다 훨씬 높을 수 있다고 언급했습니다. 즉, 원하는 경우 까다로운 부분을 무시할 수 있습니다.

그러나 나는 이것이 증거와 컴퓨터 프로그램 사이의 근본적인 차이의 결과 일 뿐이라고 믿습니다. 이것이 목적 입니다.

수학적 증거의 주된 목적은 무엇보다도 수학적 주장이 정확하고 아마도 더 중요하다는 것을 이해 하도록 설득하는 것입니다 . 따라서 수학적 세계에서만 일하도록 선택할 수 있습니다. 모든 학생들 은 디자인 에 의해 이해에 도달 할 수 있습니다. (거의) 수학적 사실과 속성에 대한 이해에만 관심이 있습니다.

따라서 올바른 증거를 만드는 것은 비교적 내결함성이 있습니다. 전체 "운동"의 요점입니다. (이것은 실수가 존재하지 않거나 간신히 존재한다는 것을 의미하지는 않습니다.

이제 프로그래밍을 고려한다면 우리의 목적은 무엇입니까? 우리는 실제로 이해를 추구하는 것이 아니라 작동 하는 것을 원합니다 . 그러나 언제 "작동"합니까? 어떤 이상한 기계가 우리가 원하는 작업을 완료 할 수 있도록하는 무언가를 성공적으로 만들었을 때 어떤 것이 작동합니다.

이것은 우리의 목표가 단순히 우리의 프로그램이 "증명"하는 어떤 정리로 표현 될 수 없다는 것을 의미하기 때문에 근본적인 차이점이라고 생각합니다. 는 수학적인 인공물이 아닌 실제 세계 (무엇이든)를 . 이것은 우리가 기계를 달래 야하기 때문에 이론적으로 우리의 목표를 달성 할 수 없다는 것을 의미합니다. 어쩐지.

따라서 결국 시도하고 실패하고 수정하고 실패하고 결과에 다소 만족할 때까지 다시 시도하는 것 외에 다른 방법은 없습니다.

결함이없는 증명을 작성한다는 가설은 결함이없는 프로그램 ( @Ariel이 지적한 것과는 다른 진술 임 )이 실제로 잘못 될 수 있다는 것 보다 간단합니다. 증거는 종종 시행 착오를 통해 어떤 수준에서 구성되기 때문입니다. 그럼에도 불구하고 이것이 "암묵적인 이론을 증명하는 것과 프로그램을 작성하는 것의 차이점은 무엇입니까?" ( Curry-Howard 서신 의 부주의 한 관찰자는 "아무것도 없다!"라고 말할 수 있습니다.)

주석에 언급 된 @wvxvw와 같이 '구조적 프로그래밍에 대한 참고 사항'(21 페이지, EWD249)의 다음 단락은 매우 관련이 있습니다.

(...) 프로그램 자체는 결코 목표가 아닙니다. 프로그램의 목적은 계산을 불러 일으키고 계산의 목적은 원하는 효과를 설정하는 것입니다. 프로그램은 프로그래머에 의해 만들어진 최종 제품이지만, 가능한 계산은 "메이킹"이 기계에 남습니다! -그의 거래의 진정한 주제입니다. 예를 들어, 프로그래머가 자신의 프로그램이 정확하다고 말할 때마다 실제로 계산할 수있는 계산에 대한 주장을합니다.

(...) 어떤 의미에서 프로그램을 만드는 것은 수학 이론을 만드는 것보다 어렵습니다. 프로그램과 이론은 모두 체계적이고 영원한 개체입니다. 그러나 수학적 이론은 의미가 있지만 프로그램은 실행을 통해서만 의미가 있습니다.

Lamport는 증명 을 작성하는 방법 (8-9 페이지) 에서 증명 오류의 유병률에 대한 의견 불일치를 제공합니다 .

약 20 년 전, 저는 수학 수업을위한 슈뢰더-베른슈타인 정리의 증거를 작성하기로 결정했습니다. 내가 찾을 수있는 가장 간단한 증거는 Kelley의 고전적인 일반 토폴로지 텍스트입니다. Kelley는보다 세련된 청중을 위해 글을 쓰고 있었기 때문에 그의 반쪽 증거에 많은 설명을 추가해야했습니다. Kelley의 증거가 잘못되었다는 것을 깨달았을 때 5 페이지를 썼습니다. 최근에 나는 증명 스타일에 대한 설득력있는 틀린 증거로 강의를 보여주고 싶었 기 때문에 Kelley를 찾았다. 나는 그의 증거로 아무 문제도 찾을 수 없었다. 분명히 맞았다! 그 증거를 읽고 다시 읽게되면 20 년 전에 기억이 나지 않았거나 어리 석 었음을 확신하게되었습니다. 여전히 Kelley의 증거는 짧았고 좋은 예가 될 것이므로 구조적 증거로 다시 작성하기 시작했습니다.

...이 스타일은 내가 Martin Abadi와 함께 쓴 논문에서 평범한 정리의 증명에 처음으로 적용되었습니다. 그는 이미 우리와 아마도 심판을 설득하기에 충분한 기존의 증거를 썼다. 증명을 구조화 된 스타일로 다시 작성하면서, 이론은 정확하지만 거의 모든 사람이 심각한 실수를 저지른 것을 발견했습니다. 다음의 공동 작업에서 잘못된 증거가 잘못된 이론으로 이어지지 않을 것이라는 희망은 없어졌습니다. 때때로, 우리는 추측을하고 칠판에 증거 스케치를 작성합니다.이 스케치는 설득력있는 전통적인 증거로 쉽게 변할 수 있었지만, 구조화 된 증거를 작성하여 추측이 틀렸다는 것을 발견하기 위해서였습니다. 그 이후로, 나는 신중하고 구조적인 증거가 없으면 결과를 믿지 않았습니다.

한 가지 큰 차이점은 프로그램은 일반적으로 입력에서 작동하도록 작성되는 반면 수학적 증명은 일반적으로 일련의 공리와 사전에 알려진 이론에서 시작한다는 것입니다. 때로는 충분히 일반적인 증거를 얻기 위해 여러 모퉁이 사례를 다루어야하지만 사례와 해결 방법이 명시 적으로 열거되고 결과의 범위가 해당 사례에 암시 적으로 제한됩니다.

가능한 입력 범위에 대해 '올바른'출력을 제공해야하는 컴퓨터 프로그램과 이것을 비교하십시오. 모든 입력을 열거하고 모두 시도하는 것은 거의 불가능합니다. 더 나쁜 것은, 프로그램이 인간과 상호 작용하고 입력이 기능을 수정하도록 허용한다고 가정 해보십시오. 인간은 예측할 수 없을 정도로 악명 높으며, 인간과의 상호 작용을 통해 합리적으로 큰 프로그램에 입력 할 수있는 숫자는 엄청나게 증가합니다. 프로그램이 사용될 수있는 모든 다른 방법을 예측하고 실패가 유일한 옵션 일 때 모든 유스 케이스를 작동 시키거나 최소한 합리적인 방법으로 실패하도록해야합니다. 그리고 그것은 당신도이 어떻게 알고 가정거야 되어 모든 모호한 구석 경우에 작동 할 수 있습니다.

마지막으로 큰 프로그램은 실제로 단일 증명, 심지어 복잡한 것까지 비교할 수 없습니다. 큰 프로그램은 아마도 작은 문헌 라이브러리를 수집하고 검토하는 것과 더 비슷할 것입니다. 일부는 해결해야 할 오류가있을 수 있습니다. 작은 알고리즘 구현 일 수있는 단일 증명 규모의 프로그램의 경우, 숙련 된 소프트웨어 엔지니어는 특히 일반적인 사소한 오류 (예 : 철자 오류)를 예방 / 해결하는 최신 도구를 사용할 때 실수없이 프로그램을 완성 / 실행할 수 있다고 가정 해 봅시다. )는 교정시 해결해야 할 초기 문제와 동일합니다.

그들은 컴퓨터의 문제는 당신이 말하는 것을 정확하게 한다는 것입니다.

나는 이것이 여러 가지 이유 중 하나라고 생각합니다.

컴퓨터 프로그램에서 기록기 (사용자)는 똑똑하지만 판독기 (CPU)는 바보입니다.
그러나 수학적 증거로 작가 (귀하)는 똑똑하고 독자 (검토 자) 또한 똑똑하다.

이것은 당신이 컴퓨터로 "잘, 당신은 내가 무슨 뜻 인지 알 것"에 빠질 여유가 없다는 것을 의미 합니다. 의도를 모른 채 정확히 말해줍니다.

예를 들어, 이것이 어떤 증거의 한 단계라고 가정 해 봅시다.

당신이 평가하기 위해 컴퓨터를 말한다면 다음으로 나누면 X + 3 , 당신이 할 프로그램에 질식 것 X = - 3 . 그러나 수학자는이 점을 불필요하게 고착시키지 않을 것입니다. 그는 이것이 당신이 만들고자하는 시점과 관련이 없을 가능성이 높으며,이 사소한 문제를 포기하고 불평하는 것은 누구에게도 도움이되지 않는다는 것을 깨달았습니다. 그는 단지 당신을 따르지 않기 때문에 당신이 의미하는 것을 얻을 것입니다 ; 그는 당신 을 이해 합니다. 독자가 똑똑하면 실패하기가 더 어렵습니다.$x^2+4x+3$$x+3$$x = -3$

Yuval의 답변에서 해결되지 않은 한 가지 문제는 다른 동물을 비교하고 있다는 것입니다.

"코드가 정확한지"의미 론적 진술을 말하고, 당신은 당신의 코드에 의해 기술 된 오브젝트는 모든 입력을 특정 속성, 예를 만족하는 말을 의미 은 계산 N을 $n$$n!$. 이것은 실제로 어려운 작업이며 답을 얻으려면 단순한 구문을 넘어야합니다. 이것에 대한 당신의 수학적 비유는 "이 증거가 맞습니까?"입니다. 이것은 올바른 비유가 "이 정리가 사실이고, 그렇다면 어떻게 증명할 수 있습니까?"라는 것이 거의 공평하지 않습니다. 전자는 "쉽게"검증 될 수있는 구문 설명이지만, 후자는 훨씬 더 어렵다 (경도가 공식화 될 수있다). 당신이 생각해 낸 가장 복잡한 코드를 생각해보고, Poincaré의 추측 (현재 정리)을 증명하는 것과 비교해보십시오.

프로그램의 시맨틱 특성을 검증하는 것은 결정 불가능하며 (Rice 's theorem) 유사하게, 1 차 술어 논리의 명령문이 참인지 여부도 판별 할 수 없습니다. 요점은 문제를 보는 방식과 경도의 차이가 거의 없다는 것입니다. 다른 한편으로, 우리는 프로그램 (컴파일러)의 구문 적 속성에 대해 추론 할 수 있으며, 이것은 증명을 확인할 수 있다는 사실과 유사합니다. 버그 (코드는 내가 원하는 것을하지 않습니다)는 의미 론적이므로 올바른 버그와 비교해야합니다.

Yuval을 강화하고 일부 공식 시스템에서 작성하고 검증 할 수있는 수학적 증거를 작성하려는 동기로 전체 분야가 성장했다고 말하므로 검증 프로세스조차도 사소한 것은 아닙니다.

결함이없는 수학적 증거를 작성하고 결함이없는 컴퓨터 코드를 작성하여 전자가 후자보다 훨씬 다루기 쉽도록 만드는 것과 다른 점은 무엇입니까?

주된 이유는 dem 등성 (동일한 입력에 대해 동일한 결과를 제공함)과 불변성 (변경되지 않음)이라고 생각합니다.

화요일에 읽거나 1999 년에서 2000 년으로 진급했을 때 수학적 증거가 다른 결과를 줄 수 있다면 어떨까요? 수학적 증거의 일부가 몇 페이지 뒤로 돌아가서 몇 줄을 다시 쓴 다음 그 시점부터 다시 시작한다면 어떨까요?

그러한 증거는 컴퓨터 코드의 일반적인 세그먼트만큼 버그가 발생하기 쉽다고 확신합니다.

나는 다른 이차적 요인들도 본다 :

1. 수학자들은 일반적으로 중요하고 출판 가능한 증거를 작성하기 전에 훨씬 더 교육을받습니다. 자칭 전문 개발자의 1/4은 6 년 전에 코딩을 시작 했지만 ( SO 설문 조사 2017 참조 ) 대부분의 수학자들이 10 년이 넘는 공식 수학 교육을 받았다고 가정합니다.
2. 수학적 증거는 컴퓨터 코드와 같은 수준의 정밀한 조사가 이루어지지 않습니다. 한 번의 오타로 인해 프로그램이 중단 될 수는 있지만 수십 번의 오타만으로는 증명의 가치를 파괴하기에 충분하지 않을 수 있습니다 (가독성).
3. 악마는 세부 사항에 있으며 컴퓨터 코드는 세부 정보를 건너 뛸 수 없습니다. 증명은 단순 / 루틴으로 간주되는 단계를 건너 뛸 수 있습니다. 현대 언어로 사용 가능한 멋진 구문 설탕이 있지만, 하드 코딩되어 있으며 비교가 상당히 제한적입니다.
4. 수학은 나이가 많고 기초 / 핵심이 더 견고합니다. 수학에는 새롭고 반짝이는 서브 필드가 많이 있지만, 핵심 원칙의 대부분은 수십 년 동안 사용되어 왔습니다. 이것은 안정성으로 이어집니다. 다른 한편으로, 프로그래머들은 여전히 ​​기본적인 코딩 방법론에 동의하지 않습니다 (애자일 개발 및 채택률에 대해 물어보십시오).

유발이 쓴 것에 동의합니다. 그러나 더 간단한 대답도 있습니다. 실제로 소프트웨어 엔지니어는 일반적으로 프로그램의 정확성을 확인하려고 시도하지도 않고 단순히 프로그램의 정확성을 정의하는 조건을 기록하지도 않습니다.

여러 가지 이유가 있습니다. 하나는 대부분의 소프트웨어 엔지니어가 수학적으로 문제를 명확하게 공식화 할 수있는 기술이없고 정확성 증명을 작성하는 방법을 모른다는 것입니다.

또 다른 하나는 복잡한 소프트웨어 시스템 (특히 분산 시스템)에 대한 정확성 조건을 정의하는 것은 매우 어렵고 시간이 많이 걸리는 작업이라는 것입니다. 그들은 몇 주 만에 작동하는 것으로 보입니다.

또 다른 이유는 프로그램의 정확성이 다른 의미의 의미를 가지지 않는 다른 시스템이 작성한 다른 많은 시스템에 달려 있기 때문입니다. 귀하의 도서관 / 서비스에 관찰 가능한 행동 (계약의 일부가 아님)이있는 경우 누군가가 그에 의존 할 것이라고 본질적으로 말하는 하이 럼의 법이 있습니다. 그것은 본질적으로 수학의 정리와 같은 명확한 계약을 가진 모듈 형태의 소프트웨어를 개발한다는 아이디어가 실제로 작동하지 않음을 의미합니다. 리플렉션이 사용되는 언어에서는 더 나빠집니다. 오늘날 프로그램이 정확하더라도 누군가가 의존성 중 하나에서 사소한 리팩토링을 수행하면 내일 고장날 수 있습니다.

실제로 일반적으로 발생하는 것은 테스트가 있다는 것입니다. 테스트는 프로그램에서 예상되는대로 작동합니다. 새로운 버그가 발견 될 때마다 테스트를 추가하여 발견합니다. 그것은 어느 정도까지 작동하지만 정확성 증거는 아닙니다.

사람들이 정확성을 정의 할 수있는 능력이 없거나 올바른 프로그램을 작성하지 못하거나 그렇게하는 것이 어렵다고 생각할 때 소프트웨어가 정확하지 않은 것은 놀라운 일이 아닙니다.

그러나 결국 더 나은 곳에서 소프트웨어 엔지니어링은 코드 검토를 통해 이루어집니다. 즉, 프로그램 작성자는 다른 사람에게 프로그램이 올바르게 작동 함을 확신시켜야합니다. 그것이 비공식적 인 고수준 논증의 요점입니다. 그러나 일반적으로 정확성에 대한 명확한 엄격한 정의 나 정확성의 증거에 가까운 것은 없습니다.

수학에서 사람들은 정확성에 중점을 둡니다. 소프트웨어 개발에는 프로그래머가 신경 써야 할 것들이 많으며 그들 사이에는 상충 관계가 있습니다. 버그가없는 소프트웨어 또는 정확성에 대한 올바른 정의 (시간이 지남에 따라 요구 사항이 변경됨)를 갖는 것이 이상적이지만 다른 요소와 교환해야하며 그 중 가장 중요한 요소 중 하나는 기존 소프트웨어 개발에 소요되는 시간입니다 개발자. 따라서 실제로 더 나은 곳에서 목표와 프로세스는 소프트웨어를 버그없이 만드는 것이 아니라 가능한 한 버그의 위험을 완화합니다.

이미 좋은 답변이 많이 있지만 수학과 프로그래밍이 동일하지 않은 더 많은 이유가 있습니다.

1 수학 증명은 컴퓨터 프로그램보다 훨씬 간단한 경향이 있습니다. 가상 증거의 첫 단계를 고려하십시오.

a를 정수로하자

b를 정수로하자

c = a + b라고하자

지금까지 증거는 괜찮습니다. 비슷한 프로그램의 첫 단계로 바꾸어 봅시다 :

a = 입력 ();

b = 입력 ();

c = a + b라고하자;

우리는 이미 수많은 문제가 있습니다. 사용자가 실제로 정수를 입력했다고 가정하면 경계를 확인해야합니다. 가 이상 -32768 (시스템 또는 무엇이든 분 INT는)? 가 32767보다 작은? 이제 b에 대해서도 같은 것을 확인해야합니다 . 그리고 우리는 a 와 b를 추가했기 때문에 프로그램은 a + b 가 아니면 정확하지 않습니다.-32768보다 크고 32767보다 작습니다. 이것은 프로그래머가 수학자가 무시할 수있는 것에 대해 걱정해야하는 5 가지 개별 조건입니다. 프로그래머는 그들에 대해 걱정할 필요가있을뿐만 아니라, 이러한 조건 중 하나가 충족되지 않을 때 수행 할 작업을 파악하고 자신이 결정한 조건을 처리하는 방법은 코드를 작성해야합니다. 수학은 간단합니다. 프로그래밍이 어렵다.

2 질문자는 컴파일 타임 오류 또는 런타임 오류를 언급하고 있는지 말하지 않지만 프로그래머는 일반적으로 컴파일 타임 오류에 신경 쓰지 않습니다. 컴파일러는 그것들을 찾아서 쉽게 고칠 수 있습니다. 그들은 오타와 같습니다. 사람들은 처음 몇 번이나 오류없이 몇 개의 문단을 입력합니까?

3 훈련.아주 어린 나이부터 우리는 수학을 배우도록 지시받으며 사소한 실수로 인해 계속해서 또 다른 결과에 직면하게됩니다. 숙련 된 수학자는 보통 중학교에서 다단계 대수 문제를 해결하기 시작했고 1 년 동안 매주 수십 (또는 그 이상)의 문제를 해결해야했습니다. 음수 부호 하나만 삭제하면 전체 문제가 잘못되었습니다. 대수 후에 문제가 길어지고 어려워졌습니다. 반면에 프로그래머는 일반적으로 공식 교육이 훨씬 적습니다. 많은 사람들이 자율적으로 (최소한 초기에) 배우고 대학까지 공식 교육을받지 못했습니다. 대학 수준에서도 프로그래머는 상당히 많은 수학 수업을 수강해야하지만 수학자는 아마도 한두 개의 프로그래밍 수업을 듣게됩니다.

나는 Yuval의 대답이 마음에 들지만 조금만 사용하고 싶었습니다. 수학 증명을 작성하는 것이 더 쉬운 이유 중 하나는 플라톤 식 수학 온톨로지의 방식으로 요약 할 수 있습니다. 무슨 뜻인지 보려면 다음을 고려하십시오.

• Math의 함수는 순수합니다 (함수 호출의 전체 결과는 반환 값에 완전히 캡슐화되어 결정적이며 입력 값에서 완전히 계산 됨).
• 수학에는 돌연변이 나 재 할당이 없습니다 (이러한 것들을 모델링해야 할 때 함수와 시퀀스가 ​​사용됩니다).
• 수학은 참조 적으로 투명합니다 (예 : 포인터, 이름 별 호출 대 값별 개념 없음). 똑같은 것).

위의 제한으로 인해 프로그램 작성 이 더 쉬운 지 여부는 논쟁의 여지가 있지만, 위의 제한으로 인해 프로그램 에 대한 추론이 더 쉬워진다는 광범위한 동의가 있다고 생각 합니다. 수학 증명을 작성할 때 가장 중요한 것은 현재 작성중인 증명에 대한 이유입니다 (프로그래밍과 달리 추상화가 자유 로움에 따라 수학에서 노력을 반복 할 필요가 없기 때문에). 위의 제한.

근본적인 수학적 증거는 실제 인간의 요구를 충족 시키도록 설계된 실제 적용에는 해당되지 않습니다.

인간은 컴퓨터 프로그램 영역에서 매일 가능한 것에 대한 욕구, 요구 및 요구 사항을 바꿀 것입니다.

결함이없는 수학적 증거를 작성하고 결함이없는 컴퓨터 코드를 작성하여 전자가 후자보다 훨씬 다루기 쉽도록 만드는 것과 다른 점은 무엇입니까?

수학적 문제만큼 명확한 요구 사항이 있으면 결함없는 프로그램을 작성할 수 있습니다. Dijkstra의 알고리즘이 그래프에서 두 점 사이의 최단 경로를 찾을 수 있음을 증명하는 것은 임의의 입력을 허용하고 두 점 사이의 최단 점을 찾는 프로그램을 구현하는 것과 다릅니다.

관리해야 할 메모리, 성능 및 하드웨어 문제가 있습니다. 나는 알고리즘을 작성할 때 그것들을 관리하기 위해 순수하고 기능적인 구조를 사용할 수 있다고 생각할 수는 없지만 컴퓨터 프로그램은 "실제"하드웨어 세계에 살고 수학 증거는 "이론"에 있습니다.

더 간결 해지 려면 :

학계 이외의 환경에서 다른 각도에서 보면 종종 돈이됩니다.

다른 게시물도 잘 설명했듯이 Math는 단일 추상 사양이므로 증명하려면 해당 사양 내에서 일관되게 작동해야합니다. 컴퓨터 프로그램은 수학의 추상 사양의 많은 구현에서 작동 할 수 있습니다. 즉, 한 언어 또는 하드웨어 제조업체가 부동 소수점 수학을 구현하는 방식이 다른 점과 약간 다를 수 있으며 결과에 약간의 변동이 발생할 수 있습니다.

따라서 컴퓨터 프로그램을 작성하기 전에 '증명'하면 하드웨어 수준, 운영 체제 수준, 드라이버 수준, 프로그래밍 언어, 컴파일러, 해석기 등의 모든 가능한 논리 조합에 대해 논리를 증명해야합니다. 실행 가능한 데이터와 수집 가능한 데이터가있을 수 있습니다. 우주 임무, 무기 시스템 또는 원자력 제어 시스템에 대한 이러한 수준의 준비와 이해는 아마도 실패는 수백억 달러의 손실과 잠재적으로 많은 생명을 잃은 것을 의미하지만 그 밖의 많은 것은 아닙니다.

'매일'프로그래머 및 / 또는 비즈니스의 경우 대부분 올바른 코드에서 특정 수준의 정확도를 수용하고 사용 가능한 제품을 판매하는 것이 훨씬 더 비용 효과적이며 개발자는 버그가 발견되는 동안 소급하여 버그를 수정할 수 있습니다 용법.

귀하의 추론은 유효하지만 귀하의 의견은 유효하지 않습니다. 수학 증명은 둘 다 인간이 작성한 경우 단순히 프로그램보다 내결함성이 아닙니다. Dijkstra는 이미 여기에 인용되었지만 추가 견적을 제공 할 것입니다.

그러나 우리는 제한된 힘으로 계산하여 원하는 효과를 얻을 수 있도록 계산을 구성해야합니다. 이 조직은 프로그램의 구성을 포함하고 우리는 다음 크기의 문제, 즉 직면하고 있습니다. 프로그램 텍스트의 길이, 그리고 우리는이 문제를 명시 적으로 인식해야합니다. 우리는 텍스트를 읽거나 쓸 수있는 정도가 그 크기에 크게 좌우된다는 사실을 알고 있어야합니다. [...]

"명확성"이 정량적 측면을 강조했다는 사실에 대해 독자의주의를 끌고 싶었던 것과 같은 분위기에 있습니다. 많은 수학자들이 흥미롭게도 사실을 모르고있는 것 같습니다. 10 페이지 분량의 조건이 충족 될 때 결론의 타당성을 나타내는 정리는 정리가 호소 될 때마다 모든 조건을 확인해야하므로 편리한 도구가 아닙니다. 유클리드 기하학에서 피타고라스의 정리는 A와 C를 통해 A와 C를 통해 직선이 B와 C를 통해 직선과 직교로 그려 질 수 있도록 3 개의 점 A, B 및 C에 대해 유지합니다. 또는 모든 점 A, B 및 C가 일치합니까? 그러나 이것은 피타고라스 정리를 사용할 수있는 편의성에 크게 책임이있는 것 같습니다.

요약 : 느리게 이해되는 인간으로서 나는 머리가 매우 작고 그것을 살면서 내 한계를 존중하고 그것들을 무시하려고하지 않고 완전한 신용을주는 법을 배우는 것이 낫습니다. 실패로 처벌.

이것은 Dijkstra의 구조적 프로그래밍의 첫 번째 장에서 마지막 세 단락으로 약간 편집되었습니다.

아마도 이것을 바꾸어 말하면, 당신의 질문에 더 잘 적용 할 수 있습니다 : 정확성은 대체로 당신의 증거의 크기의 함수입니다. 긴 수학적 증거의 정확성은 확립하기가 매우 어렵습니다 (발표 된 "증거"는 실제로 아무도 확인하지 않았기 때문에 불확실성의 림보에 살고 있습니다). 그러나 사소한 프로그램의 정확성을 사소한 증거와 비교하면 눈에 띄는 차이가 없을 것입니다. 그러나 자동화 된 교정 보조자 (넓은 의미에서 Java 컴파일러는 교정 보조자이기도합니다)는 많은 기초 작업을 자동화하여 프로그램이 이길 수 있도록합니다.

다른 답변이 답변에서 언급했듯이 (정교하게하고 싶습니다), 문제의 큰 부분은 라이브러리 사용입니다. 완벽한 문서 (버그없는 코드와 마찬가지로)를 사용하더라도 라이브러리를 사용하는 모든 프로그래머에게 라이브러리에 대한 완전한 지식을 전달하는 것은 불가능합니다. 프로그래머가 라이브러리를 완벽하게 이해하지 못하면 라이브러리를 사용할 때 실수를 할 수 있습니다. 때로는 코드가 작동하지 않을 때 발견되는 중요한 버그가 발생할 수 있습니다. 그러나 사소한 버그의 경우 눈에 띄지 않을 수 있습니다.

수학자가 기존의 증명과 정리를 완전히 이해하지 않고 사용했다면 비슷한 상황이 될 것입니다. 그들 자신의 증거는 결함이있을 수 있습니다. 이것은 해결책이 하나의 라이브러리를 사용하는 모든 것을 완벽하게 배우는 것임을 암시 할 수 있지만; 이것은 실제로 시간이 많이 걸리고 프로그래머가 가지고 있지 않은 도메인 지식을 필요로 할 수 있습니다.

더 간결하게 말하면, 소프트웨어 엔지니어링 (일반적으로 실제로 엔지니어링)은 다른 수준의 추상화를 캡슐화하여 사람들이 전문화 된 문제의 작은 영역에 집중할 수 있도록합니다.이를 통해 사람들은 해당 영역의 전문 지식을 개발할 수 있지만 훌륭한 의사 소통이 필요합니다 각 층 사이. 의사 소통이 완벽하지 않으면 문제가 발생합니다.

나는 그 위대한 대답 후에 독창적이 되려고 노력할 것입니다.

프로그램 은 증거입니다

카레 - 하워드의 동형 프로그램의 유형이 정리하고 실제 코드가 증거입니다, 우리에게 알려줍니다.

분명히 이것은 매우 추상적이고 높은 수준의 견해입니다. 아마도 당신이 의미하는 문제는 전형적인 코드 것이 너무 낮기 때문에 더 어렵다는 것입니다. 대부분의 경우 "기계에게해야 할 일을 알려야합니다". 또는 다른 방법으로 이것을 살펴보면 수학자들은 추상화에 능숙합니다.

참고로 "스트림 음악" 은 둘 사이에서 가장 아름다운 다리 중 하나입니다. 그것은 기본적으로 "내가 원하는 말을 할 수있는 것들을 설정 이 에서 그 방법"및 기계 마술 않습니다 이 원하는대로 정확히.

다른 많은 답변들 중 어느 것도 다음을 지적하지 않습니다. 수학적 증거는 무한한 메모리와 무한한 컴퓨팅 능력을 가진 가상의 컴퓨팅 시스템에서 작동합니다. 따라서 임의의 숫자를 무한정 정밀도로 보유 할 수 있으며 계산시 정밀도를 잃지 않습니다.

$\pi$

그렇지 않습니다. 수학 증명은 본질적으로 버그가 많으며 독자가 컴파일러보다 더 관대 한 것입니다. 마찬가지로, 컴퓨터 프로그램의 독자는 적어도 그들이 그것을 실행하려고 할 때까지 그것이 정확하다고 믿기 쉽습니다.

예를 들어, 수학 증명을 ZFC와 같은 공식 언어로 번역하려고하면 버그도 포함됩니다. 이러한 증명이 실제로 길어질 수 있기 때문에 증명을 생성하는 프로그램을 작성해야합니다. 근본적인 증거를 공식화하는 데 활발한 연구가 있지만 위험에 처한 사람은 거의 없습니다.

실제로 수학은 BSOD를 얻을 수 있습니다! 처음이 아니에요!

충분히 검증 된 모든 수학적 증거가 본질적으로 정확하거나 정확할 수 있다는 정통 아이디어는 직장에서 소프트웨어 프로젝트를 동기 부여하는 것과 동일합니다. 로드맵을 유지하는 한 모든 버그를 해결합니다 완벽한 기능-최종 제품으로 이어지는 반복적 인 프로세스입니다.

여기에 반전이 있습니다. 우리는 이미 자금을 확보하고 비즈니스 개념을 검증했으며 모든 문서가 여기에 있습니다. 우리는 단지 당신이 실행하기를 원하며 그것은 확실합니다!

힐버트에게 유감스럽게 생각하지 말자 , 자신이 무엇을하는지 알고있었습니다. 사업 일뿐입니다.

당신이 정말로 확신하기를 원한다면 모든 것을 사례별로 가져 가서 자신 만의 결론을 내리십시오!

프로그램이 수학 증명보다 오류가 발생하기 쉬운 두 가지 중요한 이유가 있습니다.

1 : 프로그램에는 시간이 지남에 따라 변하는 변수 또는 동적 객체가 포함되어 있지만 교정의 수학적 객체는 일반적으로 정적입니다. 따라서 수학의 표기법은 프로그램에서 작동하지 않는 추론에 대한 직접적인 지원으로 사용될 수 있습니다 (그리고 a = b 인 경우에도 마찬가지입니다). 또한 프로그램이 병렬이거나 여러 스레드가있는 경우이 문제가 훨씬 악화됩니다.

2 : 수학은 종종 비교적 깔끔하게 정의 된 객체 (그래프, 매니 폴드, 링, 그룹 등)를 가정하지만 프로그래밍은 매우 복잡하고 불규칙적 인 객체를 처리합니다. 유한 정밀도 산술, 유한 스택, 문자 정수 변환, 포인터, 수집이 필요한 쓰레기 등 ... 따라서 정확성과 관련된 조건의 수집은 명심하기가 매우 어렵습니다.

두 가지 다른 "범주"를 구별해야합니다.

• 의사 증명 (또는 의사 코드)-그것은 당신이 책에서 보는 것입니다. 자연 언어로 작성됩니다 (예 : 영어). 이것이 수학 (또는 알고리즘)을 배우기 위해 사용해야하는 것입니다.
• 정식 증명 (또는 정식 코드)-증명 (또는 코드)을 기계적으로 검증 (또는 실행 가능)해야 할 때 작성합니다. 이러한 표현에는 "인간 지능"이 필요하지 않습니다. 미리 정의 된 몇 가지 단계 (일반적으로 오늘날 컴퓨터에서 수행)를 수행하여 기계적으로 검증 (또는 실행) 할 수 있습니다.

우리는 수천 년 동안 의사 코드 (예 : Euclids 알고리즘)를 사용해 왔습니다. 공식 코드 작성 (C 또는 Java와 같은 공식 언어로 작성)은 컴퓨터가 발명 된 후 매우 인기 있고 유용 해졌습니다. 그러나 슬프게도 공식적인 증거 (Principia Mathematica 또는 Metamath와 같은 공식 언어)는 그리 인기가 없습니다. 오늘날 모든 사람들이 의사 증거를 작성하기 때문에 사람들은 종종 새로운 증거에 대해 논쟁합니다. 실제 "증명"이후 몇 년, 수십 년 또는 수백 년 동안 실수가 발견 될 수 있습니다.

참조를 찾을 수 없지만 Tony Hoare는 한 번 다음 줄을 따라 무언가를 말했다고 생각합니다. 프로그램 확인과 증명 확인의 차이점은 한 번에 두 줄씩 증명을 확인할 수 있다는 것입니다.

한마디로 : 지역성.

증명은 쉽게 확인할 수 있도록 작성되었습니다. 프로그램은 실행될 수 있도록 작성되었습니다. 이러한 이유로 프로그래머는 대개 프로그램을 확인하는 사람에게 유용한 정보를 생략합니다.

x가 읽기 전용 인이 프로그램을 고려하십시오.

    assume x >= 0
    p := 0 ;
    var pp := 0 ;
    while( x >= pp + 2*p + 1 ) 
    {
        var q := 1 ;
        var qq := q ;
        var pq := p ;
        while(  pp + 4*pq + 4*qq <= x )
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

실행하기는 쉽지만 확인하기는 어렵습니다.

그러나 누락 된 어설 션을 다시 추가하면 각 할당 시퀀스가 ​​사전 및 사후 조건에 맞는지 확인하고 각 루프마다 루프의 사후 조건이 암시되는지 확인하여 프로그램을 로컬로 확인할 수 있습니다 루프 가드의 불변 및 부정.

    assume x >= 0
    p := 0 ;
    var pp := 0 ; 
    while( x >= pp + 2*p + 1 ) 
        invariant p*p <= x 
        invariant pp == p*p
        decreases x-p*p 
    {
        var q := 1 ;
        var qq := q ; 
        var pq := p ; 
        while(  pp + 4*pq + 4*qq <= x )
            invariant (p+q)*(p+q) <= x
            invariant q > 0 
            invariant qq == q*q 
            invariant pq == p*q 
            decreases x-(p+q)*(p+q)
        {
            q, pq, qq := 2*q, 2*pq, 4*qq ;
        }
        assert (p+q)*(p+q) <= x and pp==p*p and pq==p*q and qq==q*q and q>0
        p, pp := p + q, pp + 2*pq + qq ;
    }
    assert  p*p <= x < (p+1)*(p+1)

원래의 질문으로 돌아 가기 : 왜 수학 증명을 작성하는 것이 컴퓨터 코드를 작성하는 것보다 내결함성이 있습니까? 증명은 독자가 쉽게 확인할 수 있도록 설계되었으므로 작성자가 쉽게 확인할 수 있으므로 경고 작성자는 증명에 논리적 오류를 만들지 않는 경향이 있습니다. 우리가 프로그래밍 할 때, 우리는 종종 우리의 코드가 올바른 이유를 적지 않습니다. 결과적으로 독자와 프로그램 작성자 모두 코드를 확인하기가 어렵습니다. 결과적으로 저자는 오류를 만들고 유지합니다.

그러나 희망이 있습니다. 프로그램을 작성할 때 프로그램이 정확하다고 생각하는 이유를 적어두면 코드를 작성할 때 코드를 검사하여 버그가 적은 코드를 작성할 수 있습니다. 이것은 또한 다른 사람들이 우리 코드를 읽고 스스로 확인할 수 있다는 이점이 있습니다.

우리는 증명을 작성하거나 코드를 작성하는 것이 실제로 어려운지 또는 원칙적으로 어려운지를 물을 수 있습니다.

실제로, 증명은 코딩보다 훨씬 어렵습니다. 2 년 동안 대학 수준의 수학을 수료 한 사람은 소수에 불과합니다. 2 년 동안 대학 수준의 CS를 습득 한 사람들 중 30 % 이상이 FizzBuzz 를 해결할 수 있습니다. .

그러나 원칙적으로 다른 이유는 근본적인 이유가 있습니다. 원칙적으로 증거는 판단이나 이해가 필요없는 프로세스를 통해 정확성을 검사 할 수 있습니다. 프로그램은 할 수 없습니다. 우리는 처방 된 프로세스를 통해 프로그램이 중단되는지 여부를 알 수 없습니다.

수학적 진술 중 일부만이 사실로 입증 될 수 있습니다. 더 중요한 것은, 모든 진실한 진술이 입증 될 수있는 사소한 (*) 수학적 공리 세트를 구성하는 것은 불가능할 것이다. 컴퓨터로 할 수있는 것의 작은 부분을 수행하기 위해 프로그램을 작성해야한다면, 아마도 올바른 소프트웨어를 작성하는 것이 가능하지만, 컴퓨터는 종종 올바른 것의 범위를 벗어난 일을하도록 요구받습니다. 소프트웨어는 달성 할 수 있습니다.

(*) 모든 실제 진술을 열거하고 입증 할 수있는 일련의 공리를 정의 할 수 있지만 일반적으로 그다지 흥미롭지는 않습니다. 공리 집합을 공식적으로 분류 할 수는 있지만, 상대적으로 말하거나, 비 사소한 것으로 공시 할 수 있지만, 핵심은 사실이지만 입증 할 수없는 진술의 입증 가능한 존재는 집합의 결함이 아니라는 것입니다 공리. 기존의 사실이지만 실현 불가능한 진술을 입증 할 수 있도록 공리를 추가하면 다른 진술은 사실이 될 수 있지만 진술 할 수는 없습니다.

1. 컴퓨터 프로그램은 실제 환경에서 테스트됩니다. 제한된 수의 사람들 만 이해할 수있는 긴 수학적 증거에서 까다로운 기술적 오류는 발견되지 않은 채 남아있을 가능성이 높습니다. 소프트웨어 제품에서 동일한 종류의 오류가 발생하면 일반 사용자가 알 수있는 이상한 동작이 발생할 수 있습니다. 따라서 전제가 올바르지 않을 수 있습니다.

2. 컴퓨터 프로그램은 유용한 실제 기능을 수행합니다. 이를 위해 100 % 정확할 필요는 없으며, 높은 정확성 표준은 꽤 비쌉니다. 증명은 실제로 무언가를 증명하는 경우에만 유용하므로 '100 % 정답'부분을 건너 뛰는 것은 수학자에게는 옵션이 아닙니다.

3. 수학 증명이 명확하게 정의됩니다. 증거에 결함이 있으면 저자가 실수 한 것입니다. 요구 사항이 제대로 전달되지 않았거나 프로그래머가 들어 본 적이없는 것과 호환성 문제가 있기 때문에 컴퓨터 프로그램의 많은 버그가 발생합니다.

4. 많은 컴퓨터 프로그램이 올바른 것으로 입증 될 수 없습니다. 얼굴 인식과 같이 비공식적으로 정의 된 문제를 해결할 수 있습니다. 또는 주식 시장 예측 소프트웨어와 같고 공식적으로 정의 된 목표를 가지고 있지만 실제 변수가 너무 많습니다.

인간 활동으로서의 수학의 많은 부분은 증명이 검증하기 쉬운 도메인 특정 언어의 개발이었습니다.

증명의 품질은 길이와 복잡성에 반비례합니다. 고려중인 특정 증거 내에서 상호 작용하는 보조 개념과 함께, 우리가 진술하고있는 상황을 설명하기위한 좋은 표기법을 개발함으로써 길이와 복잡성을 줄일 수 있습니다.

이것은 쉬운 과정이 아니며, 연구의 최전선에서 제거 된 사람들이 목격 한 대부분의 증거는 그 분야의 표기법이 수백 년 또는 수천 년이었던 수학적 분야 (대수 및 분석과 같은)에 있습니다. 실제로 증거를 기록하는 행위가 산들 바람처럼 느껴지는 지점까지 개선되었습니다.

그러나 연구의 최전선에서, 특히 잘 정립 된 또는 잘 개발 된 표기법을 가진 분야에 있지 않은 문제에 대해 작업하는 경우, 올바른 증거를 작성하는 것조차도 올바른 프로그램을 작성하는 것이 어려워집니다. 동시에 프로그래밍 언어 디자인의 아날로그를 작성하고, 신경망을 올바르게 컴파일하도록 훈련시키고, 증명을 작성하고, 메모리 부족, 언어 최적화, 언어를 배우면서 뇌를 반복하고 증거를 다시 쓰십시오.

다시 말하지만, 올바른 증거를 작성하는 것은 수학의 특정 영역에서 올바른 프로그램을 작성하는 데 어려움을 겪을 수 있다고 생각하지만, 수학 분야의 진보라는 개념은 증명의 용이성과 밀접하게 관련되어 있기 때문에 해당 영역은 반드시 젊고 저개발 상태입니다. 확인.

내가 만들고자하는 요점을 표현하는 또 다른 방법은 프로그래밍 언어와 수학이 컴퓨터 프로그램과 증명을 각각 컴파일 할 수 있도록 고안된 것입니다. 컴퓨터 프로그램을 컴파일하는 것은 컴퓨터에서 수행되며 일반적으로 프로그램 자체의 정확성과는 거의 관련이없는 구문 정확성을 보장하는 반면, 증거를 "컴파일"하는 것은 사람이 수행하며 구문 정확성을 보장합니다. 증거의 정확성.

솔직히 사과와 오렌지를 비교하고 있습니다. 내결함성 및 버그없는 가없는 것은 같은 것이 아닙니다.

프로그램이 숫자를 비교하는 경우 2그리고 3그것은 말한다 2 is greater than 3, 그것은 때문에 버그가 구현 될 수있다 :

# Buggy implementation
function is_a_greater_than_b(a,b):
  return b > a

그래도 프로그램에는 여전히 결함이 없습니다. 두 숫자를 비교할 때 a및 이 (가)보다 큰 b경우 항상 알려줄 수 있습니다 . 그것은 당신 (프로그래머)이 컴퓨터에게 요구 한 것이 아닙니다.ba

a) 컴퓨터 프로그램이 수학 증명보다 더 크기 때문에

a.1) 복잡한 컴퓨터 프로그램을 작성하는 동안 수학 증명을 작성하는 것보다 더 많은 사람들이 사용한다고 생각합니다. 실수 마진이 높다는 것을 의미합니다.

b) CEO / 주주는 작은 버그를 수정하는 것보다 돈에 더 관심을 갖기 때문에 개발자는 일부 요구 사항 / 마감일 / 데모를 충족시키기 위해 작업을 수행해야합니다.

c) 당신은 comp sci에서 "심층적 인"지식없이 프로그래머가 될 수 있기는하지만, 수학에서는 어렵습니다.

또한 :

NASA :

이 소프트웨어는 버그가 없습니다. 인간이 성취 한 것만 큼 완벽합니다. 다음 통계를 고려하십시오. 프로그램의 마지막 3 개 버전 (각 420,000 줄 길이)에는 각각 하나의 오류 만있었습니다. 이 소프트웨어의 최신 11 개 버전에는 총 17 개의 오류가있었습니다.

소프트웨어의 업그레이드를 통해 셔틀이 글로벌 포지셔닝 위성 (Global Positioning Satellites), 프로그램의 1.5 % 또는 6,366 줄의 코드로 변경 될 수 있습니다. 한 번의 변경에 대한 사양은 전화 번호부보다 두꺼운 2,500 페이지를 실행합니다. 현재 프로그램의 스펙은 30 개의 볼륨을 채우고 40,000 페이지를 실행합니다.

https://www.fastcompany.com/28121/they-write-right-stuff

기본 수준 :

수학의 경우 :
2 + 3 = 5

나는 아주 어렸을 때에 대해 배웠습니다. 가장 기본적인 요소 인 2 개의 객체와 3 개의 객체를 볼 수 있습니다. 큰.

컴퓨터 프로그래밍의 경우 대부분의 사람들은 고급 언어를 사용하는 경향이 있습니다. 일부 고급 언어는 C와 같은 하위 고급 언어 중 하나로 "컴파일"될 수 있습니다. 그런 다음 C를 어셈블리 언어로 번역 할 수 있습니다. 그런 다음 어셈블리 언어는 기계 코드로 변환됩니다. 많은 사람들이 복잡성이 끝났다고 생각하지만, 그렇지 않습니다. 최신 CPU는 머신 코드를 명령으로 사용하지만 실제로는 "마이크로 코드"를 실행하여 해당 명령을 실행합니다.

이것은 가장 기본적인 구조 (가장 단순한 구조를 다루는 것)에서 하드웨어에 내장되어 있고 대부분의 프로그래머가 직접 사용하지 않거나 업데이트하지 않는 마이크로 코드를 다루고 있음을 의미합니다. 실제로, 대부분의 프로그래머는 마이크로 코드 (마이크로 코드보다 0 레벨 높음)를 건드리지 않을뿐만 아니라 대부분의 프로그래머는 머신 코드 (마이크로 코드보다 1 레벨 높음) 또는 어셈블리 (마이크로 코드보다 2 레벨 높음)를 건드리지 않습니다 ( 아마도 대학에서 약간의 정식 훈련을 제외하고). 대부분의 프로그래머는 3 단계 이상의 시간을 보냅니다.

또한 우리가 의회 (일반적으로 사람들이 얻는 수준이 낮은 수준)를 살펴보면, 각 단계는 일반적으로 훈련을 받고 그 단계를 해석 할 자원이있는 사람들이 이해할 수 있습니다. 이런 의미에서 어셈블리는 고급 언어보다 훨씬 간단합니다. 그러나 어셈블리는 매우 간단하여 복잡한 작업이나 평범한 작업을 수행하는 것이 매우 지루합니다. 고급 언어는 우리를 자유롭게 해줍니다.

"역 엔지니어링"에 관한 법률에서 판사는 이론적으로 코드를 한 번에 1 바이트 씩 처리 할 수 ​​있다고하더라도 현대 프로그램에는 수백만 바이트가 포함되므로 일부 코드 (예 : 코드 사본)는 이러한 코드에 대해서만 작성해야한다고 선언했습니다. 실현 가능한 노력. (따라서 내부 개발은 저작권법의 일반화 된 "사본 없음"규칙을 위반하는 것으로 간주되지 않았습니다.) (저는 무단 세가 제네시스 카트리지를 만드는 것을 생각하고 있지만 게임 지니 사건에서 언급 된 것을 생각하고있을 수 있습니다. )

현대화:

286을위한 코드를 실행합니까? 아니면 64 비트 코드를 실행합니까?

수학은 수천 년 동안 거슬러 올라가는 기본을 사용합니다. 컴퓨터를 사용하는 사람들은 일반적으로 20 년 전의 투자가 쓸모없는 자원 낭비라고 생각합니다. 즉, 수학을 훨씬 더 철저히 테스트 할 수 있습니다.

사용 된 도구의 표준 :

나는 (나보다 더 공식적인 컴퓨터 프로그래밍 교육을받은 친구에 의해) C 사양을 충족시키는 버그가없는 C 컴파일러 같은 것은 없다는 것을 배웠다. C 언어는 기본적으로 스택 목적으로 무한 메모리를 사용할 가능성을 가정하기 때문입니다. 분명히, 사람들이 본질적으로 좀 더 유한 한 실제 기계로 작동하는 사용 가능한 컴파일러를 만들려고 할 때 그러한 불가능한 요구 사항을 벗어나야했습니다.

실제로 Windows Script Host의 JScript를 사용하면 객체를 사용하여 많은 것을 얻을 수 있음을 알았습니다. (새 코드를 작성하는 데 필요한 도구 세트가 최신 버전의 Microsoft Windows에 내장되어 있기 때문에 환경이 마음에 듭니다.)이 환경을 사용할 때 때로는 개체의 작동 방식에 대해 쉽게 찾을 수있는 설명서가없는 것을 발견했습니다. 그러나 객체를 사용하면 매우 유익하므로 어쨌든 그렇게합니다. 그래서 내가 할 일은 코드를 작성하는 것입니다. 호넷의 둥지로 버그가있을 수 있으며, 샌드 박스가있는 환경에서 효과를 볼 수 있고 상호 작용하면서 객체의 동작에 대해 배울 수 있습니다.

다른 경우에는 때때로 개체의 동작을 파악한 후에 만 ​​개체 (운영 체제와 함께 제공됨)에 버그가 있으며 Microsoft가 의도적으로 결정한 것으로 알려진 문제는 해결되지 않음을 알게되었습니다. .

이러한 시나리오에서 나는 정기적으로 (1 년에 두 번) 정기적으로 새 릴리스를 작성하는 마스터 프로그래머가 만든 OpenBSD를 10 년 이상 유명한 "원격 홀 2 개"로 신뢰합니까? (심지어 심각한 문제에 대한 정오표도 있습니다.) 아닙니다. Microsoft Windows를 사용하는 컴퓨터를 사람들에게 제공하는 비즈니스를 지원하는 비즈니스를 위해 일하고 있기 때문에 이러한 고품질의 제품에 의존하지 않으므로 코드가 작동해야합니다.

실용성 / 사용 가능성은 사람들이 유용하다고 생각하는 플랫폼에서 작업해야하며, 보안이 매우 나쁜 플랫폼입니다 (동일한 회사의 제품이 훨씬 더 악화 된 밀레니엄 초기부터 대폭 개선 되었음에도 불구하고). .

요약

컴퓨터 프로그래밍에 오류가 발생하기 쉬운 이유는 여러 가지가 있으며 이는 컴퓨터 사용자 커뮤니티에서 받아들입니다. 실제로 대부분의 코드는 오류없는 노력을 허용하지 않는 환경에서 작성됩니다. (보안 프로토콜 개발과 같은 일부 예외는 이와 관련하여 조금 더 많은 노력을 기울일 수 있습니다.) 더 많은 돈을 투자하기를 원하지 않는 기업의 일반적인 생각과 고객을 행복하게 만드는 인공 마감일을 놓치는 것의 영향은 다음과 같습니다. 너무 많은 시간을 소비하면 상황이 10 년 안에 크게 변하기 때문에 쓸모없는 플랫폼을 사용하게 될 것입니다.

어쨌든, 나는 strlen과 strcpy에 대한 소스 코드를 보았을 때 매우 유용하고 인기있는 기능이 얼마나 짧은 지 놀랐습니다. 예를 들어, strlen은 "int strlen (char * x) {char y = x; ( (y ++)); return (yx) -1;}" 과 같은 것일 수 있습니다 .

그러나 일반적인 컴퓨터 프로그램은 그보다 훨씬 길다. 또한 많은 현대적인 프로그래밍은 덜 철저하게 테스트되거나 버그가있는 것으로 알려진 다른 코드를 사용합니다. 오늘날의 시스템은 "낮은 수준으로 처리되는 세부 사항"으로 많은 미세한 부분을 손으로 흔드는 것을 제외하고는 쉽게 생각할 수있는 것보다 훨씬 정교합니다.

이 필수 복잡성과 복잡하고 잘못된 시스템으로 작업 할 때의 확실성으로 인해 컴퓨터 프로그래밍은 사물이 훨씬 간단한 수준으로 내려 오는 경향이있는 많은 수학보다 검증하기 위해 많은 하드웨어를 만듭니다.

수학으로 사물을 분해하면 아이들이 이해할 수있는 개별 조각에 도달하게됩니다. 대부분의 사람들은 수학을 신뢰합니다. 적어도 기본 산술 (또는 적어도 카운팅).

실제로 컴퓨터 프로그래밍을 분석하여 실제로 어떤 일이 일어나고 있는지 확인하면 결국 전자적으로 실행되는 깨진 표준 및 코드의 깨진 구현으로 끝나게되고 실제 구현은 대부분의 대학 교육을받은 컴퓨터 과학자들이하는 마이크로 코드보다 한 단계 아래에 있습니다. 감히 만지지 마십시오 (그들이 알고 있다면).

나는 버그가없는 코드를 작성할 수 있다는 개념에 반대하는 대학 또는 최근 졸업생의 일부 프로그래머와 이야기했습니다. 그들은 가능성을 기록했으며 인상적인 예 (내가 보여줄 수있는)가 설득력있는 주장이라는 것을 인정하지만, 그러한 샘플을 대표적 드문 우연한 것으로 간주하고 여전히 셀 수있는 가능성을 무시합니다. 더 높은 표준을 갖는 데 (수학에서 볼 수있는 훨씬 더 신뢰할 수있는 기초와는 훨씬 다른 태도입니다.)

수학적 증거는 "무엇"지식과 프로그램이 "지식"을 설명합니다.

프로그램 작성은 프로그래머가 발생할 수있는 모든 다른 상태와 프로그램의 동작이 어떻게 변하는 지에 대해 추론해야하기 때문에 더 복잡합니다. 증명은 공식 또는 범주 추론을 사용하여 다른 정의에 대한 사항을 증명합니다.

대부분의 버그는 프로그래머가 예상하지 못한 상태로 들어가는 프로세스로 인해 발생합니다. 프로그램에는 일반적으로 정적 데이터가 아니지만 실제로 프로그램이 실행되는 방식을 변형시키는 수천 개의 또는 큰 시스템에는 수백만 개의 가능한 변수가 있습니다. 이러한 상호 작용은 모두 예상 할 수없는 동작을 생성합니다. 특히 컴퓨터 밑에서 추상화 계층이 변경되는 최신 컴퓨터에서는 불가능합니다.

증거로, 상태 변경이 없습니다. 토론의 정의와 목적은 고정되어 있습니다. 증명은 일반적으로 문제에 대해 생각하고 많은 경우를 고려할 것을 요구하지만, 그러한 경우는 정의에 의해 수정됩니다.