再帰アルゴリズムを持つ本当の目的は何なのかを考えています。再帰アルゴリズムがコンパクトで、ある意味で理解しやすいことは誰もが知っています。ただし、再帰の最大の欠点は、再帰アルゴリズムが実行中に大量のシステム リソースを必要とすることです。これは、再帰アルゴリズムが非常に「単純なデータ」でのみ実行されるべきであるという結果につながります（正しい言葉を使用しているかどうかはわかりません）。
例: 再帰アルゴリズムを使用して、特定の行列の格子パスの数を計算するアルゴリズムを作成しました。このアルゴリズムは小さな行列サイズではうまく機能しますが、行列サイズが 20 を超えると、コンピューターがタスクを完了するまでに時間がかかります。したがって、通常のアプローチを使用してアルゴリズムを書き直す必要があります。
再帰アルゴリズムの目的を説明してくれる人はいますか? システムリソースの使用にはあまり効果的ではなく、通常のアプローチで完全に書き直すことができるためです（再帰アルゴリズムを書き直すのが難しい場合があることはわかっています）。
実際、この場合、ある人のゴミは別の人の宝物です。しかし、バックアップするために、「膨大な量のシステムリソース」というあなたの主張を考えてみましょう:キャッシングとパイプラインの問題を無視して、再帰アルゴリズムが「目に見えない」方法で使用するリソースは、再帰呼び出しを行うためのシステムスタックスペースです:現在の命令ポインタがプッシュされます再帰関数へのすべてのパラメーターと同様に、スタック上で。さらに、再帰プロシージャにローカルな変数がスタック上に作成されますが、これはどの関数にも当てはまりますが、ローカル変数によって消費されるメモリは再帰の深さの倍になります。とはいえ、これは必ずしも「巨大」というわけではありません。
再帰アプローチの利点は（あなたが言及したものに加えて）...それを待って...システムスタックを別のデータ構造として使用できるという事実です。二分木を探索するための再帰的アルゴリズムを考えてみましょう:ノードを渡すことによってパラメータを再帰関数に渡すと、非再帰的アプローチで明示的に維持する必要があるデータ構造 (つまり、スタック) を実際に維持していますが、再帰関数では実際に宣言する必要がないという違いがあります。スタックを明示的に維持します。したがって、リソースの唯一の追加の「無駄」は、スタックフレームで必要なものに加えて、スタック上の命令ポインターのサイズ * 再帰の深さです。ノード ポインターを格納するための明示的なデータ構造を宣言する必要がないため、より単純化されたわかりやすいアルゴリズムの場合、これはわずかな代償です。
多くの再帰関数では、再帰アプローチは実際の再帰を伴わないことに注意してください: 再帰呼び出しが再帰関数の最後の呼び出しとして行われ、再帰呼び出しの結果が呼び出し関数自体によって返される場合、末尾呼び出し最適化(多くのコンパイラで利用可能) は、非再帰的なコードを生成します。