在写binary search时对于mid的计算我最开始使用的是
mid = (low + high)/2;
后来看到在很多的实现为
mid = low + (high - low)/2;
想了一下两种实现貌似没什么差别啊，后来无意看到g9博客上的一篇文章，备份一下：
http://blog.csdn.net/g9yuayon/article/details/772382
这是Joshua Bloch（Effective Java的作者）在google blog上发的帖子。在说这个帖子之前，不得不强力重复Joshua Bloch的推荐：如果你还没有读过Programming Pearls （中文版叫《编程珠玑》)这本书，现在就去读吧。如果你只读了一遍，现在就去再读一遍吧。
还是说回Joshua的文章。当初Programming Pearls的作者Jon Bentley到CMU做讲座。他叫在场的计算机系博士生们写出binary search的算法，然后当场分析了其中一份。当然，那份算法以及绝大部分人写的算法都错了。Jon Bentley在Programming Pearls里也提到，虽然1946年就有人发表binary search，但直到1962第一个正确运行的算法才写出来。这个小故事的关键教训就是写程序时要仔细考虑算法的不变量(invariant)。如果我记 得没错，Programming Pearls第4章讲解了怎么证明binary search的正确性。当然，每本离散数学的教科书都会教我们列出pre-condition, invariant, 和post-condition，证明循环开始前pre-condition成立，循环中invariant始终成立，而循环结束后post- condition被满足，而几乎每本教科书（至少我看过的）都会用binary search作例子。所以有兴趣的自己去看吧，俺就不罗嗦了。
JDK里的binary search代码是这样实现的（Joshua Bloch本人写的）
1: public static int binarySearch(int[] a, int key) { 2: int low = 0; 3: int high = a.length - 1; 4: 5: while (low <= high) { 6: int mid = (low + high) / 2; 7: int midVal = a[mid]; 8: 9: if (midVal < key) 10: low = mid + 1; 11: else if (midVal > key) 12: high = mid - 1; 13: else 14: return mid; // key found 15: } 16: return -(low + 1); // key not found. 17: }
错误就在第6行：
6: int mid = (low + high) / 2;
这行的问题是当low和high的和超过2^31-1, 也就是Java里最大整数值时，整数溢出就发生了，而mid就变成负数了, 于是JVM就抓狂了，于是ArrayIndexOutOfBoundsException就发生了。
当一个数组包含多过2^30元素时，这个错误就会被发现。那么大的数组在80年代 Programming Pearls第一版写就的时候难以想象，但在现在却很常见。所以说，尽管1962年正确的binary search问世，现实却是直到现在流行系统里的binary search还有错。
解决的办法不难。把第6行改写成
6: int mid = low + ((high - low) / 2);
或者
6: int mid = (low + high) >>> 1;
C和C++里没有这个">>>"，我们可以这样做：
6： int mid = ((unsigned) (low + high)) >> 1。
那现在binary search就完全正确了么？我们还是不知道。我们得到的深刻教训是，仅仅证明一个程序正确是不够的。我们必须仔细测试。高德纳在写给Peter van Emde Boas的信里说，“上面那段程序可能有错。我只证明了它是正确的，但还没有测过”。人们往往用这段话来彰显高德纳的一丝不苟和学究气，谁知道这句话背后是高德纳深刻的洞察力。人们常说“理论上讲实践和理论没有差别。实践上讲，两者确有差别”，可为旁证。
binary search的这个错误同样会出现在其它“分而治之”的算法里，比如说mergesort。如果你有类似的算法代码，赶快修改吧。Joshua说，他从中学到的教训是谦卑：哪怕一个简单的程序都很难写对，而整个社会却运行在庞大而复杂的代码上面。
最后的总结很有意思：我们程序员需要各种帮助，别无它法。仔细设计很好。测试很好。形式化方法 很好（不过我还是觉得有教授研究用形式化电子商务需求（比如用范畴论），纯粹无事找事）。代码评审很好，静态分析很好。但他们并不能帮我们彻底消除代码错 误－－他们将永远存在。我们半个世纪以来竭尽全力都不能消除一个程序错误。我们必须小心翼翼，防御性地编程，并且保持警醒。