1.2.9 為算法寫代碼
絕大多數算法注定最終以計算機程序的形式實現。為算法編程既是挑戰，也是機遇。挑戰在于，為算法編寫的程序可能出現錯誤或者效率低下。一些有影響的計算機科學家堅信，除非計算機程序的正確性能夠以數學的嚴密性來證明，否則我們不能認為程序是正確的。他們開發了一些特殊的技術來實現這種證明（[Gri81]），但到目前為止，這些形式化驗證技術只能處理一些非常小型的程序。
就實用性來說，對程序的驗證還是要依賴測試。測試計算機程序與其說是一門科學，還不如說是一門藝術。但這并不意味著我們就無需學習這方面的知識。我們可以查看一些專門講述測試和調試技術的書籍，但更重要的是，無論我們實現何種算法，都要對程序進行徹底的測試及調試。
另一個需要注意的問題是，本書自始至終都假設算法的輸入都在事先確定的范圍內，從而不進行檢驗。當算法的程序實現用于實際應用時，這樣的檢驗還是必不可少的。
當然，算法的正確實現是必要的，但它還不是全部：我們當然不愿意用缺乏效率的實現來削弱算法的威力。現代編譯器的確為這種需求提供了一定的保障，尤其當它們處于代碼優化模式時。但我們仍然需要掌握一些標準的技巧，例如：在循環之外計算循環中的不變式（表達式的值不會隨情況而改變）；合并公共的子表達式；用低開銷操作代替高開銷操作等（參見[Ker99]和[Ben00]，它們對代碼優化和算法編程的其他相關問題做了很好的討論）。一般來說，這樣的改進對算法速度的影響僅僅是一個常數因子，而一個更好的算法會使運行時間產生數量級的差異。對于一個已選定的算法，如果能提高10%～50%的速度，上述努力將是值得的。
對于實際程序，我們還可以利用經驗分析來研究它內在算法的效率。這種分析的基本原理是：提供若干輸入，計算程序的運行時間，然后對結果進行分析。我們將在2.6節討論經驗分析方法的利與弊。
最后，我們再強調一下圖1.2中過程的主要含義：
一個好的算法是不懈努力和反復修正的結果，這是一條規律。
所以，即使夠運氣，獲得了一個看似完美的算法思路，也應該嘗試著改進它。
實際上，這是一件好事，因為這會讓最終結果充滿更多的樂趣（的確，我曾經考慮將這本書命名為《算法的樂趣》）。但另一方面，我們怎么知道何時應該停止這種努力呢？現實生活中，迫使我們停下來的往往是項目進度表和老板的耐心。其實原本也該如此，完美的代價往往是高昂的，而且并不總是提倡的。設計算法是一種工程行為，需要在資源有限的情況下，在互斥的目標之間做權衡，設計者的時間就是這樣一種資源。
在學術領域，算法的最優性（optimality）問題引發了有趣而又艱苦的研究。實際上，該問題與某一算法的效率無關，而與所解決問題的復雜度有關：對于給定的問題，任一算法最少需要花費多少氣力呢？有些時候，上述問題的答案是已知的。例如，對于長度為n的數組，任何用比較元素值來對數組進行排序的算法，都需要做大約n log2n次比較（參見11.2節）。但對于許多貌似簡單的問題，計算機科學家還無法給出一個最終答案，例如矩陣的乘法。
算法問題求解的另一個重要疑問是：是不是每個問題都能夠用算法的方法來解決？我們當然不是在討論問題無解的情況，例如在判別式為負時求二次方程的實根。在這種情況下，我們能得到的結果，或者說期望得到的結果，應該是算法指出該問題無解。我們也不是在討論定義模糊的問題。我們所說的是，即使是一些明確定義的問題，它們只要求回答“是”或“否”，可能也是“不可判定”的，即不能用任何算法解決。11.3節將介紹這種問題的一個重要例子。幸運的是，在實際計算中，絕大多數問題都能夠用算法來解決。
圖1.2的流程圖可能過于呆板了，但在結束這一節之前，我們希望讀者不要誤以為設計算法很無聊。一個千真萬確的事實是：發明（或者發現）算法是一個非常有創造性和非常值得付出的過程。本書的目的就是證明這個事實。