二級標題
二級標題
目前主流計算機語言表示浮點數大多遵循了IEEE 754標準，Rust語言也不例外。如下是Rust語言中有關雙精度浮點類型f64的說明與計算機內部二進制數據保存形式：
圖片
圖片
圖片
浮點數採用了底數為2的科學計數法來表達。例如可以用有限位數的二進制數0.1101 來表示小數0.8125，具體的轉化方式如下：
然而對於另一個小數0.7來說，其實際轉化為浮點數的過程中將存在如下問題：
即小數0.7 將表示為0.101100110011001100.....(無限循環)，無法用有限位長的浮點數來準確表示，並存在“舍入(Rounding)”現象。
假設在NEAR公鏈上，需要分發0.7個NEAR代幣給十位用戶，具體每位用戶分得的NEAR代幣數量將計算保存於result_0變量中。
執行該測試用例的輸出結果如下：
可見在上述浮點運算中，amount的值並非準確地表示了0.7，而是一個極為近似的值0.69999999999999995559。進一步的，對於諸如amount/divisor的單一除法運算，其運算結果也將變為不精確的0.06999999999999999，並非預期的0.07。由此可見浮點數運算的不確定性。
對此，我們不得不考慮在智能合約中使用其它類型的數值表示方法，如定點數。
根據定點數小數點固定的位置不同，定點數有定點（純）整數和定點（純）小數兩種。
小數點固定在數的最低位之後，則稱其為定點整數
在實際的智能合約編寫中，通常會使用一個具有固定分母的分數來表示某一數值，例如分數' x/N '，其中' N '是常數，' x '可以變化。
若“N”取值為“1,000,000,000,000,000,000”，也就是: ' 10^18 '，此時小數可被表示為整數，像這樣:
在NEAR Protocol中，該N常見的取值為' 10^24 '，即10^24 個yoctoNEAR等價於1個NEAR代幣。
基於此，我們可以將本小節的單元測試修改為如下方式進行計算：
以此可獲得數值精算的運算結果: 0.7 NEAR / 10 = 0.07 NEAR
2. Rust整數計算精度的問題
從上文第1小節的描述中可以發現，使用整數運算可解決某些運算場景中浮點數運算精度丟失問題。
但這並非意味著使用整數計算的結果完全是準確可靠的。本小節將介紹影響整數計算精度的部分原因。
2.1 運算順序
同一算數優先級的乘法與除法，其前後順序的變化可能直接影響到計算結果，導致整數計算精度的問題。
例如存在如下運算：
執行單元測試的結果如下：
我們可以發現result_0 = a * c / b 及result_1 = （a / b）* c儘管它們的計算公式相同，但是運算結果卻不同。
分析具體的原因為：對於整數除法而言，小於除數的精度會被捨棄。因此在計算result_1的過程中，首先計算的(a / b) 會率先失去計算精度，變為0；而在計算result_0時，會首先算得a * c的結果20_0000，該結果將大於除數b，因此避免了精度丟失的問題，可得到正確的計算結果。
2.2 過小的數量級
該單元測試的具體結果如下：
可見運算過程等價的result_0和result_1運算結果並不相同，且result_1 = 13更加地接近於實際預期的計算值：13.3333....
3. 如何編寫數值精算的Rust智能合約
保證正確的精度在智能合約中十分重要。儘管Rust語言中也存在整數運算結果精度丟失的問題，但我們可以採取如下一些防護手段來提高精度，達到令人滿意的效果。
3.1 調整運算的操作順序
令整數乘法優先於整數的除法。
3.2 增加整數的數量級
整數使用更大的數量級，創造更大的分子。
比如對於一個NEAR token來說，如果定義其上文所描述的N = 10，則意味著：若需要表示5.123的NEAR價值，則實際運算所採用的整數數值將表示為5.123* 10^10 = 51_230_000_000 。該值繼續參與後續的整數運算，可提高運算精度。
3.3 積累運算精度的損失
對於確實無法避免的整數計算精度問題，項目方可以考慮記錄累計的運算精度的損失。
假設如下使用fn distribute(amount: u128, offset: u128) -> u128為USER_NUM位用戶分發代幣的場景。
在該測試用例中，系統每次將給3位用戶分發10個Token。但是，由於整數運算精度的問題，第一輪中計算per_user_share時，獲得的整數運算結果為10 / 3 = 3 ，即第一輪distribute用戶將平均獲得3個token，總計9個token被分發。
此時可以發現，系統中還剩下1個token未能分發給用戶。為此可以考慮將該剩餘的token臨時保存在系統全局的變量offset中。等待下次系統再次調用distribute給用戶分發token時，該值將被取出，並嘗試和本輪分發的token金額一起分發給用戶。
如下為模擬的代幣分發過程：
可見當系統開始第3輪地分發代幣時，此時系統積累的offset值已達到2，該值將再次與本輪所要分發的10個token累加在一起，發放給用戶。 (本次計算per_user_share = token_to_distribute / USER_NUM = 12 / 3 = 4將不存在精度損失。)
從整體上來看，在前3輪中，系統一共發放了30個Token。每個用戶在每一輪中分別獲得了3、3、4個token，此時用戶也總計獲得30個token，達到了系統足額發放獎金目的。
3.4 使用Rust Crate庫rust-decimal
