大數定理

空間上統治宇宙的是萬有引力（遠遠超過電磁力、強力和弱力），時間上統治宇宙的則是大數定理。

引子

這兩天為了測試定時重新整理功能，編寫了一小段代碼，每秒產生一個隨機數，如果隨機數大於0.999，就彈出通知框，類比定時重新整理資料庫查看輕負荷事件的程式。

沒想到，這段代碼似乎很愛表現，本來按理說每小時應該產生3.6個，但實際上經常剛運行1分鐘就彈出來了，還經常連續跳。

這咋回事呢？難道程式中潛伏著一個智慧生物？

於是修改了代碼，昨天測試了一晚上，結果如下：

Mon Feb 20 22:08:39 UTC+0800 2012: start!
Mon Feb 20 22:15:28 UTC+0800 2012:0.9996775767156192
Mon Feb 20 22:26:45 UTC+0800 2012:0.9993164486570707
Mon Feb 20 22:39:41 UTC+0800 2012:0.9991614030679405
Mon Feb 20 22:52:17 UTC+0800 2012:0.9993802612934692
Mon Feb 20 22:57:18 UTC+0800 2012:0.9992101100747147
Mon Feb 20 23:49:47 UTC+0800 2012:0.9994722976553704
Tue Feb 21 00:32:22 UTC+0800 2012:0.9993711621307835
Tue Feb 21 00:44:49 UTC+0800 2012:0.9997594440820359
Tue Feb 21 00:59:11 UTC+0800 2012:0.9990013300168501
Tue Feb 21 01:01:05 UTC+0800 2012:0.9995229600977049
Tue Feb 21 01:06:59 UTC+0800 2012:0.999817806874123
Tue Feb 21 01:43:27 UTC+0800 2012:0.9991565107679405
Tue Feb 21 01:52:45 UTC+0800 2012:0.9994827659434577
Tue Feb 21 01:56:38 UTC+0800 2012:0.9994192574575108
Tue Feb 21 02:01:23 UTC+0800 2012:0.9992681562004064
Tue Feb 21 03:19:18 UTC+0800 2012:0.9996777448874157
Tue Feb 21 03:22:19 UTC+0800 2012:0.9996629119550424
Tue Feb 21 03:24:53 UTC+0800 2012:0.9992419533798492
Tue Feb 21 03:28:41 UTC+0800 2012:0.999059605995319
Tue Feb 21 03:32:00 UTC+0800 2012:0.9990270301026873
Tue Feb 21 04:12:00 UTC+0800 2012:0.9993799632901426
Tue Feb 21 04:17:32 UTC+0800 2012:0.9994741351743861
Tue Feb 21 04:26:54 UTC+0800 2012:0.9993270924804556
Tue Feb 21 04:30:12 UTC+0800 2012:0.9994040516631909
Tue Feb 21 04:52:36 UTC+0800 2012:0.9995258410445615
Tue Feb 21 05:39:31 UTC+0800 2012:0.999388751953785
Tue Feb 21 05:43:27 UTC+0800 2012:0.9999265437402556
Tue Feb 21 05:50:03 UTC+0800 2012:0.9997207089599427
Tue Feb 21 05:56:21 UTC+0800 2012:0.9998498736376766
Tue Feb 21 06:16:08 UTC+0800 2012:0.9999746575172905
Tue Feb 21 06:23:04 UTC+0800 2012:0.9997999256014357
Tue Feb 21 06:57:41 UTC+0800 2012:0.999702550543468
Tue Feb 21 07:29:17 UTC+0800 2012:0.9996094465673534
Tue Feb 21 07:29:53 UTC+0800 2012:0.9992936536360875
Tue Feb 21 07:31:19 UTC+0800 2012:0.9994029914395262
Tue Feb 21 07:33:24 UTC+0800 2012:0.9999636418665332
Tue Feb 21 07:45:48 UTC+0800 2012:0.9990307948678938
現在時間是08:40（有接近一小時沒彈出來啦！）

在10.5小時時間裡，彈出了37個，幾乎完全等於3.6個/小時。如果觀察局部，在最後7：29～7：33連續彈出了4個，而在最後的一小時，則一個沒彈。

但局部的偶然事件並不會影響大量統計的結果，這就叫大數定理，就是當數目多到一定程度後，統計規律將佔據統治地位，結果將趨向於事件的數學期望。

一些偶發的連續彈出，在心理上造成了“愛表現的智慧生物”的錯覺。

代碼如下有空可以玩玩：

<script type = "text/javascript">    $(document).ready( function () {        $("#log").append(Date().toString() + ": start!<br>")    });    $(function tick() {        var value = Math.random();        $("h1").html(value.toString());        if (value > 0.999) {            $("#log").append(Date().toString() + ":" + value + "<br>")        };        setTimeout(tick, 1000);    });</script><p id = "log"></p>

 

用途

這東西有什麼用？在http://blog.csdn.net/cheny_com/article/details/7001982中提到過，當年牛頓時代磨製望遠鏡，就是利用了大數定理，用純手工把鏡面精度加工到1/8光波長。

在軟體估算中，大數定理也非常有用。如果同樣一個項目，如果分成10個大塊來分別估算，就不如分成20個來得準確。儘管事後會發現無論10個還是20個，每個任務都一樣估不準，但是把20個任務加在一起，剩餘誤差比10個的時候要小很多。

這就是為什麼要做WBS分解，然後估算任務的原因。對于敏捷開發的估算，如果能把大型的（超過5人天的）任務分解一下，再行估算，然後相加，誤差會小很多。

但是為什麼呢？有什麼數學原理在起作用？

這就要講到隨時變數相加時的“卷積”運算。

比如拋硬幣，拋1次，正反的機率分別0.5，拋兩次，則不會說兩正兩反的機率分別0.5，而是中間插進來個一正一反，而且還佔據了大頭，成為0.25-0.5-0.25的格局。

如果用整數表示，可以看到下面的三角形：

01次：1 1

02次：1 2 1

03次：1 3 3 1

04次：1 4 6 4 1

05次：1 5 10 10 5 1

06次：1 6 15 20 15 6 1

07次：1 7 21 35 35 21 7 1

...

01次時的11意思是說1正+1反

02次時的121意思是說1/4個兩正+2/4個1正1反+1/4個兩反，4是所有數字之和

03次的1331=1/8個3正+3/8個2正1反+3/8個1正2反+1/8個三反，8是所有數字之和

……這個三角形叫做楊輝三角形，還是中國人發明的，可以參考最後的連結。

隨著次數的增多，極端情況越來越少，而中央鼓起來一個大包。如果連續拋7次硬幣，你可以只押4正3反或3正4反，就能有70/128的勝率。

隨機變數在相加時，中間鼓起來的現象叫做“卷積”。（額……只能先這麼說了）

下面這些事情都和大數定理相關：

1. 分得細估得准（永遠不要追求單個任務估算得很准，硬幣怎麼拋，都是一正一反，多拋幾次就得了）

2. 用的多缺陷少（所以要趕緊作出可運行軟體跑著）

3. 看的多缺陷少（所以要代碼審查）

4. ……等等

楊輝三角型：http://baike.baidu.com/view/298289.htm

大數定理的百度詞條不對。