프로덕션 소프트웨어에서 일반적인 대수 지수 시간 알고리즘은 얼마나 흔합니까?

지수 시간 알고리즘은 일반적으로 피해야하지만 때로는 필요하다는 것을 알고 있습니다. 여행 판매원이 사례입니다. 프로덕션 소프트웨어에서 이러한 알고리즘은 얼마나 흔합니까? 이러한 경우가 일반적으로 필요한가요 아니면 급한 일의 결과입니까? 나는 많은 사람들이 좋은 휴리스틱으로 해결할 수 있음을 이해합니다. 일반적으로 할 수없는 것들로 무엇을합니까?

프로덕션 소프트웨어 가 아닌 프로덕션 소프트웨어 에서 수행 되는 것은 공식적인 검증 입니다. 아마도 대부분의 고객 소프트웨어에는 채택되지 않았지만 임베디드 시스템 및 드라이버, 즉 정확성이 중요하고 다루기 쉬운 하드 및 소프트웨어에 대한 추적을 얻습니다.

실제로 계산할 수있는 이러한 문제 (장벽 # 1)는 종종 EXPTIME- 하드 (hardtime)이며 , 운이 좋은 경우에는 PSPACE- 완전한 문제 (장벽 # 2)가 발생합니다. 두 클래스 모두 NP- 완료 문제보다 어렵 기 때문에 비교하기 쉽습니다. 이중 지수 문제도 쉽게 얻을 수 있습니다.

이 경우 휴리스틱 (최종 결과의 의미)은 명확한 결과가 필요하므로이를 잘라 내지 않습니다. 따라서 큰 기계와 시간이 필요합니다. 휴리스틱 (대체 선택의 의미에서)은 종종 런타임을 단축 시키며 (즉, 오류 상태가 검색 될 때 영리한 검색 공간 탐색) 발생하지만 최악의 경우 대기만하면됩니다. 또는 펜 앤 페이퍼 교정을 수행하고 컴퓨터로 검사하여 계산이 더 간단합니다.

지수 최악의 복잡한 경우 일반적으로 사용되는 알고리즘 은 선형 프로그래밍에 사용되는 단순한 방법 입니다. 그러나, 그 방법의 일반적인 복잡성은 공개 된 문제입니다. 몇 가지 구체적인 가정으로 다항식입니다.

프로그래밍 언어 인터프리터는 입력 시간, 즉 해석하는 프로그램의 길이에서 지수 시간보다 나쁘며 매우 일반적입니다. 또 다른 예는 자동 정리 증명 / 제약 해결 / Sat 해결 / 정수 선형 프로그래밍입니다. 그리고 또 다른 예는 Maple / Mathematica에서 구현 된 상징적 차별화입니다 (단, 노드간에 하위 표현을 공유 할 수 있으면 선형 시간으로 상징적 차별화를 수행 할 수 있음).

세일즈맨 여행 문제의 예를 들어 보겠습니다. 나는 몇 번 일했다.

영업 사원 문제를 해결하기위한 솔루션을 작성했지만 몇 가지 매개 변수가있는 팀에 근무한 적이 몇 번 있습니다. 예를 들어, 고유 한 기술을 갖춘 기술자와 엔지니어가있는 상점이 될 수 있습니다. 목적지는 매일 서비스 요청 형태로 나타납니다. 모든 프로그램은 처음 작성된 이후 수정 및 유지 보수를 거쳤지만 프로덕션 상태입니다.

이것이 그들이 일한 방식입니다. 각 엔지니어는 매일 휴대용 장치에서 서비스 할 항목 목록을받습니다. 각 서비스 작업을 마치면 사례를 종료해야합니다. 제외 된 사례는 고객이 불만을 표명 한 것보다 우선 순위가 약간 높은 다음 날 예정된 사례에 참여합니다. 엔지니어가 사건에 참여하지 않는 데에는 많은 이유가있었습니다. 교통 문제가 가장 흔했습니다.

그들은 얼마나 흔합니까? 최소한 고객으로부터 온 판매 후 서비스 요청 수만큼 일반적입니다. 예를 들어 애프터 서비스가 없으면 고객 유지가 어려워지고 새로운 고객 확보가 어려워집니다.

아마존과 같은 많은 웹 기반 상점과 다른 서점과 비즈니스에서 잘 작동하는 다른 상점들과 함께 여행 세일즈맨이 예전보다 더 일반적이라고 생각합니다. 또한 교과서에서 가르치는 여행하는 판매원 문제의 많은 변형이있을 수 있습니다.