루프로는 할 수없는 재귀로 할 수있는 것이 있습니까?

루프를 사용하는 것보다 재귀를 사용하는 것이 좋을 때가 있고 재귀를 사용하는 것보다 루프를 사용하는 것이 더 좋은 경우가 있습니다. "올바른"것을 선택하면 리소스를 절약하거나 코드 줄을 줄일 수 있습니다.

루프가 아닌 재귀를 사용하여 작업을 수행 할 수있는 경우가 있습니까?

예, 아니오 궁극적으로 반복이 계산할 수없는 재귀는 없지만 루프는 훨씬 더 많은 배관이 필요합니다. 따라서 루프가 할 수없는 재귀가 할 수있는 한 가지는 일부 작업을 매우 쉽게 만드는 것입니다.

나무를 걷다. 재귀와 함께 나무를 걷는 것은 어리석은 일입니다. 세상에서 가장 자연스러운 것입니다. 고리가 달린 나무를 걷는 것은 훨씬 간단합니다. 수행 한 작업을 추적하려면 스택 또는 다른 데이터 구조를 유지해야합니다.

종종 문제에 대한 재귀 적 해결책이 더 예쁘다. 그것은 기술적 용어이며 중요합니다.

아니.

아래에 도착 매우 계산하기 위해 필요한 최소의 기본, 당신은 (혼자가 충분하지 않고, 필요한 구성 요소입니다) 루프 할 수 있어야합니다. 방법 은 중요하지 않습니다 .

Turing Machine을 구현할 수있는 모든 프로그래밍 언어를 Turing complete 라고 합니다. 그리고 완전한 언어가 많이 있습니다.

"실제로 작동합니까?" 튜링 완전성의이다 FRACTRAN 이다, 완전한 튜링을 . 하나의 루프 구조를 가지며 Turing 기계를 구현할 수 있습니다. 따라서 계산 가능한 모든 것은 재귀가없는 언어로 구현 될 수 있습니다. 따라서,이없는 것도 재귀 간단한 루프는 할 수 없습니다 계산 가능성의 측면에서 당신을 제공 할 수 있습니다.

이것은 실제로 몇 가지 요점으로 요약됩니다.

• 계산 가능한 모든 것은 튜링 머신에서 계산할 수 있습니다.
• Turing 기계를 구현할 수있는 모든 언어 (Turing complete라고 함)는 다른 언어가 할 수있는 모든 것을 계산할 수 있습니다.
• 재귀가없는 언어로 된 튜링 머신이 있고 ( 다른 esolang에 들어갈 때만 재귀가있는 다른 머신이 있기 때문에) 재귀로 할 수있는 것은 없습니다. 루프 (그리고 재귀로는 할 수없는 루프로는 할 수없는 일).

이것은 반복이 아닌 재귀 또는 재귀가 아닌 반복으로 더 쉽게 생각할 수있는 몇 가지 문제 클래스가 있다고 말하는 것은 아닙니다. 그러나이 도구들도 마찬가지로 강력합니다.

그리고 나는 이것을 'esolang'극단으로 가져 갔지만 (주로 Turing이 완벽하고 다소 이상한 방식으로 구현 된 것을 찾을 수 있기 때문에) esolang이 선택 사항이라는 것을 의미하지는 않습니다. 매직 더 개더링, 센드 메일, 미디어 위키 템플릿, 스칼라 타입 시스템을 포함하여 실수로 튜링 완료된 것들 의 전체 목록이 있습니다. 실제로는 실제적인 작업을 수행 할 때 이러한 도구를 사용하여 계산 가능한 모든 항목을 계산할 수 있다는 점에서 최적의 성능과는 거리가 멀습니다.

이 동등성은 tail call이라고 알려진 특정 유형의 재귀에 들어갈 때 특히 흥미로울 수 있습니다 .

가지고 있다면, 다음과 같이 작성된 계승 법을 생각해 봅시다.

int fact(int n) {
    return fact(n, 1);
}

int fact(int n, int accum) {
    if(n == 0) { return 1; }
    if(n == 1) { return accum; }
    return fact(n-1, n * accum);
}

이 유형의 재귀는 사용 된 스택이없는 루프로 다시 작성됩니다. 이러한 접근법은 종종 등가 루프가 작성되는 것보다 더 우아하고 이해하기 쉽지만, 모든 재귀 호출에 대해 등가 루프가 작성 될 수 있으며 모든 루프에 대해 재귀 호출이 작성 될 수 있습니다.

복잡하고 될 수있는 꼬리 호출 재귀 호출로 간단한 루프를 변환 시간도 있습니다 더 이해하기 어렵다.

이론 측면으로 들어가려면 교회 튜링 논문을 참조하십시오 . CS.SE 의 교회 튜링 논문 이 유용하다는 것을 알 수 있습니다.

루프가 아닌 재귀를 사용하여 작업을 수행 할 수있는 경우가 있습니까?

재귀 알고리즘은 루프로 전환 할 수 있습니다. 재귀 호출은 정확히 현재 상태를 스택에 저장하고 알고리즘을 진행하기 때문에 AKA 스택을 사용하여 임시 상태를 저장합니다. 나중에 상태를 복원합니다. 그래서 짧은 대답은 : 아니요, 그런 경우는 없습니다 .

그러나 "예"에 대한 주장은 가능합니다. 구체적이고 쉬운 예를 들어 보자 : 병합 정렬. 데이터를 두 부분으로 나누고, 부분을 병합 정렬 한 다음 결합해야합니다. 부품에 대해 병합 정렬을 수행하기 위해 병합 정렬을 위해 실제 프로그래밍 언어 함수 호출을 수행하지 않더라도 실제로 함수 호출을 수행하는 것과 동일한 기능을 구현해야합니다 (상태를 자신의 스택에 푸시하고 다른 시작 매개 변수로 루프를 시작한 다음 나중에 스택에서 상태를 팝하십시오.

재귀 호출을 직접 구현하면 별도의 "푸시 상태"와 "시작으로 점프"및 "팝 상태"단계와 같이 재귀입니까? 그리고 그 대답은 : 아니요, 여전히 재귀라고하지 않으며 명시 적 스택을 사용한 반복 이라고 합니다 (기존의 용어를 사용하려는 경우).

이것은 또한 "작업"의 정의에 의존합니다. 작업이 정렬되어야하는 경우 많은 알고리즘을 사용하여 수행 할 수 있으며 많은 알고리즘은 재귀가 필요하지 않습니다. 작업이 merge sort와 같은 특정 알고리즘을 구현하는 경우 위의 모호성이 적용됩니다.

따라서 재귀와 같은 알고리즘 만있는 일반적인 작업이 있습니까? 이 질문에서 @WizardOfMenlo의 의견에서 Ackermann 함수 는 그 간단한 예입니다. 따라서 재귀의 개념은 다른 컴퓨터 프로그램 구조 (명시 적 스택을 사용한 반복)로 구현할 수 있더라도 자체적으로 존재합니다.

"재귀"를 얼마나 엄격하게 정의 하느냐에 달려 있습니다.

콜 스택 (또는 프로그램 상태를 유지하기위한 메커니즘이 사용되는)을 엄격히 요구하는 경우 항상 그렇지 않은 것으로 대체 할 수 있습니다. 실제로 자연스럽게 재귀를 많이 사용하는 언어는 테일 콜 최적화를 많이 사용하는 컴파일러를 사용하는 경향이 있으므로 작성하는 것은 재귀 적이지만 실행하는 것은 반복적입니다.

그러나 재귀 호출을하고 그 재귀 호출에 대해 재귀 호출의 결과를 사용하는 경우를 고려하십시오.

public static BigInteger Ackermann(BigInteger m, BigInteger n)
{
  if (m == 0)
    return  n+1;
  if (n == 0)
    return Ackermann(m - 1, 1);
  else
    return Ackermann(m - 1, Ackermann(m, n - 1));
}

첫 번째 재귀 호출을 반복적으로 만드는 것은 쉽습니다.

public static BigInteger Ackermann(BigInteger m, BigInteger n)
{
restart:
  if (m == 0)
    return  n+1;
  if (n == 0)
  {
    m--;
    n = 1;
    goto restart;
  }
  else
    return Ackermann(m - 1, Ackermann(m, n - 1));
}

우리는 다음 청소는 제거 할 수 있습니다 goto병동 벨로키랍토르 와 다 익스트라의 그늘 :

public static BigInteger Ackermann(BigInteger m, BigInteger n)
{
  while(m != 0)
  {
    if (n == 0)
    {
      m--;
      n = 1;
    }
    else
      return Ackermann(m - 1, Ackermann(m, n - 1));
  }
  return  n+1;
}

그러나 다른 재귀 호출을 제거하려면 일부 호출 값을 스택에 저장해야합니다.

public static BigInteger Ackermann(BigInteger m, BigInteger n)
{
  Stack<BigInteger> stack = new Stack<BigInteger>();
  stack.Push(m);
  while(stack.Count != 0)
  {
    m = stack.Pop();
    if(m == 0)
      n = n + 1;
    else if(n == 0)
    {
      stack.Push(m - 1);
      n = 1;
    }
    else
    {
      stack.Push(m - 1);
      stack.Push(m);
      --n;
    }
  }
  return n;
}

이제 소스 코드를 고려할 때 재귀 메서드를 반복 메서드로 바꿨습니다.

이것이 컴파일 된 것을 고려하여, 우리는 호출 스택을 사용하는 코드를 재귀를 구현하지 않는 코드로 변환했습니다 (그리고 그렇게 작은 코드에서도 아주 작은 값에 대한 스택 오버플로 예외를 코드로 변환합니다) 반환하는 데 엄청나게 오랜 시간이 걸립니다 [ Ackerman 함수가 스택을 넘치지 않게 하려면 어떻게해야합니까? 더 많은 최적화를 통해 실제로는 더 많은 입력을 반환 할 수 있습니다]).

재귀가 일반적으로 구현되는 방식을 고려하여 콜 스택을 사용하는 코드를 보류중인 작업을 유지하기 위해 다른 스택을 사용하는 코드로 전환했습니다. 따라서 저수준에서 고려할 때 여전히 재귀 적이라고 주장 할 수 있습니다.

그리고 그 수준에서 실제로 다른 방법은 없습니다. 따라서 해당 방법을 재귀 적이라고 생각하면 실제로 방법 없이는 할 수없는 일이 있습니다. 일반적으로 이러한 코드에는 재귀 레이블을 지정하지 않습니다. 재귀 라는 용어 는 특정 접근 방식을 다루고 이에 대해 이야기 할 수있는 방법을 제공하기 때문에 유용하며 더 이상 그 중 하나를 사용하지 않습니다.

물론,이 모든 것이 당신이 선택할 수 있다고 가정합니다. 재귀 호출을 금지하는 언어와 반복에 필요한 반복 구조가없는 언어가 있습니다.

고전적인 대답은 "아니오"이지만 "예"가 더 나은 대답이라고 생각하는 이유를 자세히 설명하겠습니다.

계속하기 전에 계산 가능성 및 복잡성 관점에서 무언가 벗어나십시오.

• 루핑 할 때 보조 스택을 가질 수 있으면 대답은 "아니오"입니다.
• 루핑 할 때 추가 데이터가 허용되지 않으면 대답은 "예"입니다.

자, 이제 한 발을 연습용 땅에 놓고 다른 발을 이론 용 땅에 두겠습니다.

호출 스택은 제어 구조 인 반면 수동 스택은 데이터 구조입니다. 제어 및 데이터는 없는 동일한 개념 있지만있어 등가 가 될 수 있다는 점에서 감소 계산 가능성이나 복잡도 측면에서 (서로를 통해 "에뮬 레이팅"또는) 서로.

이 차이는 언제 중요할까요? 실제 도구로 작업 할 때 예를 들면 다음과 같습니다.

N-way를 구현한다고 가정 해보십시오 mergesort. for각 N세그먼트를 통과 mergesort하고 개별적으로 호출 한 다음 결과를 병합 하는 루프 가있을 수 있습니다 .

이것을 OpenMP와 어떻게 병렬화 할 수 있습니까?

재귀 영역에서는 매우 간단합니다. #pragma omp parallel for루프를 1에서 N으로 바꾸면 끝납니다. 반복 영역에서는이 작업을 수행 할 수 없습니다. 스레드를 수동으로 생성하고 수행 할 작업을 알 수 있도록 적절한 데이터를 수동으로 전달해야합니다.

반면에 #pragma vector루프와 함께 작동하지만 재귀에는 전혀 쓸모가없는 다른 도구 (예 : 자동 벡터 라이저 )가 있습니다.

요컨대, 두 패러다임이 수학적으로 동등하다는 것을 증명할 수 있다고해서 실제로 동일하다는 것을 의미하지는 않습니다. 한 패러다임에서 자동화하기가 쉽지 않은 문제 (예 : 루프 병렬화)는 다른 패러다임에서 해결하기가 훨씬 더 어려울 수 있습니다.

즉 , 하나의 패러다임 도구는 다른 패러다임으로 자동 변환되지 않습니다.

결과적으로 문제를 해결하기 위해 도구가 필요한 경우 도구가 특정 종류의 접근 방식으로 만 작동하므로 결과적으로 수학적으로 문제를 입증 할 수 있다고해도 다른 방법으로 문제를 해결하지 못할 가능성이 있습니다 어느 쪽이든 해결할 수 있습니다.

이론적 추론을 제외하고 (하드웨어 또는 가상) 머신 관점에서 재귀와 루프가 어떻게 보이는지 살펴 보겠습니다. 재귀는 제어 흐름의 조합으로, 일부 코드의 실행을 시작하고 완료시 (신호 및 예외가 무시되는 경우 간단한보기로), 해당 다른 코드 (인수)에 전달되어 반환 된 데이터의 조합으로 이루어집니다. 그것은 (결과). 일반적으로 명시 적 메모리 관리는 포함되지 않지만 반환 주소, 인수, 결과 및 중간 로컬 데이터를 저장하기 위해 스택 메모리를 암시 적으로 할당 합니다.

루프는 제어 흐름과 로컬 데이터의 조합입니다. 이것을 재귀와 비교하면이 경우 데이터의 양이 고정되어 있음을 알 수 있습니다. 이 한계를 극복하는 유일한 방법은 필요할 때마다 할당 (및 해제) 할 수있는 동적 메모리 ( heap 라고도 함 )를 사용하는 것입니다.

요약:

• 재귀 사례 = 제어 흐름 + 스택 (+ 힙)
• 루프 케이스 = 제어 흐름 + 힙

제어 흐름 부분이 상당히 강력 하다고 가정하면 사용 가능한 메모리 유형 만 다릅니다. 따라서 우리는 4 가지 사례로 남습니다 (표현력은 괄호 안에 표시됨).

1. 스택, 힙 없음 : 재귀 및 동적 구조는 불가능합니다. (재귀 = 루프)
2. 스택, 힙 없음 : 재귀는 정상이며 동적 구조는 불가능합니다. (재귀> 루프)
3. 스택, 힙 없음 : 재귀가 불가능하고 동적 구조가 정상입니다. (재귀 = 루프)
4. 스택, 힙 : 재귀 및 동적 구조는 정상입니다. (재귀 = 루프)

게임 규칙이 조금 더 엄격하고 재귀 구현에서 루프를 사용할 수없는 경우 대신 다음과 같은 결과를 얻습니다.

1. 스택, 힙 없음 : 재귀 및 동적 구조는 불가능합니다. (재귀 <루프)
2. 스택, 힙 없음 : 재귀는 정상이며 동적 구조는 불가능합니다. (재귀> 루프)
3. 스택, 힙 없음 : 재귀가 불가능하고 동적 구조가 정상입니다. (재귀 <루프)
4. 스택, 힙 : 재귀 및 동적 구조는 정상입니다. (재귀 = 루프)

이전 시나리오와의 주요 차이점은 스택 메모리 부족으로 인해 루프가없는 재귀가 실행 중에 코드 줄보다 더 많은 단계를 수행 할 수 없다는 것입니다.

예. 재귀를 사용하여 달성하기 쉽지만 루프만으로는 불가능한 몇 가지 일반적인 작업이 있습니다.

• 스택 오버플로가 발생합니다.
• 완전히 혼란스러운 초보자 프로그래머.
• 실제로 O (n ^ n) 인 빠른 모양의 함수 만들기

재귀 함수와 원시 재귀 함수에는 차이가 있습니다. 프리미티브 재귀 함수는 루프를 사용하여 계산되는 함수로, 루프 실행이 시작되기 전에 각 루프의 최대 반복 횟수가 계산됩니다. (그리고 여기서 "재귀"는 재귀를 사용하는 것과 아무 관련이 없습니다).

원시 재귀 함수는 재귀 함수보다 강력하지 않습니다. 재귀의 최대 깊이를 미리 계산해야하는 재귀를 사용하는 함수를 사용하면 동일한 결과를 얻을 수 있습니다.

c ++로 프로그래밍하고 c ++ 11을 사용하는 경우 재귀를 사용하여 수행해야 할 것은 constexpr 함수입니다. 그러나이 대답 에서 설명한대로 표준은 512로 제한합니다 . 이 경우 루프를 사용할 수 없습니다.이 경우 함수는 constexpr 일 수 없지만 c ++ 14에서 변경되기 때문입니다.

• 재귀 호출이 재귀 함수의 첫 번째 또는 마지막 문인 경우 (조건 확인 제외) 루핑 구조로 변환하는 것은 매우 쉽습니다.
• 그러나 함수가 재귀 호출 전후에 다른 작업 을 수행하면 루프로 변환하는 것이 번거로울 것입니다.
• 함수에 재귀 호출 이 여러 개 있으면 루프를 사용하는 코드로 변환하는 것은 거의 불가능합니다. 데이터를 유지하려면 일부 스택이 필요합니다. 재귀에서 호출 스택 자체는 데이터 스택으로 작동합니다.

다른 질문에 동의합니다. 루프로는 할 수없는 재귀로 할 수있는 일은 없습니다.

그러나 내 의견으로는 재귀는 매우 위험 할 수 있습니다. 첫째, 코드에서 실제로 일어나는 일을 이해하기가 더 어렵습니다. 둘째, 적어도 C ++ (Java 확실하지 않음)의 경우 각 메소드 호출로 인해 메모리 누적 및 메소드 헤더 초기화가 발생하기 때문에 각 재귀 단계가 메모리에 영향을 미칩니다. 이렇게하면 스택을 날려 버릴 수 있습니다. 입력 값이 높은 피보나치 수의 재귀를 시도하십시오.