SQL SERVER給出了相同的數學計算

查詢：

SELECT 
(ISNULL(TRY_CONVERT(NUMERIC(38, 14), '123456789.34554563453524'), 0) 
* 
ISNULL(try_convert(NUMERIC(38, 14), '456789876.34556345345353'), 0))/100.0

結果：

563938115391720.660302

第二步

上述查詢我甲肝è修改爲：

SELECT (123456789.34554563453524 * 456789876.34556345345353)/100.0

但結果是：

563938115391720.660302253145411988

這裏，第一步查詢結果已在某一點截斷小數。

如何重新編寫它以獲取確切的編號（563938115391720.660302253145411988）我得到了Step2查詢。

來源

2017-07-26 thing guy

我不會標記爲重複，但我認爲[這個SO問題]（https://stackoverflow.com/questions/126401/sql-server-2005-numeric-精確度損失）可能會解釋您的觀察結果。只有最多48位數的精度可用，並且您的產品可能會超出此限制。使用浮點舍入錯誤是所有編程語言中已知的問題。 –

可能重複[爲什麼精度在與其他數字相乘時減少]（https://stackoverflow.com/questions/14313598/why-precision-is-decreasing-when-multiply-sum-to-other-number） – Hybris95

你實際需要的精度接近於零。如果你把它放下，它可能實際上是零。請注意，SQL Server沒有任意精度的數據類型，所以無論你做什麼，即使*這個*恰好是可能的，總會有*計算失去精度。如果你只是想解釋差異，那很好，但不要誤導你自己認爲你在所有情況下都能得到確切的結果。 –

這與小數精度所預測的完全相同。見T-SQL Decimal Division Accuracy

Numbers with decimal points are interpreted as NUMERIC in SQL Server to the exact precision shown。不漂浮。在這種情況下decimal (23, 14)

在第一個例子，他們是decimal (38, 14)

同樣的結果使用相同精度明確的轉換時，相同的數據類型

SELECT 
(ISNULL(TRY_CONVERT(NUMERIC(23, 14), '123456789.34554563453524'), 0) 
* 
ISNULL(try_convert(NUMERIC(23, 14), '456789876.34556345345353'), 0))/100.0 

563938115391720.660302253145411988

注意，100.0在這個decimal(4,1)案例太

最後的話：this is long division that used to be taught at school經過一些精度變化由於在乘法的差異38/23

來源

2017-07-26 13:50:07 gbn

SQL SERVER給出了相同的數學計算

回答

相關問題