Java™ 語言規范第 5 版向 java.lang.Math 和 java.lang.StrictMath 添加了 10 種新方法，Java 6 又添加了 10 種。這個共兩部分的系列文章的第 1 部分介紹了很有意義的新的數學方法。它提供了在還未出現計算機的時代中數學家比較熟悉的函數。在第 2 部分中，我主要關注這樣一些函數，它們的目的是操作浮點數，而不是抽象實數。

　　就像我在 第 1 部分中 提到的一樣，實數(比如 e 或 0.2)和它的計算機表示(比如 Java double)之間的區別是非常重要的。最理想的數字應該是無限精確的，然而 Java 表示的位數是固定的(float 為 32 位，double 為 64 位)。float 的最大值約為 3.4*1038。這個值還不足以表示某些東西，比如宇宙中的電子數目。

　　double 的最大值為 1.8*10308，幾乎能夠表示任何物理量。不過涉及到抽象數學量的計算時，可能超出這些值的范圍。例如，光是 171! (171 * 170 * 169 * 168 * ... * 1) 就超出了 double 最大值。float 只能表示 35! 以內的數字。非常小的數(值接近于 0 的數字)也會帶來麻煩，同時涉及到非常大的數和非常小的數的計算是非常危險的。

　　為了處理這個問題，浮點數學 IEEE 754 標準(參見 參考資料)添加了特殊值 Inf 和 NaN，它們分別表示無窮大(Infinity)和非數字(Not a Number)。IEEE 754 還定義了正 0 和負 0(在一般的數學中，0 是不分正負的，但在計算機數學中，它們可以是正的，也可以是負的)。這些值給傳統的原理帶來了混亂。例如，當使用 NaN 時，排中律就不成立了。x == y 或 x != y 都有可能是不正確的。當 x 或 y 為 NaN 時，這兩個式子都不成立。

　　除了數字大小問題外，精度是一個更加實際的問題。看看這個常見的循環，將 1.0 相加 10 次之后等到的結果不是 10，而是 9.99999999999998：

　　for (double x = 0.0; x <= 10.0; x += 0.1) {
　　System.err.println(x);
　　}

　　對于簡單的應用程序，您通常讓 java.text.DecimalFormat 將最終的輸出格式化為與其值最接近的整數，這樣就可以了。不過，在科學和工程應用方面(您不能確定計算的結果是否為整數)，則需要加倍小心。如果需要在特別大的數字之間執行減法以得到較小的數字，則需要萬分 小心。如果以特別小的數字作為除數，也需要加以注意。這些操作能夠將很小的錯誤變成大錯誤，并給現實應用帶來巨大的影響。由有限精度浮點數字引起的很小的舍入錯誤就會嚴重歪曲數學精度計算。

　　浮點數和雙精度數字的二進制表示

　　由 Java 實現的 IEEE 754 浮點數有 32 位。第一位是符號位，0 表示正，1 表示負。接下來的 8 位表示指數，其值的范圍是 -125 到 +127。最后的 23 位表示尾數(有時稱為有效數字)，其值的范圍是 0 到 33,554,431。綜合起來，浮點數是這樣表示的： sign * mantissa * 2 exponent 。

　　敏銳的讀者可能已經注意到這些數字有些不對勁。首先，表示指數的 8 位應該是從 -128 到 127，就像帶符號的字節一樣。但是這些指數的偏差是 126，即用不帶符號的值(0 到 255)減去 126 獲得真正的指數(現在是從 -126 到 128)。但是 128 和 -126 是特殊值。當指數都是 1 位(128)時，則表明這個數字是 Inf、-Inf 或 NaN。要確定具體情況，必須查看它的尾數。當指數都是 0 位(-126)時，則表明這個數字是不正常的(稍后將詳細介紹)，但是指數仍然是 -125。

　　尾數一般是一個 23 位的不帶符號的整數 — 它非常簡單。23 位可以容納 0 到 224-1，即 16,777,215。等一下，我剛才是不是說尾數的范圍是從 0 到 33,554,431?即 225-1。多出的一位是從哪里來的?

　　因此，可以通過指數表示第 1 位是什么。如果指數都是 0 位，則第 1 位為 0。否則第 1 位為 1。因為我們通常知道第 1 位是什么，所以沒有必要包含在數字中。您 “免費” 得到一個額外的位。是不是有些離奇?

　　尾數的第 1 位為 1 的浮點數是正常的。即尾數的值通常在 1 到 2 之間。尾數的第 1 位為 0 的浮點數是不正常的，盡管指數通常為 -125，但它通常能夠表示更小的數字。

　　雙精度數是以類似的方式編碼的，但是它使用 52 位的尾數和 11 位的指數來獲得更高的精度。雙精度數的指數的偏差是 1023。

　　尾數和指數

　　在 Java 6 中添加的兩個 getExponent() 方法在表示浮點數或雙精度數時返回無偏差 指數。對于浮點數，這個數字的范圍是 -125 到 +127，對于雙精度數，這個數字的范圍是 -1022 到 +1023(Inf 和 NaN 為 +128/+1024)。例如，清單 1 根據更常見的以 2 為底數的對數比較了 getExponent() 方法的結果：

　　清單 1. Math.log(x)/Math.log(2) 和 Math.getExponent()

　　public class ExponentTest {
　　public static void main(String[] args) {
　　System.out.println("x\tlg(x)\tMath.getExponent(x)");
　　for (int i = -255; i < 256; i++) {
　　double x = Math.pow(2, i);
　　System.out.println(
　　x + "\t" +
　　lg(x) + "\t" +
　　Math.getExponent(x));
　　}
　　}
　　public static double lg(double x) {
　　return Math.log(x)/Math.log(2);
　　}
　　}

　　對于使用舍入的一些值，Math.getExponent() 比一般的計算要準確一些：

　　x lg(x) Math.getExponent(x)
　　...
　　2.68435456E8 28.0 28
　　5.36870912E8 29.000000000000004 29
　　1.073741824E9 30.0 30
　　2.147483648E9 31.000000000000004 31
　　4.294967296E9 32.0 32

　　如果要執行大量此類計算，Math.getExponent() 會更快。不過需要注意，它僅適用于計算 2 的冪次方。例如，當改為 3 的冪次方時，結果如下：

　　x lg(x) Math.getExponent(x)
　　...
　　1.0 0.0 0
　　3.0 1.584962500721156 1
　　9.0 3.1699250014423126 3
　　27.0 4.754887502163469 4
　　81.0 6.339850002884625 6

　　getExponent() 不處理尾數，尾數由 Math.log() 處理。通過一些步驟，就可以找到尾數、取尾數的對數并將該值添加到指數，但這有些費勁。如果想要快速估計數量級(而不是精確值)，Math.getExponent() 是非常有用的。

　　與 Math.log() 不同，Math.getExponent() 從不返回 NaN 或 Inf。如果參數為 NaN 或 Inf，則對應的浮點數和雙精度數的結果分別是 128 和 1024。如果參數為 0，則對應的浮點數和雙精度數的結果分別是 -127 和 -1023。如果參數為負數，則數字的指數與該數字的絕對值的指數相同。例如，-8 的指數為 3，這與 8 的指數相同。

　　沒有對應的 getMantissa() 方法，但是使用簡單的數學知識就能構造一個：

　　public static double getMantissa(double x) {
　　int exponent = Math.getExponent(x);
　　return x / Math.pow(2, exponent);
　　}

　　盡管算法不是很明顯，但還是可以通過位屏蔽來查找尾數。要提取位，僅需計算 Double.doubleToLongBits(x) & 0x000FFFFFFFFFFFFFL。不過，隨后則需要考慮正常數字中多出的 1 位，然后再轉換回范圍在 1 到 2 之間的浮點數。

　　最小的精度單位

　　實數是非常密集的。任意兩個不同的實數中間都可以出現其他實數。但浮點數則不是這樣。對于浮點數和雙精度數，也存在下一個浮點數;連續的浮點數和雙精度數之間存在最小的有限距離。nextUp() 方法返回比第一個參數大的最近浮點數。例如，清單 2 打印出所有在 1.0 和 2.0 之間的浮點數：

　　清單 2. 計算浮點數數量

　　public class FloatCounter {
　　public static void main(String[] args) {
　　float x = 1.0F;
　　int numFloats = 0;
　　while (x <= 2.0) {
　　numFloats++;
　　System.out.println(x);
　　x = Math.nextUp(x);
　　}
　　System.out.println(numFloats);
　　}
　　}

　　結果是 1.0 和 2.0 之間包含 8,388,609 個浮點數;雖然很多，但還不至于是無窮多的實數。相鄰數字的距離為 0.0000001。這個距離稱為 ULP，它是最小精度單位(unit of least precision) 或最后位置單位(unit in the last place)的縮略。

　　如果需要向后查找小于指定數字的最近浮點數，則可以改用 nextAfter() 方法。第二個參數指定是否查找在第一個參數之上或之下的最近數字：

　　public static double nextAfter(float start, float direction)
　　public static double nextAfter(double start, double direction)

　　如果 direction 大于 start，則 nextAfter() 返回在 start 之上的下一個數字。如果 direction 小于 start，則 nextAfter() 返回在 start 之下的下一個數字。如果 direction 等于 start，則 nextAfter() 返回 start 本身。

　　這些方法在某些建模或圖形工具中是非常有用的。從數字上來說，您可能需要在 a 和 b 之間的 10,000 個位置上提取樣例值，但如果您具備的精度僅能識別 a 和 b 之間的 1,000 個獨立的點，那么有十分之九的工作是重復的。您可以只做十分之一的工作，但又獲得相同的結果。

　　當然，如果一定需要額外的精度，則可以選擇具有高精度的數據類型，比如 double 或 BigDecimal。例如，我曾經在 Mandelbrot 集合管理器看見過這種情況。在其中可以放大曲線圖，讓其落在最近的兩個雙精度數之間。Mandelbrot 集合在各個級別上都是非常細微和復雜的，但是 float 或 double 可以在失去區分相鄰點的能力之前達到這個細微的級別。

　　Math.ulp() 返回一個數字和距其最近的數字之間的距離。清單 3 列出了 2 的各種冪次方的 ULP：

　　清單 3. 浮點數 2 的冪次方的 ULP

　　public class UlpPrinter {
　　public static void main(String[] args) {
　　for (float x = 1.0f; x <= Float.MAX_VALUE; x *= 2.0f) {
　　System.out.println(Math.getExponent(x) + "\t" + x + "\t" + Math.ulp(x));
　　}
　　}
　　}

　　下面給出了一些輸出：

　　0 1.0 1.1920929E-7
　　1 2.0 2.3841858E-7
　　2 4.0 4.7683716E-7
　　3 8.0 9.536743E-7
　　4 16.0 1.9073486E-6
　　...
　　20 1048576.0 0.125
　　21 2097152.0 0.25
　　22 4194304.0 0.5
　　23 8388608.0 1.0
　　24 1.6777216E7 2.0
　　25 3.3554432E7 4.0
　　...
　　125 4.2535296E37 5.0706024E30
　　126 8.507059E37 1.0141205E31
　　127 1.7014118E38 2.028241E31

　　可以看到，對于比較小的 2 的冪次方，浮點數是非常精確的。但是在許多應用程序中，在數值約為 220 時，這一精度將出現問題。在接近浮點數的最大極限時，相鄰的值將被 千的七乘方(sextillions)隔開(事實上可能更大一點，但我找不到詞匯來表達)。

　　如清單 3 所示，ULP 的大小并不是固定的。隨著數字變大，它們之間的浮點數就會越來越少。例如，10,000 和 10,001 之間只有 1,025 個浮點數;它們的距離是 0.001。在 1,000,000 和 1,000,001 之間僅有 17 個浮點數，它們的距離是 0.05。精度與數量級成反比關系。對于浮點數 10,000,000，ULP 的精確度變為 1.0，超過這個數之后，將有多個整數值映射到同一個浮點數。對于雙精度數，只有達到 4.5E15 時才會出現這種情況，但這也是個問題。

　　浮點數的有限精度會導致一個難以預料的結果：超過某個點時，x+1 == x 便是真的。例如，下面這個簡單的循環實際上是無限的：

　　for (float x = 16777213f; x < 16777218f; x += 1.0f) {
　　System.out.println(x);
　　}

　　實際上，這個循環將在一個固定的點上停下來，準確的數字是 16,777,216。這個數字等于 224，在這個點上，ULP 比增量大。

　　Math.ulp() 為測試提供一個實用的用途。很明顯，我們一般不會比較兩個浮點數是否完全相等。相反，我們檢查它們是否在一定的容錯范圍內相等。例如，在 JUnit 中，像以下這樣比較預期的實際浮點值：

　　assertEquals(expectedValue, actualValue, 0.02);

　　這表明實際值與預期值的偏差在 0.02 之內。但是，0.02 是合理的容錯范圍嗎?如果預期值是 10.5 或 -107.82，則 0.02 是完全可以接受的。但當預期值為幾十億時，0.02 則與 0 沒有什么區別。通常，就 ULP 進行測試時考慮的是相對錯誤。一般選擇的容錯范圍在 1 至 10 ULP 之間，具體情況取決于計算所需的精度。例如，下面指定實際結果必須在真實值的 5 個 ULP 之內：

　　assertEquals(expectedValue, actualValue, 5*Math.ulp(expectedValue));

　　根據期望值不同，這個值可以是萬億分之一，也可以是數百萬。

　　scalb

　　Math.scalb(x, y) 用 2y 乘以 x，scalb 是 “scale binary(二進法)&rdquo; 的縮寫。

　　public static double scalb(float f, int scaleFactor)
　　public static double scalb(double d, int scaleFactor)

　　例如，Math.scalb(3, 4) 返回 3 * 24，即 3*16，結果是 48.0。也可以使用 Math.scalb() 來實現 getMantissa()：

　　public static double getMantissa(double x) {
　　int exponent = Math.getExponent(x);
　　return x / Math.scalb(1.0, exponent);
　　}

　　Math.scalb() 和 x*Math.pow(2, scaleFactor) 的區別是什么?實際上，最終的結果是一樣的。任何輸入返回的值都是完全一樣的。不過，性能方面則存在差別。Math.pow() 的性能是非常糟糕的。它必須能夠真正處理一些非常少見的情況，比如對 3.14 采用冪 -0.078。對于小的整數冪，比如 2 和 3(或以 2 為基數，這比較特殊)，通常會選擇完全錯誤的算法。

　　我擔心這會對總體性能產生影響。一些編譯器和 VM 的智能程度比較高。一些優化器會將 x*Math.pow(2, y) 識別為特殊情況并將其轉換為 Math.scalb(x, y) 或類似的東西。因此性能上的影響體現不出來。不過，我敢保證有些 VM 是沒有這么智能的。例如，使用 Apple 的 Java 6 VM 進行測試時，Math.scalb() 幾乎總是比 x*Math.pow(2, y) 快兩個數量級。當然，這通常不會造成影響。但是在特殊情況下，比如執行數百萬次求冪運算時，則需要考慮能否轉換它們以使用 Math.scalb()。

　　Copysign

　　Math.copySign() 方法將第一個參數的標記設置為第二個參數的標記。最簡單的實現如清單 4 所示：

　　清單 4. 可能實現的 copysign 算法

　　public static double copySign(double magnitude, double sign) {
　　if (magnitude == 0.0) return 0.0;
　　else if (sign < 0) {
　　if (magnitude < 0) return magnitude;
　　else return -magnitude;
　　}
　　else if (sign > 0) {
　　if (magnitude < 0) return -magnitude;
　　else return magnitude;
　　}
　　return magnitude;
　　}

　　不過，真正的實現如清單 5 所示：

　　清單 5. 來自 sun.misc.FpUtils 的真正算法

　　public static double rawCopySign(double magnitude, double sign) {
　　return Double.longBitsToDouble((Double.doubleToRawLongBits(sign) &
　　(DoubleConsts.SIGN_BIT_MASK)) |
　　(Double.doubleToRawLongBits(magnitude) &
　　(DoubleConsts.EXP_BIT_MASK |
　　DoubleConsts.SIGNIF_BIT_MASK)));
　　}

　　仔細觀察這些位就會看到，NaN 標記被視為正的。嚴格來說，Math.copySign() 并不對此提供保證，而是由 StrictMath.copySign() 負責，但在現實中，它們都調用相同的位處理代碼。

　　清單 5 可能會比清單 4 快一些，但它的主要目的是正確處理負 0。Math.copySign(10, -0.0) 返回 -10，而 Math.copySign(10, 0.0) 返回 10.0。清單 4 中最簡單形式的算法在兩種情況中都返回 10.0。當執行敏感的操作時，比如用極小的負雙精度數除以極大的正雙精度數，就可能出現負 0。例如，-1.0E-147/2.1E189 返回負 0，而 1.0E-147/2.1E189 返回正 0。不過，使用 == 比較這兩個值時，它們是相等的。因此，如果要區分它們，必須使用 Math.copySign(10, -0.0) 或 Math.signum()(調用 Math.copySign(10, -0.0))來執行比較。

　　對數和指數

　　指數函數是一個很好的例子，它表明處理有限精度浮點數(而不是無限精度實數)時是需要非常小心的。在很多等式中都出現 e x(Math.exp())。例如，它可用于定義 cosh 函數，這已經在 第 1 部分中 討論：

　　cosh(x) = (e x + e -x)/2

　　不過，對于負值的 x，一般是 -4 以下的數字，用于計算 Math.exp() 的算法表現很差，并且容易出現舍入錯誤。使用另一個算法計算 e x - 1 會更加精確，然后在最終結果上加 1。Math.expm1() 能夠實現這個不同的算法(m1 表示 “減 1”)。例如，清單 6 給出的 cosh 函數根據 x 的大小在兩個算法之間進行切換：

　　清單 6. cosh 函數

　　public static double cosh(double x) {
　　if (x < 0) x = -x;
　　double term1 = Math.exp(x);
　　double term2 = Math.expm1(-x) + 1;
　　return (term1 + term2)/2;
　　}

　　這個例子有些呆板，因為在 Math.exp() 與 Math.expm1() + 1 之間的差別很明顯的情況下，常常使用 e x，而不是 e -x。不過，Math.expm1() 在帶有多種利率的金融計算中是非常實用的，比如短期國庫券的日利率。

　　Math.log1p() 與 Math.expm1() 剛好相反，就像 Math.log() 與 Math.exp() 的關系一樣。它計算 1 的對數和參數(1p 表示 “加 1”)。在值接近 1 的數字中使用這個函數。例如，應該使用它計算 Math.log1p(0.0002)，而不是 Math.log(1.0002)。

　　現在舉一個例子，假設您需要知道在日利率為 0.03 的情況下，需要多少天投資才能使 $1,000 增長到 $1,100。清單 7 完成了這個計算任務：

　　清單 7. 計算從當前投資額增長到未來特定值所需的時間

　　public static double calculateNumberOfPeriods(
　　double presentValue, double futureValue, double rate) {
　　return (Math.log(futureValue) - Math.log(presentValue))/Math.log1p(rate);
　　}

　　在這個例子中，1p 的含義是很容易理解的，因為在計算類似數據的一般公式中通常出現 1+r。換句話說，盡管投資方很希望獲得初始投資成本的 (1+r) n ，貸方通常將利率作為附加的百分比(+r 部分)。實際上，以 3% 的利率貸款的投資者如果僅能取回投資成本的 3% 的話，那就非常糟糕了。

　　結束語

　　浮點數并不是實數。它們的數量是有限的。它們能夠表示最大和最小的值。更值得注意的是，它們的精度雖然很高，但范圍很窄，并且容易出現舍入錯誤。相反，浮點數和雙精度數處理整數時獲得的精度遠比整型數和長型數差。您必須仔細考慮這些限制，尤其是在科研和工程應用方面，以生產出健壯、可靠的代碼。對于財務應用程序(尤其是需要精確到最后一位的會計應用程序)，處理浮點數和雙精度數時也需要格外小心。

　　java.lang.Math 和 java.lang.StrictMath 類經過了精心設計，可以解決這些問題。適當地使用這些類及其包含的方法能夠改善程序。本文特別展示了良好的浮點算法有多么巧妙!最好使用專家提供的算法，而不是自己獨創算法。如果適合使用 java.lang.Math 和 java.lang.StrictMath 中提供的方法，最好繼續使用。它們通常是最佳的選擇。