我已經在C++中使用了一些圖像處理代碼，它可以計算梯度並使用hough變換算法在其中找到直線。該程序用浮點數進行大部分計算。在兩臺計算機上使用浮點數的相同代碼給出了兩個不同的結果
當我在兩臺不同計算機上的相同映像上運行此代碼時，一臺運行最新Fedora的Pentium IV，另一臺Core i5最新Ubuntu，都是32位，結果稍有不同。例如。在一臺機器上的一些變量和另一臺機器上的1.3457f上，我經過了一些冗長的計算1.3456f。這是預期的行爲還是應該在我的程序中搜索錯誤？
我的第一個猜測是，我正在訪問一些未初始化的或超出界限的內存，但我通過valgrind運行了該程序，並且找不到任何錯誤，並且在同一臺計算機上也多次運行相同的結果。
這並不罕見，它將取決於您的編譯器，優化設置，數學庫，CPU以及當然您正在使用的算法的數值穩定性。
你需要對精度要求有一個好的想法，如果你不符合這些要求，那麼你可能需要看看你的算法，例如考慮在需要時使用double而不是float。
是的。我會補充說，使用-ffloat-store標誌編譯（在GCC中）可能有助於在兩個平臺中獲得相同的結果。 – 2010-09-30 11:17:31
要麼這是浮動的內部表示之間的差異，會產生稍微不同的結果，或者它可能是浮動打印到屏幕上的方式的差異？我懷疑這是你的錯......
有關爲什麼給定的源代碼可能不會在不同計算機上產生相同輸出的背景，請參閱What Every Computer Scientist Should Know About Floating-Point Arithmetic。我懷疑這是由於你的代碼有任何缺陷，除非它以非確定性的方式進行聚合，例如。通過集中核對來自多個線程的計算結果。
浮點行爲通常可以根據編譯器選項進行調整，即使是不同CPU的級別也是如此。檢查你的編譯器文檔，看看你是否可以減少或消除這種差異。在Visual C++上（例如）這是完成via /fp。
它是由於一個稱爲機器epsilon的現象嗎？
http://en.wikipedia.org/wiki/Machine_epsilon
flaiting-point number有限制。浮點數不能精確地表示所有實數並且浮點運算不能精確地表示真正的算術運算的事實會導致許多令人驚訝的情況。這與計算機通常表示數字的有限精度有關。
基本上，根據大量因素，相同的C++指令可以編譯爲不同的機器指令（即使在同一CPU上，當然也可以在不同的CPU上），並且相同的機器指令可以導致不同的低級CPU取決於許多因素的行動。從理論上講，這些應該在語義上是等價的，但是對於浮點數來說，有些情況並非如此。
閱讀"The pitfalls of verifying floating-point computations" by David Monniaux瞭解詳情。
我也會說這很常見，可能不是你的錯。
我在過去花了很多時間試圖找出同樣的問題。
我會建議使用decimal而不是float和double只要你的號碼不涉及科學計算，但像價格，數量，匯率等
一個好主意，例如一個數據庫，但並不真正適用於內部計算，因爲通常沒有硬件支持小數（儘管我似乎記得一些大型機擁有它）。 – sleske 2010-10-01 02:34:50
值這是完全正常的，很遺憾。
有些庫可以在任何地方產生相同的結果 - 例如參見http://www.mpfr.org/。但是性能成本很高，除非完全相同的結果是最重要的標準，否則可能不值得。
我實際上編寫了一個在整數單元中實現浮點數學運算的閉源數據庫，目的是讓浮點數在不同編譯器的多個平臺（Intel，AMD，PowerPC）上提供相同的結果。我們有一個應用程序，如果浮點結果不一樣，它根本無法運行。不過，這是一個相當大的挑戰。如果我們能夠再次做到這一點，我們就會設計出原始的應用程序，但當時它的代碼太多，無法重寫。
請注意，MPFR提供的不僅僅是相同的結果，它還針對在結果類型精度範圍內的正確答案。 – MSalters 2010-10-01 08:39:45
移動到加倍（如果要節省空間，使用浮點只是常見的）。你可能仍然會有一些微小的變化，但相對的幅度會更小。 – 2010-09-30 13:41:28
這是值得仔細檢查你的代碼，以確保你使用盡可能穩定的算法。例如，如果添加兩個總和接近於零的數字（例如，1.000012 +（-1.000006）），則結果將丟失其大部分有效數字。通常通過重新構造數學表達式或僅以更高的精度進行某些中間計算來獲得更好的答案。在獲得應有精度的答案時，您將保留使用浮點數而不是雙精度值的大部分性能優勢。 – 2010-09-30 16:16:46