pow具体的には、 call( #include <math.h>) でコーナー ケースをテストしていますpow(-1, Inf)。
私のデスクトップ (Ubuntu) では、1.0 という結果が得られました。これは、2008 年の IEEE 浮動小数点仕様に準拠しています。
Android Gingerbread カーネルを実行しているときに同じテストを実行すると、NaN が返されます。
私が周りを見回したところpow、さまざまなプラットフォームの標準ライブラリに実際に多くの実装があり、pow(-1, Inf)それらが異なる結果を生成するようにコーディングされていることがわかりました。
問題は、どちらが正しいと見なされるべきかということです。アイデアや考えはありますか？
間違ったフォーラムに投稿している場合はお詫び申し上げます。Android 開発者向けリソースのリンクをたどり、ここにたどり着きました。
この点について、C 標準は完全に明確です (§F.9.4.4)。「アイデアや考え」の余地はありません。
pow(−1, ±∞) は 1 を返します。
附属書 F は、実装__STDC_IEC_559__で が定義されている場合にのみ適用されますが、1.0 が正しい答えであることは間違いありません。
これは、NDK に漏れ出した Java 主義ではないかと思います。(Java は であると定義pow(-1,infinity)しますNaN):
最初の引数の絶対値が 1 に等しく、2 番目の引数が無限大の場合、結果は NaN になります。
編集:
マッテオはこれが「意味をなさない」と反対しているので、委員会がこの選択をした理由についていくつかの説明を提供します. lim_{n->inf} (-1)^n は実数には存在しませんが、浮動小数点数は実数ではないことを覚えておく必要があり、実際、十分に大きな浮動小数点数はyすべてpow(-1,y)です+1。これは、十分に大きな浮動小数点数はすべて偶数の整数であるためです。この観点からすると、 を と定義することは非常に合理的pow(-1,infinity)で+1あり、これにより、実際には一部の浮動小数点計算でより有用な動作が得られることがわかります。
C 委員会と IEEE-754 委員会の両方に関与している驚くべき数の非常に有能な数学者 (および非常に熟練したプログラマーとコンパイラーの作成者) がいて、彼らはこれらの決定を軽率に行いません。すべての標準にはバグがありますが、これはバグの 1 つではありません。