再帰-「分割して征服する」か「コードを再利用する」か

再帰 -誰もが知っているように-これらの問題の1つです-あなたの頭を包むことは、プログラミングの旅で「マイルストーン」を達成するような気がします。

しかし、実際の問題で実際に使用する場合は、再帰のメカニズムを知るだけでは十分ではありません。再帰が最も適切な解決策である問題の性質も理解する必要があります。

私の質問はこれです...

• 再帰の解決を要求する「問題パターン」とは何ですか
• 再帰は「分割統治」戦略の形式、または「コード再利用」の形式です-または、それ自体が設計パターンです
• 再帰が即座の解決策として頭に浮かぶ現実世界の問題の例を教えてください

-更新-

多くの答えは、「本当の問題」をツリー探索や階乗などと呼んでいます。「本当の本当の問題」を好むでしょう。例を挙げましょう...

テキストの大規模なチャック（のリンクリストとして約30 MBのテキストstructs）があり、全文検索のためにそのインデックスを作成する必要がありました。インデックス全体をメモリに保持し、10分ごとにテキストのインデックスを再作成する必要がありました。

10分ごとに、テキスト全体（2つのリンクリスト、1行ずつ）と新しく生成されたテキストチャンクを比較し、変更された行を確認し、その行のみを再インデックスしますテキスト全体のインデックスを再作成する必要がなくなりました。覚えておいてください-2つの30 MBのリンクリスト間の差分ポイントを見つける必要がありました。

私の同僚の一人は、HEAVY再帰を使用して行を比較する素晴らしいプログラムを思い付きました-そして、チャックが配列内で異なる位置を収集します-はいやった

要点は、再帰を頻繁に使用することで、この問題をスマートに解決できることをどのように確認できるのでしょうか？

• 再帰の解決を要求する「問題パターン」とは何ですか

再帰を使用するための問題パターンのようなものがあるとは言いません。再帰を使用して実装できるすべての関数は、スタックをプッシュおよびポップすることにより、繰り返し実装することもできます。

それは表現の問題であり、パフォーマンスの問題でもあります。多くの場合、反復アルゴリズムはパフォーマンスが向上しており、最適化が容易です。ただし、再帰アルゴリズムはより明確な式の恩恵を受けるため、多くの場合、読みやすく、理解しやすく、実装しやすいです。

無限のリストなど、再帰なしでは表現できないものもあります。いわゆる関数型言語は、自然な表現方法であるため、再帰に大きく依存しています。「再帰プログラミングとは、関数型プログラミングを正しく行うこと」です。

• 再帰は「分割統治」戦略の形式、または「コード再利用」の形式です-または、それ自体が設計パターンです

デザインパターンとは呼びません。それは表現の問題です。再帰式は、単により強力で表現力豊かであるため、より優れた、よりクリーンなコードになる場合があります。

• 再帰が即座の解決策として頭に浮かぶ現実世界の問題の例を教えてください

ツリーをトラバースする必要があるものはすべて、再帰アルゴリズムによって適切に表現されます。

再帰は「分割統治」戦略の形式、または「コード再利用」の形式です-または、それ自体が設計パターンです

どちらでもない。分割統治では再帰を使用します。しかし、再帰は必ずしも問題を2つ（またはそれ以上）の部分に分割し、それぞれを対称的に解決することを意味するため、分割と分割は必ずしも必要ではありません。再帰では、これを行いません。

コードの再利用は完全に無関係であり、設計パターンははるかに高いレベルで機能します。たとえば、分割と征服（再帰よりも高レベルのパターン）でさえ、デザインパターンとは見なされません。むしろ、アルゴリズムパターンです。

再帰が即座の解決策として頭に浮かぶ現実世界の問題の例を教えてください

ツリートラバーサル。または、より一般的には、グラフトラバーサル。これには、フォルダー構造の走査が含まれます。

もちろん、分割統治法または動的プログラミングを使用するものはすべて、再帰の観点で自然に表現されているためです。

what are the "problem patterns" that call for the solution of recursion

フラクタルの自己相似性から派生した、自己平等または自己同一性（またはそれが呼ばれている）は、再帰の典型的な問題パターンであると言えます。つまり、問題は、メインの問題とまったく同じ構造を持つサブ問題に分割できます。

前述のツリートラバーサルでは、各サブツリーはメインツリーと同様にそれ自体が完全なツリーであり、メインツリーは別のツリー内のサブツリーにすることができます。

それで、あなたの同僚はあなたのインデックス作成問題の自己平等性を発見したと思います。または、彼は反対に回り、問題を自己同等の表現に変えました。

命令型ループを関数に変換しようとすると、再帰は簡単に理解できます。とにかく、すべての質問に答えてみましょう。

再帰の解決を要求する「問題パターン」とは何ですか

ツリーのような構造またはアルゴリズムがある場合は、再帰が必要です。命令コードがスタックを処理する場合、再帰が必要になります。アルゴリズムの特定のステップが前のステップに依存している場合（ループを考える）、再帰が必要です。ここで必要なのは、使用できるように解釈されることです。

再帰は「分割統治」戦略の形式、または「コード再利用」の形式です-または、それ自体が設計パターンです

なし。分割統治では再帰を使用しますが、スタックで実装できます。コードの再利用とは、別のものを指します。設計パターンは、単純な再帰よりも複雑です。

再帰が即座の解決策として頭に浮かぶ現実世界の問題の例を教えてください

構文解析およびツリー構造を扱うすべて。暗黙のツリー構造ですら。

簡単にするためにそれを単純化する方法があれば、それが再帰が機能する手がかりになる可能性があります。それぞれ、ソートのマージやバイナリ検索などの再帰的なソリューションが存在する場合、ソートと検索の例を使用できます。

心に留めておくべきことは、階乗のような再帰でいくつかの問題をどのようにうまく解決できないかです。

再帰を使用する実際の例として、本の棚から本を検索することは、再帰的に非常に簡単に行うことができます。私は本を​​見て、それが私が望むものでないならば、私は次のものに移ります。本を見つけるか、行の終わりに到達すると停止します。本を確認し、次の本に移動するループは、再帰的に実行できます。おそらくこれは実例ではあまりにも現実的です。

再帰の解決を要求する「問題パターン」とは何ですか

非常に一般的な言葉で言えば、f（x）= f（g（x））の問題を解決するときに再帰が必要です。無限再帰で大丈夫でない限り、g（x）はxに評価されるべきではありません。

再帰は「分割統治」戦略の形式、または「コード再利用」の形式です-または、それ自体が設計パターンです

上記のどれでもない。これは、入力のバリエーションに基づいて、同じことを繰り返し行う方法にすぎません。その概念は、設計パターン、コードの再利用、さらにはコンピューターよりもはるかに長いものでした。

再帰が即座の解決策として頭に浮かぶ現実世界の問題の例を教えてください

階乗、フィボナッチ数列、ツリートラバーサル、その他の多くの問題は、再利用で解決できます。関数自体を呼び出すという意味での再帰は、必ずしもこれらの種類のものを実装する最良の方法ではありません。同じ効果を達成する他の方法（スタックとループなど）があります。

再帰アルゴリズムを作成するとき、通常、問題の再帰定義をコードに変換します。そうすれば、実行方法を知る必要すらありません。

それが関数型プログラミングで起こることです。実際、どのようにではなく何（定義）を指定します。つまり、ベースを定義してから、サブ問題の用語で問題を定義します。

たとえば、Factorialアルゴリズムを考えます

• ベースを定義します：Factorial（1）= 1;
• 階乗nの定義：階乗（n）= n *階乗（n-1）;

次に、問題が発生した場合、再帰的に定義できるかどうか、再帰的に定義できる場合はほとんど解決できていると考えてください。

ただし、再帰関数は再帰定義であってはなりません。ベースを定義し、メインの問題の解決策をサブ問題の解決策（定義）に関連付ける（定義する）ことができます。ただし、この関係には手順が必要な場合があります。

例としてはMergeSort、merge配列全体を並べ替える定義またはソリューションをサブ配列の並べ替えに関連付けるための必須の手順があります。