問題タブ [rounding-error]

C++の丸め誤差について読んでいたところです。したがって、数学を多用するプログラム（または重要な計算）を作成している場合は、フロートをすべてまとめてドロップし、doubleのみを使用する必要がありますか、それとも丸め誤差を防ぐためのより簡単な方法がありますか？

MidpointRounding.ToEvenC＃では、2つの小数点以下の丸め戦略との精度に違いはありMidpointRounding.AwayFromZeroますか？つまり、両方とも、丸められる数値間で均等に分散されるようにするのでしょうか、それとも、一方の丸め戦略が、他方と比較して丸められた数値を表すよりも優れているのでしょうか。

引数として2つの整数を取り、返すメソッドがあります:

値 1400 と 1500 (期待値は 43) で合格する単体テストを作成しましたが、1459 と 1500 では失敗します。期待される出力は 18 ですが、メソッドは 17 を返します。これは丸めと関係があると思います。 、ただし、明らかなエラーは表示されません。17.7(6) を 18 に丸めることに問題はありません。

編集：

実際の関数はわずかに異なっていました (私は Math.abs(ab) を持っていませんでしたが、代わりに、この結果として "diff" 変数を定義しました。私はそれを double diff として宣言したことを皆さんに約束することができました; - 私にはわかりません)なぜint diffになるのですか:)解決済みありがとう:)

以下のクラスをユニットテストしようとすると、次の丸め誤差が発生します。

単体テスト：

出力：

丸め誤差では効果がないはずなので、ドルの値についてはPick Axeの本で推奨されているため、Floatsを使用しています。

私はruby 1.9.2p290 (2011-07-09) [i386-mingw32]Windows764ビットHomeとWindowsXP32ビットProで実行しています。

私はもう試した

• 変数をfloatにキャストする
• +=を削除して増分をスペルアウト

動作はランダムに表示されます。

• 12.22+7.31は動作します
• 11.11+7.31が機能しない
• 11.111+7.31は動作します

何がうまくいかないのですか？

C で書き直した R コードのブロックがあり、2 つのバージョンで異なる結果が得られます。私の考えでは、これは R レベルでの丸めの問題によるものです。つまり、C ですべてが行われ、丸めが 1 回だけ行われるのとは対照的に、複数の数学演算が実行され、複合丸めの問題が発生します。私はここで過度に楽観的であり、何かが欠けているかどうかを確認するためにもう少し目を向けたいと思っていました.

最初の R コード:

今Cで：

例として、値 5、5、5、0 を渡すと、R では 13.19、C では 12.69 が得られます。技術的には、R コードはベクトル化されますが、C コードのこの特定のブロックはそうではないため、ベクトル化された入力を次のように提供したくありません。例。

これらは機能的に同じですか、それとも間違ったことをしていますか?

次の仕様を検討してください。

このメソッドtotal_percentは、値のリストの差の合計をパーセントで計算します。アルゴリズム自体は無視してください (最初と最後の値だけを見ても同じ結果が得られます)。

計算結果が と等しくないため、仕様は失敗します0.0。問題は、どこで精度が失われるかです。

編集： OS X 10.7.2でJRuby 1.6.5を使用。

これは、ウィキペディアのカハンの加算アルゴリズムです。

（加算ではなく）減算を使用する特定の理由はありますか？の計算でオペランドを入れ替えた場合、c代わりに加算を使用できますか？どういうわけか、それは私にとってより理にかなっているでしょう：

それとも、私がまだ知らない浮動小数点の加算と減算の間に奇妙な違いがありますか？

また、元のアルゴリズム(t - sum) - yとの間に違いはありますか？とにかく、左結合であるt - sum - yため、括弧は冗長ではありませんか？-

Linux x86_64 の C++ コードでは、倍精度計算 (+ または -) が必要です。

26.100000000000001 - 26 + 0.10000000000000001

私が得た：

0.20000000000000143

0.2を取得したいです。

ここでは、表示形式はインポートではなく、計算結果が if-else 分岐条件に使用されます。したがって、if-else 条件で 10 進数の後の 4 桁を比較するだけです。

丸め誤差のようですか？

計算精度を小数点以下4桁に制限するには?

オーバーヘッドを避けるために、関数を呼び出したくありません。

変換のオーバーヘッドがあるため、stringstream を使用したくありません。

より良いアイデアはありますか？

ありがとう

Google カレンダーと Outlook がすべての時間エントリが 30 分離れている時間選択を処理する方法をエミュレートしようとしています。私は、1 つのことを除いて、ほぼすべての機能テストを機能テストで使用しています。私の問題は、現在の日付を常に 30 分に丸める方法がわからないことです。

私は次のコードを使用しています：

これは、午前 12 時 (午前 12 時 30 分に返されると予想される場合) と午前 8 時 56 分 (午前 9 時に返されると予想される場合) を除いて、ほとんどの場合に機能します。

どうすればこれを修正できますか?

生の画像を jpeg 画像にエンコードする際に、8x8 データ ユニットがレベル シフトされ、2-D DCT を使用して変換され、量子化され、ハフマン エンコードされます。

最初に行 DCT を実行し、次に列 DCT を実行し、結果を最も近い整数に丸めました。このブロックを量子化モジュールに送りました。量子化中に、次の Q テーブルを使用しました。これらの表は、品質係数 99 に対して IJG によって推奨されています。

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
1 1 1
1 1
1 1 2 2 1
1 1 1 1 2 2 2
1 1 1 2 2 2 2
1 1 2 2 2 2 2 2
1 2 2 2 2 2 2 2

1 1 1 1 2 2 2 2
1 1 1 1 2 2 2 2
1 1 2 2 2 2
1 1 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2 2
2 2
2 2 2 2 2 2 2 2 2 2 2 2
2 2 2 2

「2」で割っている間の量子化中に、結果をゼロから四捨五入しました。例: 11/2 = 6. したがって、デコード中の逆量子化中にすべての奇数に +1 のエラーが追加されます。

別のセットアップでは、丸め手法を変更しました。ここでは、結果をゼロに丸めています。例: 11/2 = 5. したがって、復号化中の逆量子化中にすべての奇数に -1 のエラーが追加されます。

2 番目のケースでは、ファイル サイズが非常に小さくなり (768x512 画像の場合、ほぼ 100 kb 小さくなります)、PSNR が大きくなります。2 で量子化すると「1」であるすべての AC 係数が 1 ではなく 0 になるということで、ファイル サイズが小さいことを説明できました。したがって、RLE はファイル サイズを小さくします。しかし、エンコードの画質が向上している理由を説明することはできません。2 ～ 3 dB 増加しており、テストしたすべての画像で発生しています。

私の主張は、DCT は基本的に A * DCTmatrix のどちらの側でも等しいエラーであるため、等しい損失が生じるはずです。しかし、ここではそうではありません。