Excel與C＃號碼的差異

任何人都可以闡明爲什麼我可能會看到非常小（10^-08）數字差異，當在Excel中使用完全相同的數字與C＃？Excel與C＃號碼的差異

我有一個公式，並使用相同的輸入。在Excel中，我得到一個數字 - 在C＃中，我得到另一個數字。差別很小。

我在C＃中使用雙打，並做分工。我曾嘗試使用小數沒有太大的差異

編輯：這是駕駛我堅果 - 我花了整整一個早上在這 - 任何想法？

來源

2010-02-11 Jack Kada

我想一個類似的問題已被問以前... – 2010-02-11 11:07:07

任何想法在哪裏？ – 2010-02-11 11:57:41

區別在於c＃和excel中的MidPoint舍入規則不同。

嘗試Math.Round(someNumber,precision,MidpointRounding.AwayFromZero);

來源

2010-02-11 13:35:50

隨着差（10^-08，你的狀態）的這種小幅度的，我懷疑是中間計算是造成問題的原因。請注意，雙精度值爲64位，但寄存器可以使用80位精度。因此，如果您有一個代碼序列，編譯器會將所有中間計算保留在寄存器上，那麼實際上，如果在代碼中的不同點上進行相同的計算，實際上會獲得更高的精度，從而迫使中間結果保持在64位存儲位置。

如果在Excel單元格中存儲值作爲計算的一部分，這也會導致將中間計算截斷爲64位精度。（a）Excel計算（是工作表公式還是您對單元格值進行編程式分配？）和（b）您正在編制的C＃計算結果。如果你這樣做，那麼我們應該能夠更精確地幫助你。但是，根據您迄今爲止提供的信息，我們只能做出廣泛的猜測。

- Mike

來源

2010-02-11 14:06:31

此主題促使我堅果之前以及=）。

幾年前，我發現Excel的工作表=ROUND()函數產生了與VBA的ROUND()函數不同的結果。我還發現VBA和MySQL版本4.x（不記得確切的版本;在5.x之前）使用完全相同的算法來捨去浮點數類型。他們似乎在使用「銀行家四捨五入」的有缺陷的版本。 MySQL最終在未來的版本中改變了舍入，但有人指出，VBA和MySQL 4.x實現的方式之間的相似之處可能在於它們都依賴於C編程語言（可能用於創建VBA和MySQL）實現了Round。

VBA和MySQL 4.x都簡單地實現了C用於實現舍入的內容。然而，許多當代編程語言由於各種原因選擇了自己的舍入方法;有時它會符合IEEE規範，有時會匹配他們認爲用戶期望的內容。在VBA和MySQL 4.x的情況下，用戶從未期望銀行家舍入的缺陷版本（因此您的沮喪），所以未來的語言實現了舍入的新版本或提供的替代品（例如C＃中的decimal類型），所以用戶將能夠產生預期的價值並對整個過程有更多的控制權。

你可以嘗試參考看這篇文章的主題作進一步闡發VBA的舍入：http://www.vb-helper.com/howto_round_to_specified_digits.html

來源

2010-02-11 14:50:55

你確定你看到Excel中的整個號碼？

格式化爲「常規」的數字將以〜12位數的精度顯示（如果列的寬度不夠12位數字，則顯示更少）。例如，如果將公式「= PI（）」放入具有「常規」格式（Excel中的默認值）的單元格中並將列寬足夠寬，則會看到3.141592654。請注意，如果列不夠寬，您將看到更少的精度數字。

現在，格式化自定義數字格式爲「0.00000000000000000」的單元格，您將看到3.14159265358979000（如果列足夠寬）。

請注意，Excel實際上在內部存儲具有超過15位精度的= PI（）的值。你可以通過在單元格中輸入「=（PI（） - 3.14159265358979）」來看到這一點 - 確保在公式中包含括號。

現在，只是爲了好玩，在單元格中輸入「= PI（） - 3.14159265358979」，你會看到你得到零。在某些情況下，例如在結果幾乎爲零的地方添加或減去，Excel實際上會將結果轉換爲0.0（如果您不知道發生這種情況，這可能會使您瘋狂）。

來源

2010-02-11 16:43:40

Excel與C＃號碼的差異

回答

相關問題