SUM - 爲什麼我使用sum和使用計算器時得到不同的總和）？

注意到在計算字段中的數量的奇怪。

Vaues表：

Vaues table

類型字段 - 浮動。

我做出選擇總和：

SELECT SUM(cost) as cost FROM Table

在結果我得到sum = 20.47497010231018;

sum result

我用計算器），我得到sum = 20,47497

請告訴我爲什麼我得到不同的結果？

來源

2013-02-19 Leo Loki

是的，基本上這是一個浮點常見問題。不要在mysql中使用float作爲一個類型，你有其他的數據類型可以做到這一點。 – Sebas 2013-02-19 21:34:10

@Sebas告訴我更多，請問什麼類型的字段可以取代浮點數？ – 2013-02-19 21:35:50

閱讀「每位計算機科學家應瞭解浮點運算的知識」的時間http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html – 2013-02-19 21:36:44

這裏，閱讀：http://floating-point-gui.de/

所以，問題是浮點數 - 在硬件十進制數的內部實現，而大多數語言和應用程序使用，不映射1對1號基數爲10，正如我們所使用的。基礎值以基數2表示，並且精度有限。一些可以使用十進制表示法中的幾位數字表示的數字實際上可能需要更多的本地格式數字 - 從而導致舍入誤差。

上面鏈接的文章詳細解釋了它。

來源

2013-02-19 21:37:56 jsbueno

感謝我的新知識） – 2013-02-19 21:50:30

這些差異不足以在大多數情況下擔心。

由於位數和浮點數如何以二進制形式存儲，因此浮點數由於與預期值略有差異而臭名昭着。例如，如演示here所示，0.1的十進制值的實際值爲double，值爲0.10000000149011612。關閉，但不是確切的。

我在某些需要絕對精確的緯度和經度數的應用程序中使用的一種技術是，它們將保持整數數據類型中的值等於浮點數乘以10的某個冪。例如，一個GeoPoint in the Google Maps API v1 on Android措施微觀程度。而不是象54.123428, 60.809234這樣的經緯度來精確保存值，他們會輸入：54123428, 60809234。爲了描述這一點，他們會調用變量latitudeE6和longitudeE6來表示它是真實的緯度或經度乘以1E6（10^6的科學記數法）。

來源

2013-02-19 21:39:21

也感謝我的新知識） – 2013-02-19 21:49:52

使用DECIMAL(16, 4)（例如）鍵入您的貨幣列，其中4是數字.

你將不得不雖然修剪尾隨零，因爲例如10會出現10.0000後的數字。然而這很容易完成。

來源

2013-02-19 22:15:39 Sebas

是的，我已經使用了十進制（10,4）。謝謝。 – 2013-02-19 23:20:40

SUM - 爲什麼我使用sum和使用計算器時得到不同的總和）？

回答

相關問題