再帰はそれ自体が機能ですか？

...それとも単なる練習ですか？

私は教授との議論のためにこれを求めています：クラスで再帰をカバーしなかったという理由で関数を再帰的に呼び出すことの信用を失いました、そして私の議論は学習returnと方法によって暗黙的にそれを学んだということです。

誰かが明確な答えを持っていると思うので、私はここで尋ねています。

たとえば、次の2つの方法の違いは何ですか。

public static void a() {
    return a();
    }

public static void b() {
    return a();
    }

「a永久に継続する」（実際のプログラムでは、無効な入力が提供されたときにユーザーに再度プロンプトを表示するために正しく使用されます）以外に、との間に基本的な違いはaありbますか？最適化されていないコンパイラにとって、それらはどのように異なる方法で処理されますか？

最終的にはそれがに学習することでかどうかに降りてくるreturn a()からb、我々はまたに学んだそのことreturn a()からa。しましたか？

特定の質問に答えるには：いいえ、言語を学習する観点からすると、再帰は機能ではありません。教授が本当に教えていない「機能」を使用するためにあなたのマークを本当にドッキングした場合、それは間違っていました。

行間を読むと、1つの可能性として、再帰を使用することで、彼のコースの学習結果となるはずの機能の使用を回避できた可能性があります。たとえば、反復をまったく使用しなかった場合や、およびのfor両方forを使用する代わりにループのみを使用した場合などwhileです。課題は特定のことを実行する能力をテストすることを目的としていることが一般的であり、それらを実行しない場合、教授はその機能のために取っておいたマークを付与することはできません。ただし、それが本当に失点の原因だった場合、教授はこれを自分自身の学習体験としてとらえる必要があります。特定の学習成果を示すことが課題の基準の1つである場合は、生徒に明確に説明する必要があります。 。

そうは言っても、ここでの再帰よりも反復の方が良い選択であるという他のコメントや回答のほとんどには同意します。いくつかの理由があり、他の人々がある程度それらに触れたが、彼らが彼らの背後にある考えを完全に説明したとは思えない。

スタックオーバーフロー

より明白なのは、スタックオーバーフローエラーが発生するリスクがあることです。実際には、ユーザーが実際にスタックオーバーフローをトリガーするために何度も誤った入力を行わなければならないため、作成したメソッドが実際に1につながる可能性はほとんどありません。

ただし、注意すべき点の1つは、メソッド自体だけでなく、呼び出しチェーン内の上位または下位の他のメソッドがスタックに存在することです。このため、利用可能なスタックスペースをさりげなく取得することは、どの方法でもかなり失礼です。他のコードが不必要に多くのコードを使い果たしてしまうリスクがあるため、コードを作成するときはいつでも、空きスタック領域について常に心配する必要はありません。

これは、抽象化と呼ばれるソフトウェア設計のより一般的な原則の一部です。本質的に、を呼び出すときDoThing()、気にする必要があるのは、事が行われたことだけです。実装方法の詳細について心配する必要はありません。しかし、スタックの貪欲な使用はこの原則を破ります。コードのすべてのビットは、コールチェーンの他の場所のコードによって残されたと想定できるスタックの量を心配する必要があるためです。

読みやすさ

他の理由は読みやすさです。コードが目指すべき理想は、人間が読める形式のドキュメントになることです。この場合、各行はコードが何をしているかを簡単に説明します。次の2つの方法を使用します。

private int getInput() {
    int input;
    do {
        input = promptForInput();
    } while (!inputIsValid(input))
    return input;
}

対

private int getInput() {
    int input = promptForInput();
    if(inputIsValid(input)) {
        return input;
    }
    return getInput();
}

はい、どちらも機能し、どちらも非常に理解しやすいです。しかし、2つのアプローチはどのようにして英語で記述できるでしょうか。私はそれが次のようなものになると思います：

入力が有効になるまで入力を求め、それを返す

対

入力を要求し、入力が有効な場合はそれを返し、それ以外の場合は入力を取得してその結果を返します

おそらく、後者については少し不格好な表現を考えることもできますが、最初の表現は、実際に何をしようとしているのか、概念的にはより正確な説明になるといつも思うでしょう。これは、再帰が常に読みにくくなると言っているのではありません。ツリートラバーサルのように、それが輝く状況では、再帰と別のアプローチの間で同じ種類の並列分析を行うことができ、再帰が行ごとに、より明確に自己記述的なコードを与えることがほぼ確実にわかります。

単独では、これらはどちらも小さな点です。スタックオーバーフローが実際に発生する可能性はほとんどなく、可読性の向上はわずかです。しかし、どのプログラムもこれらの小さな決定の多くのコレクションになるので、孤立していてもそれほど重要ではない場合でも、正しい決定の背後にある原則を学ぶことが重要です。

メタ質問ではなく文字通りの質問に答えるために：再帰は、すべてのコンパイラーや言語が必ずしも許可するわけではないという意味での機能です。実際には、すべての（通常の）現代のコンパイラー、そして確かにすべてのJavaコンパイラーに期待されています！-しかし、それは普遍的に真実ではありません。

再帰がサポートされない理由の不自然な例として、静的な場所に関数の戻りアドレスを格納するコンパイラを検討してください。これは、たとえば、スタックを持たないマイクロプロセッサーのコンパイラーの場合に当てはまる可能性があります。

このようなコンパイラの場合、このような関数を呼び出すと

a();

それはとして実装されています

move the address of label 1 to variable return_from_a
jump to label function_a
label 1

そしてa（）の定義、

function a()
{
   var1 = 5;
   return;
}

として実装されています

label function_a
move 5 to variable var1
jump to the address stored in variable return_from_a

うまくいけば、そのa()ようなコンパイラで再帰的に呼び出そうとするときの問題は明白です。戻りアドレスが上書きされたため、コンパイラーは外部呼び出しから戻る方法を認識しなくなりました。

私が実際に使用したコンパイラ（70年代後半または80年代前半）では、再帰はサポートされていません。問題はそれよりも少し微妙でした。戻りアドレスは、最新のコンパイラと同じようにスタックに格納されますが、ローカル変数はありませんでした。ない （理論的には、これは非静的ローカル変数のない関数で再帰が可能だったことを意味しますが、コンパイラーが明示的にそれをサポートしたかどうか覚えていません。何らかの理由で暗黙のローカル変数が必要だった可能性があります。）

今後の展望として、特殊なシナリオ（多並列システムなど）を想像できます。この場合、すべてのスレッドにスタックを提供する必要がないことが有利であり、再帰が許可されるのは、コンパイラーがそれをループにリファクタリングできる場合のみです。（もちろん、上で説明したプリミティブコンパイラは、コードのリファクタリングなどの複雑なタスクを実行できませんでした。）

先生はあなたが勉強したかどうか知りたがっています。どうやらあなたは彼があなたに教えた方法（良い方法 ;反復）で問題を解決しなかったので、あなたは解決しなかったと見なします。私はすべてクリエイティブソリューションですが、この場合、別の理由で先生に同意する必要があります。
ユーザーが無効な入力を何度も（つまり、Enterキーを押し続けることで）提供すると、スタックオーバーフロー例外が発生し、ソリューションがクラッシュします。さらに、反復ソリューションはより効率的で維持が容易です。それがあなたの先生があなたに与えるべきだった理由だと思います。

「クラスで再帰をカバーしなかった」のでポイントを差し引くのはひどいです。関数Bを呼び出す関数Aを呼び出す方法を学び、関数Cを呼び出す関数Bに戻り、Bに戻り、Aに戻り、呼び出し元に戻ります。教師は、これらが異なる関数である必要があることを明示していません（これはたとえば、古いFORTRANバージョンの場合）、A、B、Cがすべて同じ関数である可能性がある理由はありません。

一方、実際のコードを見て、特定のケースで再帰を使用することが本当に正しいことかどうかを判断する必要があります。詳細はあまりありませんが、間違っているようです。

あなたが尋ねた特定の質問に関して見るべき多くの視点がありますが、私が言えることは、言語を学ぶという観点から、再帰はそれ自体の機能ではないということです。教授がまだ教えていない「機能」を使用するためにあなたのマークを本当にドッキングした場合、それは間違っていましたが、私が言ったように、ポイントを差し引くときに教授が実際に正しいとする他の見方があります。

私があなたの質問から推測できることから、再帰関数を使用して入力が失敗した場合に入力を求めることは、すべての再帰関数の呼び出しがスタックにプッシュされるため、良い方法ではありません。この再帰はユーザー入力によって駆動されるため、無限再帰関数を使用してStackOverflowを生成することが可能です。

質問であなたが言及した2つの例には、それらが何をするかという意味で違いはありません（ただし、他の点では異なります）。どちらの場合も、戻りアドレスとすべてのメソッド情報がスタックにロードされています。再帰の場合、戻りアドレスはメソッド呼び出しの直後の行です（もちろん、コード自体に表示されるのではなく、コンパイラが作成したコードに表示されます）。Java、C、Pythonでは、再帰は新しいスタックフレームの割り当てを必要とするため、反復（一般的に）に比べてかなり高価です。言うまでもなく、入力が何度も有効でない場合は、スタックオーバーフロー例外が発生する可能性があります。

再帰はそれ自体の主題であると考えられており、プログラミングの経験がない人が再帰を考える可能性は低いため、教授はポイントを差し引いたと思います。（もちろん、そうではないという意味ではありませんが、そうではありません）。

私見、教授はあなたにポイントを差し引いて正しいと思います。検証部分を別のメソッドに簡単に変換して、次のように使用できます。

public bool foo() 
{
  validInput = GetInput();
  while(!validInput)
  {
    MessageBox.Show("Wrong Input, please try again!");
    validInput = GetInput();
  }
  return hasWon(x, y, piece);
}

あなたがしたことが実際にその方法で解決できるなら、あなたがしたことは悪い習慣であり、避けるべきです。

教授はまだ教えていないかもしれませんが、再帰の利点と欠点を学ぶ準備ができているようです。

再帰の主な利点は、多くの場合、再帰的アルゴリズムの方がはるかに簡単かつ迅速に記述できることです。

再帰の各レベルでは、スタックに追加のスタックフレームを追加する必要があるため、再帰の主な欠点は、再帰アルゴリズムがスタックオーバーフローを引き起こす可能性があることです。

プロダクションコードでは、スケーリングによってプログラマーの単体テストよりもはるかに多くのレベルの再帰が発生する可能性がありますが、通常はデメリットよりもデメリットが優先され、再帰的なコードは多くの場合、実用的に回避されます。

特定の質問に関して、再帰は機能です、私はイエスと言う傾向がありますが、質問を再解釈した後。再帰を可能にする言語とコンパイラの一般的な設計上の選択肢があり、再帰をまったく許可しないチューリング完全言語が存在します。言い換えると、再帰は、言語/コンパイラの設計における特定の選択によって可能になる機能です。

• ファーストクラスの関数をサポートすることで、最小限の前提の下で再帰が可能になります。例については、Unlambdaでのループの記述を参照してください。または、自己参照、ループ、または割り当てを含まない、この鈍いPython式：

  >>> map((lambda x: lambda f: x(lambda g: f(lambda v: g(g)(v))))(
  ...   lambda c: c(c))(lambda R: lambda n: 1 if n < 2 else n * R(n - 1)),
  ...   xrange(10))
  [1, 1, 2, 6, 24, 120, 720, 5040, 40320, 362880]
  

• 遅延バインディングを使用する言語またはコンパイラ、または前方宣言を定義する言語/コンパイラは、再帰を可能にします。たとえば、Pythonでは以下のコードを使用できますが、これは設計上の選択（遅延バインディング）であり、チューリング完全システムの要件ではありません。相互に再帰的な関数は、多くの場合、前方宣言のサポートに依存しています。

  factorial = lambda n: 1 if n < 2 else n * factorial(n-1)
  

• 再帰的に定義された型を許可する静的型付け言語は、再帰の有効化に貢献します。GoのY Combinatorのこの実装を参照してください。再帰的に定義された型がなくても、Goで再帰を使用することは可能ですが、Yコンビネーターは特に不可能だと思います。

私があなたの質問から推測できることから、入力が失敗した場合に再帰関数を使用して入力を求めることはお勧めできません。どうして？

すべての再帰関数呼び出しがスタックにプッシュされるからです。この再帰はユーザー入力によって駆動されるため、無限の再帰関数を持つことが可能で、結果としてStackOverflowが生成されます:-p

これを行うための非再帰的ループを持つことは、進むべき道です。

再帰は、プログラミングの概念、機能（反復など）、および実践です。リンクからわかるように、このテーマに特化した研究の大きな領域があります。おそらく、これらのポイントを理解するためにトピックの深いところに行く必要はありません。

機能としての再帰

簡単に言えば、Javaは暗黙的にそれをサポートします。これは、メソッド（基本的には特別な関数）がそれ自体と、それが属するクラスを構成する他のメソッドの「知識」を持つことができるためです。これが当てはまらない言語について考えてみましょう。そのメソッドの本体を記述するaことはできますが、その中に呼び出しを含めることはできませんa。唯一の解決策は、同じ結果を得るために反復を使用することです。そのような言語では、自分の存在を（特定の構文トークンを使用して）認識している関数と認識していない関数を区別する必要があります。実際には、言語のグループ全体がその区別を行い（LispおよびML参照たとえばファミリを）。興味深いことに、Perlは匿名関数（いわゆるlambdas）自分自身を再帰的に呼び出す（ここでも、専用の構文を使用）。

再帰なし？

再帰の可能性さえサポートしていない言語の場合、固定小数点コンビネーターの形で別の解決策がしばしばありますが、それでも、いわゆるファーストクラスオブジェクト（つまり、言語自体の中で操作される）。

慣習としての再帰

その機能を言語で使用できるということは、それが慣用的であることを必ずしも意味しません。Java 8ではラムダ式が含まれているため、プログラミングに関数型アプローチを採用する方が簡単になる場合があります。ただし、実際的な考慮事項があります。

• 構文はまだ再帰的にフレンドリーではありません
• コンパイラはその慣行を検出して最適化できない場合があります

肝心なこと

幸運なことに（またはより正確には、使いやすくするために）、Javaはデフォルトでメソッドに自分自身を認識させ、再帰をサポートするため、これは実際には問題ではありませんが、理論的な問題であり、私はあなたの教師は具体的にそれに取り組みたかったのです。さらに、最近の言語の進化に照らして、将来的に重要なものになるかもしれません。