乙個關於o(n*logn)耗時下限的理論
這裡有乙個疑問：是不是o(n*logn)是排序演算法時間代價最好的極限呢？
當然不是，但是如果排序演算法是基於"關鍵字比較"操作的，那麼在最壞情況下確實能夠到達的最好效果就是o(n*logn)了。 在最好情況下就沒必要說了，如果待排序列基本有序，那麼直接插入排序的比較次數都非常的少。
下面我們來證明一下(注意：這些排序演算法的基本操作就是比較，其時間主要消耗在比較次數上)。現在有三個關鍵字k1、k2、k3。那麼下圖給出了這三個關鍵字記錄在任何可能的排序狀態下的判定樹，樹中的內部結點都進行了一次必要的比較。
三個關鍵字的待排序列只有上面葉子結點所描述的6中排序狀態。而判定樹上的每一次比較都是必須的。因此、這個判定樹足以描述通過「比較」進行的排序過程。並且，每乙個待排序列經過排序達到有序序列所需要進行的"比較"次數，恰為從樹根到葉子結點的路徑長度。因此3個關鍵字的比較最少需要2次，最多需要3次。
擴充套件一下，有n個關鍵字序列。那麼就有n!種排序狀態，自然判定樹就有n!個葉子節點。我們知道，二叉樹的樹高為h的情況下，葉子結點最多有2^(h-1)個。而現在又n!個葉子結點，那麼樹高至少為log(n!)+1。也就是說，描述n個記錄排序的判定樹必存在一條長度為[log(n!)+1]的路徑。根據斯特林公式(n!的高精度近似求解公式)： log(n!)=n*log(n)。因此，最少的比較次數也就是n*log(n)了。
基於比較操作的排序演算法的時間複雜度下限確實是o(n*logn)。那麼如果不比較呢，耗時代價會不會進一步減少。當然，關於這方面的排序演算法，請見《桶排序 》、《基數排序 》。
乙個關於 的謎題
乙個關於 的謎題 今天在看書過程中發現了乙個問題，還挺有意思的，分享給大家。下面兩個 python 表示式會產生什麼結果？t 1,2,3,4 t 2 5,6 給四個備選答案 t變成 1,2,3,4,5,6 因為 tuple 不支援對它的元素賦值，所以會丟擲typeerror異常。以上兩個都不是。以上...
關於乙個加法優化的乙個地方
include include include base.h int main int argc,char argv,char envp 下面是彙編 01291000 55 push ebp 01291001 8bec mov ebp,esp 01291003 56 push esi 0129100...
乙個關於兔子的故事
前段時間和乙個朋友聊天，酒席間向我抱怨他那段時間的鬱悶 專案經理從客戶那裡拿來乙個需求，實際上就是乙個ppt描述，我這個朋友拿過來看後剛開始不覺得什麼，乙個通常的 系統又能複雜的了哪去，但是越往後做就越發覺得裡面的問題。在ppt描述中很多地方描述的都有矛盾。比如論壇，沒錯，小公司，尤其是對於我們這樣...