2010-08-02 66 views

回答

16

科學價值觀往往是「自然」的值(長度,質量,時間等),其中有不精確的自然度入手 - 但是,你可能想非常,非常大或非常,非常小的數字。對於這些值,double通常是一個好主意。它速度很快(幾乎可以在任何地方使用硬件支持),可以上下擴展到巨大/微小的值,如果你不關心精確的decimal值,通常可以正常工作。

decimal對於「人造」數字來說是一個很好的類型,其中有一個確切的數值,幾乎總是自然地表示爲小數 - 這是貨幣的典型例子。然而,在存儲方面(每個值8個字節而不是4個),它的價格是double的兩倍,具有更小的範圍(由於指數範圍更有限),並且由於缺少硬件支持而顯着更慢。

如果存儲是一個問題,我個人只會使用float - 當您只有7個重要的小數位時,不準確的速度多快會令人驚訝。

最終,從評論「熊會吃了你」所暗示的,它取決於你在談論什麼樣的價值觀 - 當然,你打算跟他們做什麼。沒有任何進一步的信息,我懷疑double是一個很好的起點 - 但你應該根據個人情況做出真正的決定。

+1

我喜歡「自然」與「人造」的區別。 – 2010-08-02 14:49:10

5

Double似乎是這樣操作的最可靠的數據類型。即使WPF廣泛使用它。

8

嗯,當然,術語「科學計算」是一個有點模糊,但總的來說,它的double

float在很大程度上是用於與期望的32位浮點數庫的兼容性。 floatdouble操作(如加法)的性能完全相同,所以新代碼應始終使用double,因爲它具有更高的精度。

但是,x86 JITter絕不會內聯使用或返回float的函數,因此在方法中使用float實際上可能會更慢。再一次,這是爲了兼容性:如果內聯,執行引擎會跳過轉換步驟,降低其精度,因此,如果JITter內聯這些函數,它可能會不經意地更改某些計算的結果。最後,還有decimal。只要重要的是有一定的小數位數就可以使用它。定型用例是貨幣操作,但它當然支持2位以上的小數位 - 它實際上是一個80位的數據。

如果即使64位double的準確度還不夠,請考慮使用外部庫來獲取任意精度數字,但當然如果您的特定科學用例特別要求它,那麼您只需要這樣做。

+2

關於性能的好處。 – 2010-08-02 14:42:48

+0

內聯索賠的來源?在3.5 SP1中修復了一個錯誤,它不允許JIT內聯具有值類型參數的函數,但我想不出任何其他問題。 – JulianR 2010-08-02 16:06:19

+0

找不到源代碼,但我提到了這個問題。 CLR評估棧僅使用64位值作爲浮點數。每次將32位浮點數傳遞到方法中,或者方法返回32位浮點數時,評估堆棧中的值都會專門轉換爲32位浮點數以保持其精度不足。 – Timwi 2010-08-02 16:26:08

2

注意小數昂貴得多比花車/雙打使用(除了什麼喬恩斯基特和Timwi寫)。

0

我會建議雙倍,除非你需要的值是確切的;十進制用於需要這種精確度的財務計算。科學計算可以容忍小錯誤,因爲無論如何您都無法準確測量1米。如果存儲是一個問題(即巨大的矩陣),浮點只會有幫助。