金融システムでは小数点以下 2 桁しか保持されないのはなぜですか? 小数点以下 2 桁を超える金額がある場合はどうなりますか?-PHPチュートリアル-php.cn

金融システムでは小数点以下 2 桁しか保持されないのはなぜですか? 小数点以下 2 桁を超える金額がある場合はどうなりますか?

WBOY

リリース： 2023-03-01 20:06:01

オリジナル

7340 人が閲覧しました

私たちの生活の金融システムには分まで正確な小数点以下 2 桁しかありません。しかし、小数点以下 2 桁と非整数で計算すると、結果は 3 桁になります。銀行の日額などの小数点以下の計算は必ずありますが、小数点以下 2 桁の残高だけが表示されるのはなぜですか?どうして省略されるのでしょうか？この質問は興味深いと思います。

私の推測:

実際、私たちの金融システムが小数点以下 2 桁のみを使用する限り、2 桁以上の小数点以下の桁が生成される場合、5 を 1 に加算する代わりに、次の小数点以下の桁は必要ありません。、たとえ0.001元多くても、システム全体の損失は莫大になるため、小数点以下2桁以上ある場合は、次の小数点以下を直接省略することしかできません。 0.239 の場合、0.009 を省略する必要があります。この 0.009 10,000 人民元の損失はユーザーのみが負担できます。

たとえば、銀行システム、Alipay、これらはすべて小数点以下 2 桁を維持するために decimal(10,2) を使用します。私は突然この問題を思いつき、本当に混乱しました。と思った。

例えば、Alipayでポイントやお買物券を使って複数の注文を同時に引き落としする場合、注文金額の割合に応じて注文ごとに控除額が分割されるようで、小数点が表示されますが、小数点以下も2になりますちょっと、私はあまり注意していないので、複数の注文による控除額が注文時の控除額と合計されるかどうかはわかりません。

そう思うなら、私たちは頻繁に多額のお金を失っているはずだと思いますか？当初は小数点以下をもう少し保持することでこの問題を解決したいと考えていましたが、小数点以下が無限に存在する可能性があると感じていますが、その可能性はまだ低く、ユーザーが少しでもお金を失うだけでしょうか。

私は現在プロジェクトでこの種の問題に遭遇しているので、誰かが私にアドバイスをくれることを願っています。

ありがとう！

返信内容:

私の推測:

そう思うなら、私たちは何度も多額のお金を失っているはずだと思いますか？当初は小数点以下をもう少し保持することでこの問題を解決したいと考えていましたが、小数点以下が無限に存在する可能性があると感じていますが、その可能性はまだ低く、ユーザーが少しでもお金を失うだけでしょうか。

私は現在プロジェクトでこの種の問題に直面しているので、誰かが私にアドバイスをくれることを願っています。

ありがとう！

バンカー四捨五入メソッドがあります。つまり、

丸め桁の値が 5 未満の場合はそのまま切り捨てられます

丸め桁の値が 6 以上の場合は桁上げ後に丸められます
丸め桁の値が等しい場合は丸められます5 の後に何かがある場合、他の数値 (0 以外) は四捨五入されて破棄されます。5 の後に 0 が続く場合 (つまり、5 が最後の桁である場合)、桁上げが必要かどうかが決定されます。 5 より前の桁のパリティに基づいて計算されます。奇数は伝送され、偶数は破棄されます。

たとえば、上記のルールに基づいて、数値が 1 桁の精度である必要があるとします。

リーリー

この計算方法の利点を理解するための良い例を次に示します:

2.55 + 3.45 = 6

小数点以下 1 桁を保持して 2.55 と 3.45 を変換したい場合は、次のようになります:

2.6 + 3.5 = 6.1

明らかに、これは 0.1 多いので、「5 に切り上げ」に従って計算すると、2.55 は実際には 2.550 であると言えます。四捨五入したい 5 の後に 0 が続き、前の式に従ってなります。 1 桁のパリティはキャリーがあるかどうかを判断するために使用されます。明らかに、前が奇数の場合、キャリーは 2.6 です。5 の前が偶数の場合、それは破棄されます。、結果は 3.4 したがって、2 つの計算は次のようになります。 2.6 + 3.4 = 6

2016-11-24 追加手順

誰かが 2.55 + 2.55 を提案しましたが、これでもまだ 0.1 のオーバーカウントです。なぜこの例を挙げなかったのですか?

rounding

を使用しているため、この状況も存在します。重要な点は 2.45 + 2.45 です。この方法でのみ

が保証されるため、桁上げなしで中間値に近づくという状況を回避する必要があります。これが主な目的です。結局のところ、精度が限られている限り、損失が存在する必要があるのは、多数のサンプルの下で確率が等しいことを確認することだけです。 近似计算中舍去和进位的概率相等

この分野の資金調達の問題は、ビジネスのニーズを考慮する必要があります。以前の練習に従って、小数点以下 4 桁を保存しました。さまざまなシナリオに基づいて選択してください。ただし、フロントに表示される金額はすべて2桁のみで、桁は切り捨てとなります

次のようなシーン:
残高の引き出し、送金など

一般的にはそうです

。

分割払い関連

向下取数，比如10.1234;那实际可提现金额为10.12

たとえば、銀行の限度額の合計が 1,000 元で、何かを買うだけで全額使ってしまった場合、分割払いを申請できます。 3つのフェーズに分かれています

普通に考えれば

です。これは罠です

一般的な方法は次のとおりです:
最初の 2 つの期間は四捨五入によって計算されます。引き算で計算された最後の問題: 1000/3=333.3333333;在四舍五入一下就成了333.33;等你三期都还完了，发现只还了999.99;

その他の注意事項

ビジネスによって、予約桁数とトレードオフは異なります。ファンドの純額など。小数点の長さは依然として資金量に大きく影響します。これが正確であればあるほど良いです。特定のニーズについて製品とコミュニケーションしてください。 1000-333.33-333.33=333.34

実際にはそうではありません。当社の電子商取引金融システムが調整と手数料計算を実行すると、すべて最後の 6 桁に達します。 10 進数 (16, 6) は計算が終わるまで四捨五入されません。一般的に、最終的な丸めのステップは契約書に書かれており、最後のステップは交渉の範囲内にあると思います。もうシステムとは何の関係もありません。

あまり専門的な事は分かりませんが、システムを構築する際に考慮する事は無いと思います

金額が0.111であれば0.11として記録されます

小数点以下2桁以降は全て負けとなります。、0.11のみが出力されます

もちろん2桁にはならず、計算も保存も6桁以上(それ以上あるかどうかは不明ですが、少なくとも6桁は確実です)
ただ、ユーザーに最終的に付与されるポイントは計算できないだけです特定のアルゴリズムに従って最終結果を計算してキャッシュアウトされます。

コンピューターの整数 1 は小数点の 1.0 と等しくないため、お金の小数点は処理のために整数に変換されます

このように、データベースに保存されている金額フィールドの単位はセントを使用し、フロントで表示する場合は、切り上げてから100で割って元を取得する方が安全だと思います。

銀行が主体の場合、計算方法は「与える」と「受け取る」です。

「与える」: フィールド値が 200.11 の場合、計算された元は 2 元と 1.1 セントです。この 1.1 セントは切り捨てることができます。

「受け取る」: お金を決して失わないという設計原則に沿って、1 センチメートルを 1 ポイントとしてカウントする必要があります。フィールド値に小数点があるかどうかを判断し、小数点がある場合は +1 に丸めます。小数点がない場合は、すべてのマスターが値を判断して処理する必要があります。個人の好みは絶対にお金を失わないという原則です。この原則は金融機関の共通原則でもあります。重要な点は、金額の測定単位としてセントを使用することです。データ型の最大値を考慮する必要があります。範囲を超えないようにしてください。

質問してください、あなたは実際に金融機関がお金を集めるために使用する秘密の方法を明らかにしました、ハハハ。

收款时直接把分以后的数字进位处理，付款时直接截去分以后的小数位。

展示显示2位小数不代表系统中处理都是2位小数吧。我觉得应该会有很多位

要么四舍五入，要么向下取整，保留两位

合理的均分方法可以固定小数位.
比如100元平均分成N份(保留2为小数)并计算尾差:

<code><?php
header('Content-Type: text/plain; charset=utf-8');
function tail($num, $fen) {
    $avg  = bcdiv($num, $fen, 2); //除
    $tail = bcsub($num, $avg*($fen-1), 2); //减
    echo $num.'='.str_repeat($avg.'+', $fen-1).$tail."\n";
    echo "$num=$avg*($fen-1)+$tail\n";
    return array($avg, $tail);
}
var_export(tail(100, 3));
var_export(tail(100, 6));
//输出:
100=33.33+33.33+33.34
100=33.33*(3-1)+33.34
array (
  0 => '33.33',
  1 => '33.34',
)
100=16.66+16.66+16.66+16.66+16.66+16.70
100=16.66*(6-1)+16.70
array (
  0 => '16.66',
  1 => '16.70',
)</code>

ログイン後にコピー

4舍5入，没有什么好纠结的，相信老祖宗的智慧。

从统计学的角度上来看，在大规模的应用的情况下，你们金融系统多出来的和少掉的钱是近似的，同样的，用户多出来和少掉的钱也是近似的，没有必要纠结。

没有做过金融系统开发，权当抛砖引玉了。