在日常生活中，最容易接觸到的小數就是貨幣，比如你付給售貨員10元錢購買乙個9.60元的零食，售貨員應該找你0.4元也就是4毛錢才對，我們來看下面的程式：
public class client我們期望的結果是0.4，也應該是這個數字，但是列印出來的卻是0.40000000000000036，這是為什麼呢？}
這是因為在計算機中浮點數有可能（注意是可能）是不準確的，它只能無限接近準確值，而不能完全精確。為什麼會如此呢？這是由浮點數的儲存規則所決定的，我們先來看0.4這個十進位制小數如何轉換成二進位制小數，使用「乘2取整，順序排列」法（不懂？這就沒招了，太基礎了），我們發現0.4不能使用二進位制準確的表示，在二進位制數世界裡它是乙個無限迴圈的小數，也就是說，「展示」都不能「展示」，更別說是在記憶體中儲存了（浮點數的儲存包括三部分：符號位、指數字、尾數，具體不再介紹），可以這樣理解，在十進位制的世界裡沒有辦法準確表示1/3，那在二進位制世界裡當然也無法準確表示1/5（如果二進位制也有分數的話倒是可以表示），在二進位制的世界裡1/5是乙個無限迴圈小數。
各位要說了，那我對結果取整不就對了嗎？**如下：
public class client列印出結果是0.4，看似解決了，但是隱藏了乙個很深的問題。我們來思考一下金融行業的計算方法，會計系統一般記錄小數點後的4位小數，但是在彙總、展現、報表中，則只記錄小數點後的2位小數，如果使用浮點數來計算貨幣，想想看，在大批量的加減乘除後結果會有多大的差距（其中還涉及後面會講到的四捨五入問題）！會計系統要的就是準確，但是卻因為計算機的緣故不準確了，那真是罪過。要解決此問題有兩種方法：}
（1）使用bigdecimal
bigdecimal是專門為彌補浮點數無法精確計算的缺憾而設計的類，並且它本身也提供了加減乘除的常用數學演算法。特別是與資料庫decimal型別的字段對映時，bigdecimal是最優的解決方案。
（2）使用整型
把參與運算的值擴大100倍，並轉變為整型，然後在展現時再縮小100倍，這樣處理的好處是計算簡單、準確，一般在非金融行業（如零售行業）應用較多。此方法還會用於某些零售pos機，它們的輸入和輸出全部是整數，那運算就更簡單。
2 22 用整數型別處理貨幣
system.out.println 10.00 9.60 本來期望輸出應該是0.4，結果列印出來的卻是0.40000000000000036，這是為什麼呢？因為計算機中的浮點數有可能是不準確的，它只能無限接近準確值，而不能完全精確。使用numberformat雖然能夠列印出0.4，但是往深處考慮，...
mysql處理貨幣
convert zje,decimal 18,2 1 round x,d 用於資料的四捨五入,round x 其實就是round x,0 也就是預設d為0 這裡有個值得注意的地方是，d可以是負數，這時是指定小數點左邊的d位整數字為0,同時小數字均為0 select round 100.3465,2 ...
mysql裡記錄貨幣用什麼字段型別好？
開發中，貨幣在資料庫中mysql常用decimal和numric型別表示，這兩種型別被mysql實現為同樣的型別。他們被用於儲存值，該值的準確精度是極其重要的值，例如與金錢有關的資料。當宣告乙個類是這些型別之一時，精度和規模的能被 並且通常是 指定 例如 salary decimal 9,2 在這個...