浮動小数点モジュラスの正確さが重要なのはなぜですか？

ほとんどのSmalltalk方言は現在、単純な浮動小数点係数（fmod / remainder）を実装しています。
Squeak / Pharoを改善し、最終的には他のSmalltalkの標準（IEEE 754、ISO / IEC 10967）への準拠を改善するために、これを変更しました。

ただし、これらの変更の採用については、標準に準拠するだけでは同僚を納得させることができないため、この正確さがどのような状況で実際に重要であるかを説明すると、非常に役立ちます。今のところ、自分で良い例を見つけることはできません。

ここで誰かが、なぜ/いつ/どこで（どのアルゴリズムのIOW）そのような係数の正確さが重要になるか知っていますか？

arithmetic floating-point

— aka.nice
ソース

私は考えてあなたがより良い答えを得る可能性がある計算科学を、このような問題は、彼らの（サブ）ドメインにおいてより重要なので。いずれにせよ、質問はここでオントピックであり、再投稿の数日前に回答者に通知する必要があります。

— ラファエル

震えたfmod / modfの正確さに依存するコードを見たことがありますが、言語が素朴な不正確な浮動小数点係数を実装しようとする可能性はさらに恐ろしいようです。コード例：（1）残りを取りなさい。（2）ゼロの場合は停止します。（3）2を掛けて（1）に進みます。このプロセス中にいくつかの有用な作業を行うことができますが、重要な点は、このプロセスの終了は、剰余の正確さと2による乗算の正確さに依存するということです。計算科学がより適切であると思われるため、ここでより完全な答えを出す必要があるかどうかわかりません。この質問のために。

— Thomas Klimpel 2014年

推測の1つは、三角関数の入力を正規化することです。

— Paul A. Clayton、2014年

@ThomasKlimpelあなたが参照を見つけたら私は興味があります。単純な剰余は（x-（（y / x）truncated * x））として定義され、IEEEで最も近い偶数の演算に丸められます。exactRem（x、y）== 0 => naiveRem（x、y） == 0。問題は反対です-偽の正確な除算の正-naiveRem（4.0,0.1）== 0.0のように、残念ながら多くの場合ナイーブな期待に適合します！

— aka.nice 2014年

@ PaulA.Claytonはい、たぶん度のサインのため...多分、私の推測では、単純なレムは正確に約。360には6ビットの範囲しか設定されていないため、および360の除数は前の360の倍数に切り上げられないように見えるため、1e16度...ラジアンの場合、適切なライブラリには複数の精度が必要で、正確なレムは倍精度に制限されます。そのような場合に本当に役立ちますか？

— aka.nice 2014年

不正確な浮動小数点の実装は天候に影響することに注意してください。

異なるハードウェアで同じ入力を使用して気象予測を実行するテストがあり、予測は分岐しました。反復アルゴリズムを実行している場合、ここまたは小さな丸めの違いにより、太陽の光が雨に変わる蝶の効果が生じる可能性があります。

規格の丸め規則（IEEE 754、ISO / IEC 10967）は慎重に検討されており、数値アルゴリズムは予測可能に最も正確に動作し、毎回同じ結果を再現します。これらの丸め規則用に設計された標準の数値アルゴリズムに従わないと、天気予報などの反復アルゴリズムが壊れ、ランダムな結果が得られることもあります。

（そしてそれは天気予報について何か言いませんか？:)

— ゴスウィンフォンブレダーロー
ソース

一方、バタフライ効果が日光を雨に変える場合、結果はとにかく役に立ちませんでした。

— gnasher729

むかしむかし、浮動小数点データを十分な桁数のないASCIIで保存しました。あるクライアントが私に問題を示したいと思っていましたが、ASCIIファイルからデータを復元した後、問題は消えました。私はいくつかのulpは問題にならないはずだと言った、彼の問題が条件が悪ければ、とにかく私にできることは何もない。それは彼のビジネスだと彼は言った、私のものは彼自身の問題の再現性を可能にするソフトウェアを提供することでした。彼は正しかったです。

— aka.nice 2018年

そのため、％aを使用して、保存用の浮動小数点数を16進数として出力する必要があります。

— Goswin von Brederlow