財務データの計算に関しては、「丸め」基準の存在に興味があります。私の最初の考えは、データがユーザー(プレゼンテーション層)に提示されているときにのみ丸めを実行することです。
「丸められた」データがその後の計算に使用される場合、「丸められた」数値または「生の」数値を使用する必要がありますか?誰かアドバイスはありますか?
銀行の丸めなど、さまざまな丸め方法を知っていることに注意してください。
財務データの計算に関しては、「丸め」基準の存在に興味があります。私の最初の考えは、データがユーザー(プレゼンテーション層)に提示されているときにのみ丸めを実行することです。
「丸められた」データがその後の計算に使用される場合、「丸められた」数値または「生の」数値を使用する必要がありますか?誰かアドバイスはありますか?
銀行の丸めなど、さまざまな丸め方法を知っていることに注意してください。
最初の最も重要なルール:10進数のデータ型を使用し、決して2進数の浮動小数点型を使用しないでください。
正確に丸めを実行する必要がある場合は、ユーロとそれが置き換えた国の通貨との間の変換などの規制によって義務付けることができます。
そのようなルールがない場合は、すべての計算を高精度で行い、表示のためにのみ丸めます。つまり、丸められた値をそれ以上の計算には使用しません。これにより、全体として最高の精度が得られるはずです。
私が働いている金融ソフトウェア会社の灰色のひげのメインフレームプログラマーに聞いたところ、彼はよく知られた標準はなく、プログラマーの練習次第だと言った。
統計家は少なくとも1906年以来、丸めの問題を認識してきましたが、それを支持する財務基準を見つけることは困難です。
この状況によると、「欧州委員会の報告書「ユーロの導入と通貨額の 四捨五入は、銀行の四捨五入に対する標準的なアプローチがこれまでなかったことを示唆している」とのことです。
一般に、作業している基数(基数2または基数10)に関係なく、対称丸めモードを使用します。
これにより、計算中の体系的なバイアスを回避できます。
このようなモードはRound-Half-To-Evenであり、「バンカー丸め」とも呼ばれます。
丸めモードや切り捨てモードなど、数値コンテキストを明示的に指定できる言語ツールを使用します。たとえば、Pythonのdecimal
モジュール。Cライブラリによって行われた暗黙の仮定は、計算に適さない場合があります。
プログラマーを導くためにも、法廷での弁護としても、これに関する明確な基準がないことは苛立たしいことです。給与の最も近いものに向かって「通常の」丸めを行うだけで、あちこちの給与で数ペニーの過少支払につながる可能性があります。これは、労働弁護士がひび割れのように食い尽くすものです。
基本給率は小数点以下第2位でしか指定できない場合がありますが(「あなたは$ 22.71 /時間で雇用されています」)、時間外労働の混合(期間内の複数の賃金率を平均することによって決定される)のようなものは、最終的に実効時給になります。 23.37183475ドル/時間。
その上で残業代をどのように支払いますか?
15 hours x 23.37183475 x 1.5 = $525.87 rounded from $525.86628187
15 hours x 23.37 x 1.5 = $525.82
クライアントから5セントを盗んだのはなぜですか?悲しいことに、私はこれについて冗談を言っていません。
これは、完全な精度の値で計算するが切り捨てられたバージョンを表示する場合、さらに不快になります。上記の最初の計算を実行しますが、給与明細のレートに対して$23.37しか表示しません。
今では給与明細の計算はペニーとは関係がなく、説明する必要がありますが、それが従業員に有利であっても、労働法の弁護士が水中の血の匂いを嗅いで他の人を探し始めるのに十分な場合がありますもの。
1つのアプローチは、自然な方向ではなく、常に従業員に有利に働くことです。そのため、体系的な賃金の盗難の告発はあり得ません。
「それらすべてを支配する1つの基準」の存在を見たことがありません-(あなたが参照したように)丸め規則はいくつもあり、それらは業界/顧客/および通貨コード(http:/ /en.wikipedia.org/wiki/ISO_4217)-すべての人が小数点以下2桁を使用するわけではないため、問題はさらに複雑になります。一日の終わりに、顧客は実装したいルールを指定する必要があります...
スケーリングされた整数の使用を検討してください。
言い換えれば、ドルの小数ではなく、ペニーの整数を格納します。