短い答え：
pow(x, n)toがn自然数であるという特殊化は、多くの場合、時間パフォーマンスに役立ちます。しかし、標準ライブラリのジェネリックはこの目的のためにpow()（驚くほど！）かなりうまく機能します。標準Cライブラリにできる限り少ないものを含めることは絶対に重要です。一方、C ++標準ライブラリやSTLに含まれることを完全に止めるものではありません。これは、組み込みプラットフォームでの使用を誰も計画していないことを確信しています。
さて、長い答えのために。
pow(x, n)多くの場合n、自然数に特化することで、はるかに高速にすることができます。私はこの関数の独自の実装を、作成するほとんどすべてのプログラムに使用する必要がありました（ただし、Cで多くの数学プログラムを作成しています）。特殊な操作はO(log(n))時間内に実行できますが、nサイズが小さい場合は、単純な線形バージョンの方が高速です。両方の実装は次のとおりです。
// Computes x^n, where n is a natural number.
double pown(double x, unsigned n)
{
double y = 1;
// n = 2*d + r. x^n = (x^2)^d * x^r.
unsigned d = n >> 1;
unsigned r = n & 1;
double x_2_d = d == 0? 1 : pown(x*x, d);
double x_r = r == 0? 1 : x;
return x_2_d*x_r;
}
// The linear implementation.
double pown_l(double x, unsigned n)
{
double y = 1;
for (unsigned i = 0; i < n; i++)
y *= x;
return y;
}
（x結果はpow(double x, unsigned n)doubleに収まるため、戻り値はdoubleのままにしpow(double, double)ます。）
（はい、pown再帰的であるが、最大スタックサイズがほぼ等しいので、スタックを破壊することは絶対に不可能であり、log_2(n)かつn整数である場合は、nあなたの約64の最大スタックサイズが得られる64ビットの整数であるなしのハードウェアは、このような極端を有しますメモリの制限。ただし、ハードウェアスタックを備えた一部の危険なPICを除き、3から8の関数呼び出しの深さのみです。
パフォーマンスに関してpow(double, double)は、園芸品種の能力に驚くでしょう。5歳のIBM Thinkpadで1億回のイテレーションをテストしました。xイテレーション数nは10で、このシナリオでpown_lは勝ちました。glibc pow()は12.0ユーザー秒pownかかり、7.4ユーザー秒pown_lかかり、6.5ユーザー秒しかかかりませんでした。ですから、それほど驚くことではありません。私たちは多かれ少なかれこれを期待していた。
次に、x定数（2.5に設定）にしてn、0から19まで1億回ループしました。今回は、予想外に、glibc powが勝利し、地滑りが発生しました。2.0ユーザー秒しかかかりませんでした。私pownは9.6秒、pown_l12.2秒かかりました。ここで何が起こったのですか？別のテストを行って調べました。
私はx100万に等しいだけで上記と同じことをしました。今回pownは9.6秒で勝ちました。pown_l12.2秒かかり、glibc捕虜は16.3秒かかりました。さて、それは明らかです！glibc は、低いpow場合xは3つよりもパフォーマンスxが高くなりますが、高い場合は最悪です。x高いpown_lときnは、低いときに最高のパフォーマンスを発揮し、高いときは最高のpownパフォーマンスを発揮しますx。
したがって、3つの異なるアルゴリズムがあり、それぞれが適切な状況下で他のアルゴリズムよりも優れたパフォーマンスを発揮できます。つまり、最終的にどちらを使用するかは、をどのように使用するかによって異なりますがpow、適切なバージョンを使用することは価値があり、すべてのバージョンを使用することは便利です。実際、次のような関数を使用してアルゴリズムの選択を自動化することもできます。
double pown_auto(double x, unsigned n, double x_expected, unsigned n_expected) {
if (x_expected < x_threshold)
return pow(x, n);
if (n_expected < n_threshold)
return pown_l(x, n);
return pown(x, n);
}
限りx_expectedとn_expectedされている可能性が他のいくつかの注意点とともに、コンパイル時に決めた定数、その塩は、自動的に全体が削除されます最適化コンパイラの価値pown_auto関数呼び出しをし、3つのアルゴリズムの適切な選択と交換してください。（ここで、実際にこれを使用しようとする場合、上で書いたものをコンパイルしようとはしなかったので、おそらく少しいじる必要があります。;）
一方、glibc pow は機能し、glibcはすでに十分な大きさです。C標準は、さまざまな組み込みデバイスを含め、移植可能であることが想定されています（実際、どこにでもいる組み込み開発者は、glibcがすでに大きすぎることに同意しています）。すべての単純な数学関数について、すべてを含める必要がある場合は移植できません。役に立つかもしれない代替アルゴリズム。したがって、それがC標準にない理由です。
脚注：パフォーマンステストでは、-s -O2私のシステム（glilinux）でglibcをコンパイルするために使用された可能性があるものと同等かそれよりも劣ると思われる比較的寛大な最適化フラグ（）を関数に与えたので、結果はおそらく公正。より厳密なテストを行うには、自分でglibcをコンパイルする必要がありますが、実際にはそうする気はありません。以前はGentooを使用していたので、タスクが自動化されている場合でも、どのくらい時間がかかったか覚えています。結果は、私にとって十分に決定的（またはむしろ決定的ではない）です。もちろん、これを自分で行うこともできます。
ボーナスラウンド：正確な整数出力が必要な場合、pow(x, n)すべての整数への特殊化が役立ちます。p ^ N要素を持つN次元配列にメモリを割り当てることを検討してください。p ^ Nを1つでもオフにすると、segfaultがランダムに発生する可能性があります。