갑자기 우리 생활의 금융 시스템은 소수점 이하 두 자리만 있는데, 이는 분 단위까지 정확합니다. 은행 등 소수점 3자리까지 계산해야 하는데 왜 소수점 2자리까지만 잔액이 보이는 걸까요? 모직물은 어떻게 생략되나요? 나는 이 질문이 흥미롭다고 생각한다.
내 추측:
실제로 우리 금융 시스템에서는 소수점 이하 두 자리만 사용하는 한, 소수점 이하 두 자리 이상이 생성되면 다음 소수 자리는 5 뒤에 1을 추가하는 대신 직접 사용할 필요가 없습니다. 추가하면 사용자에게 추가 비용이 발생합니다. 0.001위안이 추가되더라도 전체 시스템의 손실은 엄청나므로 소수점 이하 2자리 이상이면 직접 생략할 수 있습니다. 소수점 이하 0.239라도 0.009는 생략해야 합니다. 이 0.009위안의 손실은 사용자만이 부담할 수 있습니다.
예를 들어 은행 시스템, Alipay는 모두 소수점 이하 두 자리를 사용합니다. 우리는 일반적으로 잔액 필드에 decimal(10,2)
을 사용하여 소수점 이하 두 자리를 유지합니다. 갑자기 이 문제가 생각났는데 너무 혼란스럽습니다. 나인지는 모르겠다. 그렇게 생각해라.
예를 들어 알리페이에서 포인트와 쇼핑쿠폰을 사용해 여러 주문을 동시에 차감할 때 차감금액이 주문금액 비율에 따라 주문별로 나눠지는 것 같아서 소수가 나오는데 그 소수가 또한 두 사람에 대해 세심한 주의를 기울이지 않았으며 여러 주문에 대한 공제액이 주문할 때 공제된 금액에 합산되는지 모르겠습니다.
그렇다면 우리는 그동안 많은 돈을 잃었을 것 같은데요? 원래는 소수점 이하 자릿수를 몇 개 더 유지하여 이 문제를 해결하고 싶었지만 소수점이 무한할 수도 있다고 생각하는데, 그래도 사용자가 조금만이라도 돈을 잃을 수는 없을 것입니다.
누가 나에게 조언을 해주길 바랍니다. 현재 내 프로젝트에서 이런 종류의 문제가 발생하고 있습니다.
감사합니다!
갑자기 우리 생활의 금융 시스템은 소수점 이하 두 자리만 있는데, 이는 분 단위까지 정확합니다. 은행 등 소수점 3자리까지 계산해야 하는데 왜 소수점 2자리까지만 잔액이 보이는 걸까요? 모직물은 어떻게 생략되나요? 나는 이 질문이 흥미롭다고 생각한다.
내 추측:
실제로 우리 금융 시스템에서는 소수점 이하 두 자리만 사용하는 한, 소수점 이하 두 자리 이상이 생성되면 다음 소수 자리는 5 뒤에 1을 추가하는 대신 직접 사용할 필요가 없습니다. 추가하면 사용자에게 추가 비용이 발생합니다. 0.001위안이 추가되더라도 전체 시스템의 손실은 엄청나므로 소수점 이하 2자리 이상이면 직접 생략할 수 있습니다. 소수점 이하 0.239라도 0.009는 생략해야 합니다. 이 0.009위안의 손실은 사용자만이 부담할 수 있습니다.
예를 들어 은행 시스템, Alipay는 모두 소수점 이하 두 자리를 사용합니다. 우리는 일반적으로 잔액 필드에 decimal(10,2)
을 사용하여 소수점 두 자리를 유지합니다. 갑자기 이 문제가 생각나서 너무 혼란스럽습니다. 나인지는 모르겠다. 그렇게 생각해라.
예를 들어 알리페이에서 포인트와 쇼핑쿠폰을 사용해 여러 주문을 동시에 차감할 경우, 차감금액은 주문금액의 비율에 따라 주문별로 차감금액이 나누어지는 것 같아서 소수점이 나오는데, 그 소수점이 있습니다. 저도 2명인데, 주의 깊게 살피지 않았는데, 여러 주문에 대한 차감액이 주문 시 차감된 금액에 합산되는지 모르겠습니다.
그렇다면 우리는 그동안 많은 돈을 잃었을 것 같은데요? 원래는 소수점 이하 자릿수를 몇 개 더 유지하여 이 문제를 해결하고 싶었지만 소수점이 무한할 수도 있다고 생각하는데, 그래도 사용자가 조금만이라도 돈을 잃을 수는 없을 것입니다.
누가 나에게 조언을 해주길 바랍니다. 현재 내 프로젝트에서 이런 종류의 문제가 발생하고 있습니다.
감사합니다!
은행원의 반올림 방법이 있습니다. 즉,
반올림 숫자 값이 5보다 작으면 바로 폐기됩니다.
반올림 숫자 값이 6보다 크거나 같으면 반올림하여 폐기됩니다.
값이 6보다 크거나 같으면 폐기됩니다. 반올림 숫자가 5인 경우 두 가지 유형이 있습니다. 상황: 5 뒤에 다른 숫자(0이 아닌)가 있는 경우 5 뒤에 0이 있으면(즉, 5가 마지막 숫자) 반올림되어 버려집니다. ) 이후 5 이전 숫자의 패리티를 기준으로 캐리가 필요한지 여부를 판단합니다. 홀수 캐리, 짝수를 버립니다.
위 규칙을 기반으로 한 예로 숫자가 한 자리까지 정확해야 한다고 가정해 보겠습니다.
<code>49.6101 -> 50 49.499 -> 49 49.50921 -> 50 48.50921 -> 48 48.5101 -> 49</code>
다음은 이 계산 방법의 장점을 보여주는 좋은 예입니다.
2.55 + 3.45 = 6
소수점 한 자리를 유지하고 2.55와 3.45를 변환하면 다음과 같습니다.
2.6 + 3.5 = 6.1
분명히 이것은 추가 0.1이므로 "5에서 두 배로 반올림" 계산에 따르면 2.55는 실제로 2.550이라고 할 수 있습니다. 5 이후에는 반올림하고 싶습니다. 0이면 이전 숫자의 패리티를 기준으로 캐리 여부를 판단합니다. 당연히 이전 숫자가 홀수이면 캐리 이후에는 2.6이 됩니다. 이전 5가 짝수이면 폐기되며 결과는 3.4이므로 둘 다 다음과 같이 계산됩니다. 2.6 + 3.4 = 6
2016-11-24 추가설명
이 사용되기 때문에 이런 상황도 존재할 것입니다. 핵심은 2.45 + 2.45입니다. 기존의 반올림은 반올림되지 않고 중간 값에 가까워지는 상황을 피해야 합니다. 그래야만 보장할 수 있기 때문입니다. 이것이 주요 목적입니다. 결국 정확도가 제한되는 한 손실이 있을 수밖에 없습니다. 많은 수의 샘플에서 확률이 동일한지 확인하면 됩니다.
近似计算中舍去和进位的概率相等
이 분야의 자금 문제는 여전히 비즈니스 요구를 고려해야 합니다. 이전 연습에 따르면 소수점 4자리를 저장했습니다. 다양한 시나리오에 따라 선택하세요! 단, 프런트에 표시되는 금액은 모두 2자리만 표시되며,
아래로 숫자 조회다음 장면과 같습니다:
이면 실제 인출할 수 있는 현금 금액은 向下取数
입니다. 10.1234
10.12
할부관련
이 됩니다. 이건 함정이다
1000/3=333.3333333
일반적인 관행은 다음과 같습니다. 333.33
처음 두 기간은 반올림하여 계산됩니다. 뺄셈으로 계산한 마지막 호: 999.99
;
업종에 따라 예약된 자릿수와 장단점이 다릅니다. 예를 들어 펀드의 순가치 등이 있습니다. 소수점의 길이는 여전히 자금 금액에 큰 영향을 미칩니다. 이는 정확할수록 좋습니다. 귀하의 특정 요구 사항에 대해 제품과 소통하십시오! 1000-333.33-333.33=333.34
매우 전문적인 내용은 잘 모르겠지만, 시스템을 구축할 때 고려할 사항은 없다고 생각합니다. 소수점 이하 두 자리 이후의 모든 사용자는 돈을 잃게 됩니다
금액이 0.111이면 0.11로 기록됩니다.
금액이 0.111이면 0.11만 지급됩니다
물론 두 자리는 아니겠지만, 계산과 저장 모두 6자리 이상입니다(더 있을지는 확실치 않으나 최소 6자리는 확실합니다)
그냥 최종적으로 주어지는 점수일 뿐입니다 나중에 현금화할 수 없으므로 특정 알고리즘에 따라 최종 결과가 계산됩니다.
컴퓨터의 정수 1은 십진수 1.0과 같지 않으므로 화폐의 소수를 정수로 변환하여 처리합니다
계산 방법은 '주다'와 '받다'를 사용하여 점수를 계산합니다.
'주다': 필드 값이 200.11이면 위안은 2위안이고 1.1센트. 이 1.1센트는 버릴 수 있고 2위안만 준다. 즉, 정수 부분만 가져간다.
"수집하다": 절대 고통받지 않는다는 디자인 원칙에 맞춰 상대적으로 이기적일 수 있다. 손실이 있는 경우 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入,没有什么好纠结的,相信老祖宗的智慧。
从统计学的角度上来看,在大规模的应用的情况下,你们金融系统多出来的和少掉的钱是近似的,同样的,用户多出来和少掉的钱也是近似的,没有必要纠结。
没有做过金融系统开发,权当抛砖引玉了。