CPUが「50ビットで浮動小数点計算を行い、32ビットに正しく切り捨てられるようにする」ことをどこかで読んだと思います。これが意味するのは、前述の浮動小数点演算で計算された中間値が50ビットで計算されるため、「浮動小数点サイズへの正しい丸め」が実現できるということです。
この声明はどういう意味ですか？本当ですか？もしそうなら、なぜ彼らが 18 ビット余分に計算する必要があるのかを説明しているリソースを教えていただけますか? なぜ19か17ではないのですか？それともただの嘘ですか？
編集:- 非常に役に立ち、網羅的なこのリンクを見つけました... http://www.gamasutra.com/view/news/167402/Indepth_Intermediate_floatingpoint_precision.php
ありがとう
決して保証はできませんが、実際に遭遇したのは 50 ビットではなく 53 ビットだったと思います。彼らが 53 ビットを使用した理由は、それが浮動小数点型の次の標準サイズだからです。IEEE 754 標準では、最小タイプは合計 32 ビットです。次のサイズアップは合計 64 ビットで、仮数は 53 ビットです。そのサイズを具体的に処理するためのハードウェアが既に用意されているため、(ほとんどの場合) そのサイズで計算を実行してから、より小さいサイズに丸めるのがおそらく最も簡単です。
現代のコンピューターでは、倍精度 (1 符号ビット、11 指数ビット、52 明示仮数ビット) での計算が単精度 (1 符号ビット、8 指数ビット、23 仮数ビット) での計算と同じくらい高速であることは一般的です。したがって、float オブジェクトを読み込み、float オブジェクトを計算して格納すると、コンパイラは float 値を倍精度レジスタに読み込み、倍精度で計算し、単精度の結果を格納する場合があります。これにより、わずかなコストで高い精度が得られるというメリットがあります。結果はより頻繁に「正しく丸められる」場合があります (返される結果は、数学的に正確な結果に最も近い表現可能な値です) が、これは保証されません (まだ丸め誤差があるため、
特に SIMD プログラミングを実行する場合は、倍精度が単精度よりもコストがかかる場合があります。
一般に、高級言語では、コンパイラが浮動小数点式の評価方法を自由に決定できるため、コンパイラは、ベンダーの選択 (またはコンパイラの品質)、最適化、およびターゲット スイッチに応じて、単精度または倍精度を使用する場合があります。コンパイラに渡されたコード、コンパイルされるコードのその他の側面 (たとえば、計算を行うためのマシン レジスタの可用性)、および実用的な目的ではランダムである可能性があるその他の要因。したがって、これは信頼できる動作ではありません。
聞いたことのもう 1 つの意味は、sinf や logf などの単精度関数のライブラリ ルーチンが倍精度で記述されている可能性があるため、完全に記述しなければならない場合よりも目的の結果を簡単に取得できるということです。単精度で。それはよくあることです。ただし、このようなライブラリ ルーチンは、計算中に発生する可能性のあるエラーを分析する専門家によって慎重に作成されているため、ビット数が多いほど良い結果が得られると単純に仮定することはできません。
これはイプシロン値に関係しています。たとえば、古典的な 0.1 + 0.2 問題を取り上げます: http://0.30000000000000004.com/
ほとんどの言語では、0.1 + 0.2 != 0.3 です。これは、0.1 と 0.2 が基数 10 で 10 進数を終了しているのに対して、基数 2 では、0.1 は 0.0001100110011... のように見え、0.2 は 0.001100110011... のように見えるためです。これは、0.333333333... + 0.33333333.... が精度を上げていくと 2/3 に近づくのと同様です。
なぜ 18 の余分なビットと 19 の余分なビットがあるのかという点については、より複雑な議論になります。詳細については、 http://en.wikipedia.org/wiki/Machine_epsilonを参照してください。