알고리즘 설계의 연습과 알고리즘의 점근 적 복잡성의 관련성 설명

알고리즘과 복잡성에서 우리는 알고리즘의 점근 적 복잡성, 즉 입력의 크기가 무한대로 될 때 알고리즘이 사용하는 리소스의 양에 중점을 둡니다.

실제로, 유한 한 (아마도 많은 수의) 인스턴스에서 빠르게 작동하는 알고리즘이 필요합니다.

우리가 관심있는 유한 한 수의 인스턴스에서 실제로 잘 작동하는 알고리즘은 좋은 점근 적 복잡성을 가질 필요는 없습니다 (유한 한 수의 인스턴스에서 좋은 성능은 점근 적 복잡성과 관련된 것을 암시하지 않습니다). 마찬가지로, 점근 적 복잡성이 좋은 알고리즘은 우리가 관심을 갖고있는 유한 한 수의 인스턴스 (실제로 큰 상수로 인해)에서 실제로 잘 작동하지 않을 수 있습니다.

점근 적 복잡성을 사용하는 이유는 무엇입니까? 이러한 점근 분석은 실제로 알고리즘 설계와 어떤 관련이 있습니까?

흥미로운 질문은 대안이 무엇입니까? 내가 아는 유일한 방법은 테스트 / 벤치마킹입니다. 우리는 알고리즘을 프로그래밍하고 유한 입력 세트 (대표적 샘플)에서 실행하고 결과를 비교하게합니다. 그것에 몇 가지 문제가 있습니다.

• 결과는 기계와 관련하여 일반적이지 않습니다. 다른 컴퓨터에서 벤치 마크를 실행하면 확실하고 정량적이며 심지어 정 성적으로 다른 결과를 얻을 수 있습니다.
• 결과는 프로그래밍 언어 측면에서 일반적이지 않습니다. 다른 언어는 매우 다른 결과를 초래할 수 있습니다.
• 결과는 구현 세부 사항 측면에서 일반적이지 않습니다. 문자 그대로 알고리즘이 아닌 프로그램을 비교 합니다 . 구현의 작은 변화는 성능에 큰 차이를 일으킬 수 있습니다.
• 최악의 경우가 드물면 임의의 입력 샘플에 잘못된 인스턴스가 포함되어 있지 않을 수 있습니다. 평균적인 케이스 성능에 관심이 있지만 일부 환경에서는 최악의 보증이 필요합니다.
• 실제로 입력 세트가 변경됩니다. 일반적으로 입력은 시간이 지남에 따라 커집니다. 6 개월마다 벤치 마크를 반복하지 않으면 (예, 일부 데이터가 빠르게 커짐) 결과는 곧 가치가 없습니다 ¹.

즉, 분석에서 모든 종류의 효과와 상수를 무시하는 것이 일반적이지만 (실습과 관련하여) 게으르다 고 할 수 있습니다. 주어진 (의사 코드) 구현의 성능을 정확히 지적하는 것보다 알고리즘 아이디어 를 비교하는 역할을 합니다. 이것이 거칠고 더 자세히 살펴 보는 것이 공동체에게 잘 알려져있다. 예를 들어, Quicksort는 (매우) 작은 입력에 대한 삽입 정렬보다 효율성이 떨어집니다. 공정하게 말하면,보다 정확한 분석은 일반적으로 어렵다 .

공식적이고 추상적 인 관점에 대한 또 다른 정당화는이 수준에서 상황이 더 명확하다는 것입니다. 따라서 수십 년의 이론적 연구는 실제로 사용되는 수많은 알고리즘 아이디어와 데이터 구조를 가져 왔습니다. 이론적으로 최적 인 알고리즘은 항상 실제로 사용하려는 알고리즘이 아닙니다. 다른 고려 사항이 아니라 성능도 고려해야합니다. 피보나치 힙을 생각하십시오-이 레이블은 고유하지 않을 수도 있습니다. 산술 표현을 최적화하는 데 관심이있는 전형적인 프로그래머에게는이 수준에서 새로운 아이디어가 나올 수 없습니다. 그러나 그녀는 동화 된 아이디어에 대해 이러한 최적화를 수행 할 수 있고 수행해야합니다.

격차를 줄여 어느 정도 연습 할 수있는 공식적이고 이론적 인 도구가 있습니다. 예는

• 메모리 계층 (및 기타 I / O)을 고려하여
• 평균 사례 분석 (해당되는 경우)
• (추상적 인 비용 측정 대신) 개별 진술 수 분석
• 일정한 요소를 결정합니다.

예를 들어, Knuth는 문자 그대로 (주어진 모델에서 지정된 구현에 대해) 여러 명령문의 수를 문자 그대로 계산하여 알고리즘을 정확하게 비교할 수있는 것으로 알려져 있습니다. 이 접근 방식은 추상 수준에서는 불가능하며보다 복잡한 모델에서는 수행하기가 어렵습니다 (자바 생각). 현대적인 예는 [4]를 참조하십시오.

이론과 실제 사이에는 항상 차이가있을 것입니다. 우리는 현재 알고리즘 비용과 런타임 (평균) 모두에 대해 정확한 예측을하기 위해 두 세계의 최고를 결합하려는 목표로 툴 ³을 연구하고 있지만, 지금까지 하나의 알고리즘이 더 높은 시나리오를 제거 할 수 없었습니다. 비용은 같지만 런타임 (일부 컴퓨터에서는)에 해당하는 것보다 작습니다 (그러나이를 감지하고 이유를 찾을 수는 있지만).

실습자는 벤치 마크를 실행하기 전에 이론을 사용하여 알고리즘 공간을 필터링하는 것이 좋습니다.

if ( input size forever bounded? ) {
  benchmark available implementations, choose best
  schedule new benchmarks for when machine changes
}
else {
  benchmark implementations of all asymptotically good algorithms
  choose the best
  schedule new benchmarks for when machine changes or inputs grow significantly
}

1. 캐시 미스 수가 증가하면 절대적 및 상대적 성능에 미친 변화가있을 수 있습니다. 일반적으로 입력은 증가하지만 시스템은 동일하게 유지됩니다.
2. 마찬가지로,이 분야의 주요 연구자들은 그렇게 할 수 없습니다.
3. 여기 에서 도구를 찾으 십시오 . 예 사용은에 게시되었습니다 MaLiJAn 사용하여 엔지니어링 자바 7의 듀얼 피벗 퀵 S. 와일드 등으로. (2012) [ 서문 ]
4. S. Wild와 M. Nebel 의 Java 7 듀얼 피벗 퀵 정렬의 평균 사례 분석 (2012)-[ preprint ]

나는이 질문이 점근 분석을 포함하는 과정을 가르치는 데서 발생한다고 가정한다. 이 자료가 입문 수업에서 왜 가르치는 지에 대한 몇 가지 가능한 대답이 있습니다.

• 점근 분석은 분석 자체를 산출하는 수학적 추상화입니다. (논쟁 적으로) 수학자로서, 우리는 알고리즘을 분석 할 수 있기를 원하며, 복잡성을 길들이는 유일한 방법은 점근 분석을 사용하는 것입니다.

• 알고리즘의 점근 적 성능을 평가하면 실제로 유용한 몇 가지 원칙을 지적 할 수 있습니다. .

• 점근 분석의 일부 기술이 유용합니다. 여기에서는 주로 소위 "마스터 정리"를 언급하는데, 많은 상황에서 현실에 대한 좋은 설명입니다.

• 역사적 이유도 있습니다. 사람들이 알고리즘을 처음 분석하기 시작했을 때 점근 적 복잡성이 실제 사용을 반영한다고 진지하게 생각했습니다. 그러나 결국 그들은 틀렸다. 효율적으로 해결할 수있는 문제의 종류 인 P와 다루기 힘든 문제의 종류 인 NP에서 같은 일이 일어났다.

개인적으로 저는 점근선 분석이 교과 과정의 합리적인 부분이라고 생각합니다. 더 의심스러운 부분에는 공식 언어 이론과 복잡성 이론 (Turing 기계와 관련된 모든 것)이 포함됩니다. 어떤 사람들은이 주제들이 프로그래머 자신에게는 유용하지 않지만, 그녀에게 좋은 실용 주의자가되기 위해 필요한 특정한 생각을 심어 준다고 주장합니다. 다른 사람들은 이론이 때때로 실천에 영향을 미친다고 주장하며, 이러한 드문 경우는 이러한 비전적인 주제를 일반 컴퓨터 과학 관객에게 가르치는 데 충분합니다. 오히려 역사나 문학, 또는 실제로 관심이있는 다른 과목을 배우게하고 싶습니다. 둘 다 미래의 직업 전망과 관련이 있으며 인간으로서 그들에게 더 중요합니다.

실행 시간에 대한 점근 분석을 사용해야하는 두 가지 심각한 이유가 있습니다.

• 중요하지 않은 세부 사항을 추상화합니다. 사소한 알고리즘이 필요한 많은 응용 프로그램에서 대부분의 시간은 중간에서 많은 수의 작업이 필요한 문제 인스턴스에 소비되며 정확한 작업 수보다 일반적인 추세에 더 관심이 있습니다. 이러한 응용에서 작은 동작 은 흥미롭지 않습니다.$n$

• 수학적 다루기 쉬움을 허용합니다. 연산 횟수에 대한 정확한 표현을 찾을 수있는 경우는 예외입니다. 무증상을 연구하면 더 많은 가능성이 열립니다 (복잡한 기능의 점근 적 근사가 편리함).

그리고 많은 것들이 있습니다 (기계 독립성, 의미, 비교 가능성과 같은).

Raphael의 답변에서 언급했듯이 최악의 실행 시간을 정확하게 계산하는 것은 매우 어려울 수 있습니다. RAM 모델이 이미 근사치를 도입하므로 정확한 계산이 필요하지 않을 수도 있습니다. 예를 들어, 모든 작업이 실제로 같은 시간이 걸립니까? 특정 구현 (하드웨어, 최적화)은 일정한 요소에 의해 알고리즘 속도를 높일 수 있습니다. 우리는 알고리즘이 이러한 요소들과 독립적 으로 얼마나 효과적인지 알고 싶습니다 . 이것은 점근 분석의 사용에 대한 큰 동기입니다.

무증상은 "단순"하기 때문에 (어쨌든 유한 사례에 대한 정확한 분석을 수행하는 것보다 간단합니다).

예를 들어 Knuth의 백과 사전 "The Computer Programming of Computer Programming"을 비교해보십시오.이 알고리즘은 모든 중요한 알고리즘 (및 중요하지 않은 많은 알고리즘)에 대한 자세한 분석을 수행하며 종종 점근 추정값을 얻기에 충분한 규칙 규칙 분석 ( 또는 대부분의 "알고리즘"책에서 연습 한대로).

당신은 확실히 옳습니다. 경우 문제가 중요한만큼하는 크 누스 스타일 (또는 아마도 덜 자세한 조금) 분석을 잘 보장 할 수있다. 에서는 많은 경우, 실험 데이터에 끼워 점근 복잡도의 힌트 (아마도 분산액 평균)은 충분하다. 에서는 대부분의 경우 하는 수행하는 거친 분류 첫 번째 잡초 아웃 라운드 비교 점근 정확한 충분 수, 경쟁 알고리즘을. 그리고 경쟁자가 없다면, 정확한 세부 비용에 대한 나쁜 소식을 얻는 것은 마조히즘입니다.

여기서는 점근 분석에 의해 입력의 크기가 무한대로 진행됨에 따라 알고리즘의 동작을 의미한다고 가정합니다.

우리가 점근 분석을 사용하는 이유는 실제로 알고리즘의 동작을 예측하는 데 유용 하기 때문입니다 . 예측은 예를 들어 어떤 알고리즘을 사용해야하는지에 대한 알고리즘이 다른 경우에 결정을 내릴 수있게합니다. (유용하다고해서 항상 올바른 것은 아닙니다.)

실제 세계의 단순화 된 모델에 대해서도 같은 질문을 할 수 있습니다. 현실 세계의 단순화 된 수학적 모델을 사용하는 이유는 무엇입니까?

물리학에 대해 생각하십시오. 고전적인 뉴턴 물리학은 현실 세계를 예측하는 데 상대 론적 물리학만큼 좋지 않습니다. 그러나 자동차, 초고층 빌딩, 잠수함, 비행기, 다리 등을 만들기에 충분한 모델입니다. 위성을 만들거나 우주 탐사선을 명왕성에 보내거나 움직임을 예측하려는 경우와 같이 충분하지 않은 경우가 있습니다. 별이나 행성과 같은 거대한 천체 또는 전자와 같은 초고속 물체. 모델의 한계가 무엇인지 아는 것이 중요합니다.

1. 일반적으로 현실 세계의 근사치입니다. 실제로 우리는 더 나은 점근 분석을 가진 알고리즘이 실제로 더 잘 작동한다는 것을 종종 알 수 있습니다. 알고리즘이 더 나은 점근 적 행동을 갖는 경우는 드물기 때문에 입력이 충분히 클 수있는 경우 일반적으로 알고리즘 행동의 첫 번째 예측으로 점근 적 분석에 의존 할 수 있습니다. 입력이 작다는 것을 알고 있다면 그렇지 않습니다. 원하는 성능에 따라보다 신중한 분석이 필요할 수 있습니다. 예를 들어 입력 분포에 대한 정보가있는 경우 알고리즘에 제공되는 목표를 달성하기 위해보다 신중한 분석을 수행 할 수 있습니다 (예 : 99에서 빠르게) 입력의 %). 요점은 첫 단계로서 점근 분석은 좋은 출발점입니다. 실제로 성능 테스트도 수행해야하지만 자체 문제도 있음을 명심해야합니다.

2. 실제로 계산하는 것은 비교적 간단합니다. 일반적으로 알고리즘의 점근 적 복잡성에 대해 적어도 좋은 범위를 계산할 수 있습니다. 간단히하기 위해 모든 입력에서 다른 알고리즘보다 우수한 알고리즘 가 있다고 가정합니다 . 가 다른 사람보다 낫다 는 것을 어떻게 알 수 있습니까? 우리는 점근 적 분석을 수행하고 있음을 알 수A $A$$A$$A$더 나은 점근 적 복잡성이 있습니다. 모든 입력에서 다른 것보다 낫지 않은 것은 무엇입니까? 그러면 더 까다로워지고 우리가 관심있는 것에 달려 있습니다. 큰 입력이나 작은 입력에 관심이 있습니까? 큰 입력에 관심이 있다면 알고리즘이 더 나은 점근 적 복잡성을 갖지만 우리가 관심을 갖는 큰 입력에서 최악의 행동을하는 것은 일반적이지 않습니다. 작은 입력에 대해 더 신경 쓰면 점근 분석은 그다지 유용하지 않을 수 있습니다. 관심있는 입력에 대한 알고리즘의 실행 시간을 비교해야합니다. 실제로 복잡한 요구 사항이있는 복잡한 작업의 경우 점근 분석이 유용하지 않을 수 있습니다. 알고리즘 교과서에서 다루는 간단한 기본 문제의 경우 매우 유용합니다.

간단히 말하면 점근 적 복잡성은 간단한 기본 작업 (알고리즘 교과서의 문제)에 대한 실제 알고리즘 복잡도의 근사치를 계산하기가 비교적 쉽습니다. 보다 복잡한 프로그램을 구축함에 따라 성능 요구 사항이 변경되고 더욱 복잡해져 점근 분석이 유용하지 않을 수 있습니다.

알고리즘의 성능을 예측하고 비교하기 위해 점근 분석을 다른 접근법과 비교하는 것이 좋습니다. 일반적인 접근법 중 하나는 랜덤 또는 벤치 마크 입력에 대한 성능 테스트입니다. 예를 들어 SAT 해석과 같이 휴리스틱을 사용하는 경우 점근 적 복잡성을 계산하는 것이 어렵거나 실현 불가능한 경우가 일반적입니다. 또 다른 경우는 프로그램의 성능이 외부 요인에 의존하는 경우와 같이 요구 사항이 더 복잡한 경우이며, 목표는 일정 시간 제한 (예 : 사용자에게 표시되는 인터페이스 업데이트에 대해 생각)에서 99 %의 일정 시간 내에 완료되는 것이있을 수 있습니다. 입력.

그러나 성능 분석에도 문제가 있음을 명심하십시오. 그것은 수학에 대한 수혜자에게 성능에 대해 더 적은 것을 제공하지는 않습니다. 실제로 알고리즘에 제공 될 모든 입력에 대해 성능 테스트를 수행합니다 (종종 계산이 불가능합니다). 우리는 무작위 표본 또는 우리가 암시하는 벤치 마크에 대해에 테스트하면 가정 몇 가지 규칙 알고리즘의 성능에 대한을, 즉 알고리즘은 성능 테스트의 일부가 아닌 다른 입력에 유사하게 수행합니다.

성능 테스트의 두 번째 문제는 테스트 환경에 따라 다릅니다. 즉, 프로그램의 성능은 입력만으로 결정되는 것이 아니라 외부 요인 (예 : 머신 유형, 운영 체제, 코딩 알고리즘의 효율성, CPU 사용률, 메모리 액세스 시간 등)에 의해 결정됩니다. 같은 기계에서 테스트합니다. 여기서도 성능 테스트가 수행되는 특정 환경이 프로그램을 실행할 수있는 모든 환경에서 성능 테스트를 수행하지 않는 한 (그리고 정렬을 실행할 수있는 기계를 어떻게 예측할 수 있는지를 제외하고) 실제 환경과 유사하다고 가정합니다. 알고리즘을 10 년 만에?).

MergeSort ( ) 의 점근 적 실행 시간을 계산하고 이를 SelectionSort ( ) 또는 BinarySerch ( 의 실행 시간과 비교하는 것과 비교하십시오. )를 LinearSearch ( )와 함께 사용하십시오 .Θ ( n 2 ) Θ ( lg n ) O ( n $\Theta(n \lg n)$$\Theta(n^2)$$\Theta(\lg n)$$O(n)$

CS에서 가장 보편적 인 알고리즘 / 응용 프로그램 중 하나, 즉 정렬을 사용하는 간단한 내장형 예제는 어떻습니까? 거품 정렬이 소요 모두 평균 최악의 경우 시간과 퀵 에 대한 평균 만에 "거의"최악의 경우. 차이점을 확인하는 좋은 방법은 무작위 배열 및 성능을 정렬하는 나란히 동기화 된 애니메이션을 보는 것입니다. 거의 항상 bubblesort는 "더 오래"걸리며 하나는 quicksort와 비교하여 완료 될 때 까지 대기 합니다.O ( N 로그 N ) O ( N 2$O(n^2)$$O(n \log n)$$O(n^2)$

이제 코드가 호출되는 횟수만큼 코드에서 대기가 반복 된다고 상상해보십시오 . 퀵 정렬 알고리즘의이 명백한 우월성을 수학적으로 수량화 / 정의하는 방법은 무엇입니까? (즉, 그 이름이 실제로 정당화되었거나 단순히 마케팅 슬로건입니까?) 점근 적 복잡성 측정을 통해. 하나는 거품 정렬이 어떻게 든 약한 알고리즘이고 점근 적 복잡성 분석 이이를 정량적으로 증명할 수 있다고 주관적으로 느낀 애니메이션을보고있다 . 그러나 점근 적 복잡성 분석은 알고리즘을 분석하는 도구 중 하나 일 뿐이며 항상 궁극적 인 것은 아닙니다.

병렬 코드도 살펴볼 가치가 있습니다. bubblesort는 개념적으로 더 단순 해 보이며 재귀를 사용하지 않습니다. quicksort는 "3의 중앙값"피봇 원리와 같이 즉시 이해되지 않습니다. bubblesort는 서브 루틴없이 루프에서만 구현 될 수있는 반면 quicksort는 일반적으로 하나 이상의 서브 루틴을 가질 수 있습니다. 이것은 코드 단순화가 많을수록 코드 단순성을 희생하면서 점근 적 복잡성을 향상시킬 수있는 패턴을 보여줍니다. 때때로의 개념과 유사 극도의 tradoff이 한계 수확 체감 코드의 복잡성 매우 큰 AMTS는 점근 적 복잡성이 매우 작은 개선을 구입 [정당화하기 위해 전체 thms의 전체 서류와 증거를 요구] 여기서 (경제에서 오리지널은). 이것은 예를 들어 esp로 표시됩니다.행렬 곱셈 과 그래프 도 가능 합니다.