學習演算法時，演算法的證明看不懂，該怎麼辦？是繼續理解，還是先看懂代碼？

01-08

先看懂實現，再回頭看懂證明。

以《演算法導論》為例，不能指望一遍就全都懂。先一遍，把基本演算法的原理和實現搞懂；再一遍，可以關注證明。

雖然糾結於證明也有意義，但我認為不能因為一個證明不繼續下去。得不償失。

兩方面吧。

A 演算法正確性的證明——這個，最好的方法就是畫草圖去模擬，模擬的過程中你很容易發現某個步驟特別重要，攻破之；還有一個問題——」演算法的證明看不懂「　有時候真的不是你的錯，你應該多看點別的書，看看別的人是怎麼講這個問題的。很典型的例子就是，演算法導論里有很多地方我看不懂（請盡情吐槽吧），但是有時候換一本書，（比如我推薦演算法概論 (豆瓣) ，或者 Sedgewick 的演算法 (豆瓣) ），換一種解讀方法，就懂了，這時你再回去看那個看不懂的，可能也就有新的體會。

B 複雜度的證明——需要一點數學功底，然後其實關於這個，我想說的太多了。因為在大學裡修的演算法課，老師都很不注重複雜度，只是給個結論這樣。但是我去看國外名校的公開課，或者在 http://coursera.org 上選修的演算法課里，他們都會care這個事情，看了幾集之後就發現，其實這些複雜度的證明也是有規律可循的，需要用到的數學知識也並不多，高中數學裡求數列的方法就大抵夠用了。

我曾經一度迷戀演算法，現在對演算法保持熱愛的態度。在我看來，演算法不是「聰明人」的專利，而是培養我們看待世界的方法，鍛煉我們的思維模式，打個比方，就像你踢球，要先練體力一樣。像我這種智商水平在均線附近的人，真的很感謝這精彩的演算法世界，跟著無數聰明的前輩一起思考，很過癮。

我的經驗是，證明看不懂，看代碼更看不懂。

怎麼辦？具體是那一步看不懂？把書往回翻

繼續理解。有句話這麼說的：「Essentially, a theory is an abstract, symbolic representation of what is conceived to be reality. 」（本質上理論是抽象化、符號化表達現實的方式），很多時候，代碼作為一種Reality並沒有展現Theory的全貌，用抽象化、符號化的表達概括的是更廣闊的範圍。而且，個人經驗，理論沒明白，看代碼很可能更暈或者誤解。

如果題主能學好初中歐氏立體幾何，以及高中的數學歸納法，就不必糾結於某些演算法的證明了。已經被認可的證明，相信就好。Proof 本來就是數學界的 social process。我到現在還沒認真看過紅黑樹的演算法。

感謝邀請，怪不好意思的。其實我經常是證明也沒看懂，代碼也沒看懂，就先用上了。有些Acmer確實可以達到AC後仍然不會這道題的境界，我離他們還有段距離。

首先，題主準備用多少時間學習某個演算法，10分鐘？30分鐘？1個小時？

由於題主並不滿足淺嘗輒止，那麼我們就按照 @劉未鵬的知其所以然（以演算法學習為例）中的方法學習。那麼，想要徹底理解一個稍微複雜的演算法，我們估計要花上一個比較長的時間。

之所以提到這個問題，原因是我們在學習的時候，很難準確估計學習內容的難度。如果低估，在學習時很容易跳過關鍵步驟，難以理解最終結果；如果高估，則在面對學習內容的困難部分時，容易退卻，不願意花時間去想。

所以，想要解決這個問題，一定要在學習對象上花上足夠的時間。

其次，題主用了什麼方法來學習某個演算法？

既然不滿足淺嘗輒止，那麼就要用各種方法攻堅學習內容。這裡我就不班門弄斧了，題主可以參考 @劉未鵬的博文：

Category Archives: 學習方法

知其所以然（以演算法學習為例）
知其所以然（續）
知其所以然（三）：為什麼演算法這麼難？

給一個評價標準，如果你能給別人講明白這個演算法，那麼你就真正明白了。

之前問過類似的問題@vczh是這麼回答的，自己創造很多test case，人肉跑演算法測試他，直到你直覺上相信為止

經驗一個。看不懂證明的時候，你先把代碼碼出來，然後拿數據去測試，然後一般來說是需要debug一下的（不那麼好寫的代碼），然後你debug的時候會加深對演算法的理解，然後慢慢你就看得懂證明了。

知識儲備不夠