問題タブ [floating-point-precision]

数百桁の長さ (pi - 3 の最初の 100 桁など) の float 値があり、それを操作する方法が必要です。多数の小数を持ち、組み込みライブラリで多くの精度を維持する float を格納して操作する方法はありますか? C ++にPythonのDecimalモジュールのようなものはありますか?

私のアルゴリズムは、単精度浮動小数点演算のイプシロンを計算しています。1.1921e-007前後のはずです。コードは次のとおりです。

デバッグモードでは、次の妥当な出力（省略形）が得られます。

ただし、リリースモードに切り替えると（最適化の有無に関係なく！）、コードは次の結果をもたらします。

これは倍精度の値に対応します。したがって、いくつかの最適化により、計算がdouble値で実行されると思います。もちろん、この場合の結果は間違っています！

また、これは、プロジェクトオプションでX86リリースをターゲットにしている場合にのみ発生します。繰り返しますが、最適化のオン/オフは重要ではありません。私は64ビットWIN7、VS 2010 Ultimateを使用しており、.NET4.0をターゲットにしています。

何がその振る舞いを引き起こす可能性がありますか？いくつかのWOWの問題？信頼できる方法でそれを回避する方法は？単精度計算の代わりに倍精度を使用するコードをCLRが生成しないようにするにはどうすればよいですか？

注：ここで問題が発生しなくても、プラットフォームターゲットとして「AnyCPU」または「X64」に切り替えることはできません。ただし、32/64ビット用のさまざまなバージョンのネイティブライブラリがいくつかあります。したがって、ターゲットは具体的でなければなりません。

単精度と倍精度の間で変換できる方法を探しています。1 つの例は、2 つの整数を除算して浮動小数点数の結果を取得することです。そんなことがあるものか？

Python の float (および精度) の基になるデータ構造に関する質問があります。

b と c の値はマシンに依存しているようです。これらはターゲット値に最も近い数値ですが、まったく同じ数値ではありません。私は、'Print' で '正しい' 数値が得られるように監督されていました。ある人は、Python が私たちに真実を伝えることを選んだのに対し、print は '嘘をついている' ためだと言いました。

私の質問は次のとおり

です。 1.嘘をつく方法は？たとえば、関数では 2 つの値を取り、それらが同じ場合に戻ります。上記のbとcのように？それを行うための明確に定義されたアルゴリズムはありますか？浮動小数点計算が含まれている場合、すべての言語 (C/C++) でこの種の問題が発生すると言われましたが、どのようにこれを「解決」しますか?

2. 最も近い数値を格納する代わりに、実際の数値を格納できないのはなぜですか? それは制限ですか、それとも効率のための取引ですか？

どうもありがとうジョン

そのため、浮動小数点数の有効桁数と精度の相対的な損失との関係を頭でラップしようとしましたが、それを理解できないようです。私は以前、次のことを行うように言った記事を読んでいました。

1. float を 2147483647 の値に設定します。その値が実際には 2147483648 であることがわかります。
2. float から 64 を引くと、演算が正しいことがわかります。
3. float から 65 を引くと、実際には 2147483520 になっていることがわかります。つまり、実際には 128 を引いたということです。

では、有効桁数が 10 桁であるのに、なぜ 128 になるのでしょうか。float がどのように格納されるか (符号は 1 ビット、指数は 8 ビット、仮数は 23 ビット) を理解し、すべての整数が float データ構造で正確なホームを自動的に見つけると仮定すると、どのように精度が失われるかを理解していますが、私は知りません。 128がどこから来たのか理解できません。私の直感は、私が正しい方向に進んでいることを示していますが、誰かが私のためにこれを解決できることを願っています.

私は当初、可能な float 間の距離は 2 ^ (n-1) (n は有効桁数) であると考えていましたが、そうではありませんでした。

ありがとうございました！

bを_int64変数と仮定します。sqrt((long double)a)*sqrt((long double)b)高精度の80ビット浮動小数点で計算する必要があります。

例。(__int64)(sqrt((long double)a)*sqrt((long double)a) + 0.5) != a多くの場合、そうあるべきです。

どのwin32C/ C ++コンパイラが80ビット浮動小数点演算を管理できますか？

ColdFusion の数学演算が浮動小数点演算の問題の影響を受けないように見えるのはなぜですか? コードを取得します。

どの出力

0.07

java.lang.Double

ただし、同等の Java コードは、2 つの double を追加するときに期待するものを生成します。

これは、浮動小数点演算 ( http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html )の現実により、ColdFusion に期待するものです。

ColdFusion は舞台裏で何らかの「魔法」を行っているのでしょうか、それともここで孤立した異常を見ているのでしょうか?

私は基本的なデータ型について知っており、float 型 (float、double) はいくつかの数値を正確に保持できないことを知っています。

ただし、コードを Matlab から Python (Numpy) に移植する際に、計算に大きな違いがあることがわかりました。

最初の 2 つの要素だけがゼロ以外の値を持つ 500 次元のベクトルを z 正規化する次のコードを見てください。

マトラブ:

パイソン:

フォーマットがPythonでもう少し多くの数字を示していることに加えて、0.02以上の大きな違いがあります（imho）

Python と Matlab の両方が 64 ビット データ型を使用しています (afaik)。Python は「numpy.float64」と Matlab の「double」を使用します。

なぜこんなに差が大きいのでしょうか？どちらがより正しいですか？

ParaView で処理/可視化する C++ プログラムからのデータを印刷していますが、浮動小数点数に問題があります。Paraview は Float32 と Float64 の両方のデータ型をサポートしています。Float64 は、典型的な制限 +/-1.7e +/- 308 の double と同等です。しかし、私のコードは 6.5e-318 のような数値を出力しています。これは、データの読み取り時に ParaView でエラーをスローしています。これらの小さい数値をゼロに丸めると、ParaView のエラーが消えることを確認しました。なぜこのような「高精度」出力が得られるのかはわかりません。おそらく、一部の数値が double よりも高い精度で格納されているためです。たとえば、次のコードは私のシステムで同じ動作を再現します。

私の出力は次のとおりです。

私のシステムは Mac OS X Snow Leopard で、上記を GCC 4.2 と GCC 4.6 でフラグ-m32, -m64and -ffloat-store(これが役立つかどうかはわかりません) でテストしました。

実際、私にとっての出力は問題ありませんが、ParaView の場合はそうではありません。なぜこの違いがあるのか​​ 知りたいだけです。重要な可能性のある浮動小数点数に関連するものを無視している可能性が非常に高いです。double のこの出力/数値動作についての手がかりを教えてください。

この小さなコードは私を夢中にさせます:

実際、私はIEEE 754規格の浮動小数点数の内部表現による病理学的ケースを実証しようとしていました. MacOS または Windows マシンでは、最終的な出力行は次のようになります。

サイクル 29 値 :1.28084153156127500000e+13

しかし、Linux (Scientific Linux 5.4) では、コードは問題なく実行されます。読んで、次のことがわかりました。

FreeBSD、NetBSD、OpenBSD などの BSD システムでは、ハードウェアの倍精度丸めモードがデフォルトであり、ネイティブの倍精度プラットフォームとの最大の互換性を提供します。x86 GNU/Linux システムでは、デフォルトのモードは拡張精度です (精度を高めることを目的としています)。

同じページのGCC INTROでは、Linux システムで倍精度丸めを有効にする方法が説明されていましたが、他のシステムで拡張精度を使用する方法については説明されていませんでした。MacOsまたはWindowsでそれは可能ですか? そしてどうやって ？