"二分查找可以解決（預排序數組的查找）問題：只要數組中包含T（即要查找的值），那么通過不斷縮小包含T的范圍，最終就可以找到它。一開始，范圍覆蓋整個數組。將數組的中間項與T進行比較，可以排除一半元素，范圍縮小一半。就這樣反復比較，反復縮小范圍，最終就會在數組中找到T，或者確定原以為T所在的范圍實際為空。對于包含N個元素的表，整個查找過程大約要經過log(2)N次比較。
多數程序員都覺得只要理解了上面的描述，寫出代碼就不難了；但事實并非如此。如果你不認同這一點，最好的辦法就是放下書本，自己動手寫一寫。試試吧。
我在貝爾實驗室和IBM的時候都出過這道考題。那些專業的程序員有幾個小時的時間，可以用他們選擇的語言把上面的描述寫出來；寫出高級偽代碼也可以。考試結束后，差不多所有程序員都認為自己寫出了正確的程序。于是，我們花了半個鐘頭來看他們編寫的代碼經過測試用例驗證的結果。幾次課，一百多人的結果相差無幾：90%的程序員寫的程序中有bug（我并不認為沒有bug的代碼就正確）。
我很驚訝：在足夠的時間內，只有大約10%的專業程序員可以把這個小程序寫對。但寫不對這個小程序的還不止這些人：高德納在《計算機程序設計的藝術 第3卷 排序和查找》第6.2.1節的“歷史與參考文獻”部分指出，雖然早在1946年就有人將二分查找的方法公諸于世，但直到1962年才有人寫出沒有bug的二分查找程序。 "——喬恩·本特利，《編程珠璣（第1版）》第35-36頁。
于是我嘗試了一下，也不能說不正確，但是確實干得不夠漂亮（或者說自作聰明）。
下面是我用Ruby寫的：
class Array
# Ord a -> [a] -> a -> Maybe Int
def ibsearch(x)
return nil if self.empty?
low, heigh = 0, self.length - 1
while low < heigh
mid = (low + heigh) / 2
x <= self[mid]? heigh = mid : low = mid + 1
end
x == self[low]? low : nil
end
end
這是測試用例：
class TestBsearch < Test::Unit::TestCase
def test_bsearch
count = 100
count.times do
xs = Array.new(SecureRandom.random_number(count))
xs.map! { |e| SecureRandom.random_number(count) }
xs.sort!
x = xs.sample
index = xs.index(x)
assert_equal(index,xs.ibsearch(x))
end
end
def test_bsearch_not_exit
count = 100
count.times do
xs = Array.new(SecureRandom.random_number(count))
xs.map! { |e| SecureRandom.random_number(count) }
xs.sort!
x = count + 1
assert_equal(nil,xs.ibsearch(x))
end
end
end
測試都能通過，聰明的你，能看出哪里不夠漂亮么？
下面是維基百科上的C/C++寫的：
int binary_search(int A[], int key, int imin, int imax)
{
// continue searching while [imin,imax] is not empty
while (imin <= imax)
{
// calculate the midpoint for roughly equal partition
int imid = midpoint(imin, imax);
if(A[imid] == key)
// key found at index imid
return imid;
// determine which subarray to search
else if (A[imid] < key)
// change min index to search upper subarray
imin = imid + 1;
else
// change max index to search lower subarray
imax = imid - 1;
}
// key was not found
return KEY_NOT_FOUND;
}
三點差異
拋開語法層面的不同，有三點顯著的差異。
1.while循環的判斷條件不同，我的沒有等于。
2.等于A[mid]判斷，我放在循環外面。
3.高位改變時，我沒有+1。
所有這些不同都基于一個自作聰明的想法：
標準版對于[..2,2,2...]這樣有相同元素的數組，返回值是隨機的，可能是相同元素中任何一個元素的位置。
于是，我為了準確的定義這種情況下，決定返回相同元素的第一個。
簡單講，標準版在對半縮小目標空間的時候，只要找到相等的元素就停止搜索了，這時候目標空間>=1。而我的版本，即使找到相等的也會接著搜索下去，直到目標空間縮小到1。
乍一看，好像我的定義更精確。然而在實際應用中，這種做法其實很愚蠢。
舉例說明
白名單過濾中，假設[...lyq...]中lyq前面還有一百萬個元素，標準版只要找到lyq就停止了，而我的版本為了確認這個lyq是否唯一，要把剩下的一百萬個元素也搜索一遍。當你確定數組中每個元素都不同時，我這種版本簡直就是沒事找事干。
聰明的你，也許會問，那如果有很多個lyq怎么辦？二分查找對半縮小空間也很快，貌似沒什么不妥。
其實不然，就算要判斷是否唯一，也很簡單，根本不需要改造標準版。答案就是，對找到的元素lyq，看他前一位是否也是lyq。如果是，說明不唯一。這樣做根本不用破壞核心。
感悟
經典的算法，看起來好像很簡單。但是在這簡單的背后，有很多邊邊角角的細節是被隱藏了的。活學活用，結合特定的場景擴展算法才是王道，不要總想著自己設計個新算法出來，搞個大新聞。
